The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Уязвимость в uClibc и uClibc-ng, позволяющая подменить данные в кэше DNS"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Уязвимость в uClibc и uClibc-ng, позволяющая подменить данные в кэше DNS"  +/
Сообщение от opennews (??), 04-Май-22, 14:40 
В стандартных Си-библиотеках uClibc и uClibc-ng, применяемых во многих встраиваемых и портативных устройствах, выявлена уязвимость (CVE не присвоен), позволяющая подставить фиктивные данные в кэш DNS, что можно использовать для подмены в кэше IP-адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57131

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +4 +/
Сообщение от Аноним (1), 04-Май-22, 14:40 
Никогда не было, и вот опять
Ответить | Правка | Наверх | Cообщить модератору

43. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Аноним (43), 04-Май-22, 22:46 
Опять детский сад и школа виноваты? 👀 )
Ответить | Правка | Наверх | Cообщить модератору

2. Скрыто модератором  –6 +/
Сообщение от Аноним (2), 04-Май-22, 14:43 
Ответить | Правка | Наверх | Cообщить модератору

7. Скрыто модератором  +3 +/
Сообщение от Аноним (7), 04-Май-22, 15:04 
Ответить | Правка | Наверх | Cообщить модератору

13. Скрыто модератором  +6 +/
Сообщение от НяшМяш (ok), 04-Май-22, 15:18 
Ответить | Правка | Наверх | Cообщить модератору

10. Скрыто модератором  +/
Сообщение от Аноним (10), 04-Май-22, 15:10 
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. Скрыто модератором  +/
Сообщение от Аниме (?), 04-Май-22, 14:44 
Ответить | Правка | Наверх | Cообщить модератору

8. Скрыто модератором  +/
Сообщение от Аноним (7), 04-Май-22, 15:06 
Ответить | Правка | Наверх | Cообщить модератору

4. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +2 +/
Сообщение от Аноним (4), 04-Май-22, 14:48 
Не, ну с printf было забавнее, я так понимаю у них у всех качество кода примерно одинаковое.
Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +1 +/
Сообщение от timur.davletshin (ok), 04-Май-22, 14:54 
OpenWRT же на musl переезжал, нет?
Ответить | Правка | Наверх | Cообщить модератору

11. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Мохнатый пись (?), 04-Май-22, 15:11 
Деды-пердуны на 19.07 могут иметь uClibc
Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +1 +/
Сообщение от timur.davletshin (ok), 04-Май-22, 15:47 
Там тоже musl.
Ответить | Правка | Наверх | Cообщить модератору

18. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Аноним (18), 04-Май-22, 16:19 
> musl

Там же тоже какие-то застаревшие проблемы с сетью, с тем же DNS, нет?

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

19. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от timur.davletshin (ok), 04-Май-22, 16:20 
>> musl
> Там же тоже какие-то застаревшие проблемы с сетью, с тем же DNS,
> нет?

Нет.

Ответить | Правка | Наверх | Cообщить модератору

21. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Аноним (18), 04-Май-22, 16:31 
А пишут, что musl = based but still immature with a lot of network issues, glibc = cringe but rock solid.

Уже нет? :) Ура!

Ответить | Правка | Наверх | Cообщить модератору

22. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +3 +/
Сообщение от timur.davletshin (ok), 04-Май-22, 16:37 
Ты накидывай лучше сразу ссылки на уязвимости в DNS, а не языком по широкому холсту.
Ответить | Правка | Наверх | Cообщить модератору

27. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Nr (?), 04-Май-22, 17:03 
Есть и musl, и glibc https://openwrt.org/releases/22.03/notes-22.03.0-rc1
Ответить | Правка | Наверх | Cообщить модератору

33. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от timur.davletshin (ok), 04-Май-22, 18:23 
> Есть и musl, и glibc https://openwrt.org/releases/22.03/notes-22.03.0-rc1

Это тулчейн. Как оно компиляется по большому счёту никому нет дела. А libc в самом OpenWRT от musl.

Ответить | Правка | Наверх | Cообщить модератору

29. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Аноним (29), 04-Май-22, 17:56 
ага, например, musl не умеет в DNS через TCP
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

36. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  –1 +/
Сообщение от Аноним (18), 04-Май-22, 19:32 
То есть DoT/DoH в Alpine Linux не будет работать?
Ответить | Правка | Наверх | Cообщить модератору

55. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от ilyafedin (ok), 06-Май-22, 06:45 
DoT/DoH не через libc работают
Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  –3 +/
Сообщение от Аноним (6), 04-Май-22, 15:02 
UDP маздай.
Ответить | Правка | Наверх | Cообщить модератору

9. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Аноним (7), 04-Май-22, 15:07 
Однако, NAT он пробивает лучше, чем TCP.
Ответить | Правка | Наверх | Cообщить модератору

12. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  –1 +/
Сообщение от Мохнатый пись (?), 04-Май-22, 15:13 
NAT не нужен, но UDP ещё и канал лучше утилизирует.
Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от timur.davletshin (ok), 04-Май-22, 15:52 
Он использует те же алгоритмы управления потоком, что и TCP. Просто напулять пакетов без проверки доставки можно больше, но кому такое нужно? Даже realtime видео нафиг не упало, если оно рассыпается на кашу из квадратов.
Ответить | Правка | Наверх | Cообщить модератору

20. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  –1 +/
Сообщение от Мохнатый пись (?), 04-Май-22, 16:31 
QUIC может использовать свои алгоритмы для проверки доставки.
Ответить | Правка | Наверх | Cообщить модератору

23. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от timur.davletshin (ok), 04-Май-22, 16:42 
> QUIC может использовать свои алгоритмы для проверки доставки.

Проверка доставки или всё же управление потоком? Так-то в подавляющем большинстве реализаций обычный CUBIC стоит в дефолте. Почему выносить из усерспейса VPN в ядро считается хорошим (Wireguard), а перенос realtime управления потоком из ядра в узерспейс (TCP → QUIC) не считается плохой идеей? Вам не кажется, что где-то в одном из двух случаев логика даёт сбой и создатели протокола просто "залечивают" без должного обоснования.

Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +1 +/
Сообщение от Аноним (7), 04-Май-22, 16:47 
QUIC - синдром NIH Гугли.
Ответить | Правка | Наверх | Cообщить модератору

30. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  –1 +/
Сообщение от Аноним (-), 04-Май-22, 18:02 
> Почему выносить из усерспейса VPN в ядро считается хорошим (Wireguard), а перенос realtime управления потоком из ядра в узерспейс (TCP → QUIC) не считается плохой идеей?

Потому что это разные задачи. Разным задачам, разные решения. Ты не знал об этом? Всё ищешь серебряную пулю? Успехов в поисках, тогда.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

31. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от timur.davletshin (ok), 04-Май-22, 18:16 
> Потому что это разные задачи. Разным задачам, разные решения. Ты не знал
> об этом? Всё ищешь серебряную пулю? Успехов в поисках, тогда.

Господин, вы бредите. Когда-нибудь на досуге попробуй джиттер померять в userspace реализациях и в kernel. Гарантирую, ты прозреешь. Как ресэмплинг звука в userspace вынесли, так все начали ныть про кривой pulseaudio, хотя он просто старые алгоритмы вынес в пользовательское пространство. В сетевых протоколах есть абсолютно идентичный негативный эффект от подобного переноса и не важно, это VPN или CUBIC/Reno, реализованные поверх UDP.

Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  –1 +/
Сообщение от Аноним (-), 04-Май-22, 18:37 
Нет ты.

Во-первых, VPN и HTTPS -- это разные протоколы под разные задачи. Если ты говоришь, что они принципиально не отличаются по своим требованиям к реализации, то давай обосновывай нам, почему они принципиально не различаются. Давай-давай.

Во-вторых, разработка чего-либо в ядре гораздо дороже. Строчка кода ядра обходится дороже, чем строчка кода юзерспейса. Поддержка этой строчки кода обходится резко дороже. Это ещё помножается на то, что ядерная разработка будет работать только с одним ядром, и если ты хочешь кроссплатформенности, то тебе придётся вести несколько разработок под разные ядра. OpenVPN тоже исходно разрабатывался в юзерспейсе, несмотря на весь этот твой бла-бла-бла про джиттер. Почему? Разработчики, что тупее тебя были? Нет, они как раз были умнее. Они знали, что разработка в ядре дорого, и поэтому нащупывать правильную архитектуру для реализации VPN, правильные структуры данных, правильные алгоритмы, структуру конфига, и всё остальное лучше в юзерспейсе. В юзерспейсе дешевле разрабатывать код, дешевле его мейнтейнить, дешевле дебажить, дешевле профайлить, ошибки (как архитектурные так и вида use-after-free) обходятся и исправляются дешевле, и поэтому в юзерспейсе было возможно разработать OpenVPN, в ядре практически невозможно. Вот теперь, когда накоплен опыт разработки VPN, опыт использования VPN, когда можно профайлить работу VPN со всех сторон, выясняя где и какие бутылочные горлышки возникают, вот теперь можно запилить и ядерную реализацию, причём сразу отливая её в граните так, чтобы потом не перелопачивать каждый год, когда очередная гениальная идея в голову пришла, или когда какое-нибудь важное наблюдение о строчке кода-источнике джиттера было сделано.

Ты, как заурядный опеннетовец, вслепую ощупываешь слона и говоришь, что слон похож на столб. Глаза разуй и посмотри на проблему во всей её неповторимой сложности. Тогда ты, возможно, прекратишь бредить своими деревьями джиттеров, и начнёшь говорить дельные вещи о лесе в целом.

QUIC -- это сырой протокол. Из которого хрен знает, что выйдет, и выйдет ли. Вероятно гугл применил кучу теории, для того, чтобы предсказать результат, но теория на то и теория, чтобы проверяться практикой. Только опеннетовец может ратовать за то, чтобы вбухивать сотни нефти в разработку этого QUIC прям сразу в ядре. Любой разумный человек будет разрабатывать его в юзерспейсе поверх стандартного для многих платформ API сокетов, внедрять на все платформы в юзерспейс, собирать данные с практического применения, и вот только после этого ставить вопрос: а не занести ли QUIC в ядро?

Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от timur.davletshin (ok), 04-Май-22, 19:42 
> Нет ты.
> Во-первых, VPN и HTTPS -- это разные протоколы под разные задачи. Если
> ты говоришь, что они принципиально не отличаются по своим требованиям к
> реализации, то давай обосновывай нам, почему они принципиально не различаются. Давай-давай.

Читай внимательно, что я написал. Мне до твоего HTTPS дела нет, я писал про управление потоком в QUIC как пример корявости, т.к. данное действие является задачей близкой к realtime'у. А ведь именно уменьшение накладных расходов на операции подобного приоритета стали обоснованием для выноса протокола Wireguard в ядро. Будто до этого VPN'ов на уровне ядра не было...

Ответить | Правка | Наверх | Cообщить модератору

56. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  –1 +/
Сообщение от Онаним (?), 06-Май-22, 09:40 
Вирегад в ядро вытащен только по одной причине, по той же, по которой опенжпн свой ядерный модуль пилит.
Если подавать данные для декодирования через юзерспейс - это лишняя смена контекста на каждый долбаный пакет.

В случае клюка совершенно не актуально, потому что тот, кто его танцует, его и ужинает.

Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от timur.davletshin (ok), 06-Май-22, 10:14 
> Вирегад в ядро вытащен только по одной причине, по той же, по
> которой опенжпн свой ядерный модуль пилит.
> Если подавать данные для декодирования через юзерспейс - это лишняя смена контекста
> на каждый долбаный пакет.

Т.е. QUIC в таком случае не должен существовать. Спасибо, что хоть на таком уровне со мной согласились.

Ответить | Правка | Наверх | Cообщить модератору

58. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 06-Май-22, 13:49 
Клюк в ядре не нужен. Он вполне может существовать в юзерспейсе - пакеты приходят всё тому же адресату, который занимается и управлением потоком.

В случае вирегада и прочих впн - пакеты идут через декодер, и снова уходят в ядро - следующему получателю. Разница ощутима?

Ответить | Правка | Наверх | Cообщить модератору

59. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от timur.davletshin (ok), 06-Май-22, 15:43 
> Клюк в ядре не нужен. Он вполне может существовать в юзерспейсе -
> пакеты приходят всё тому же адресату, который занимается и управлением потоком.

А чё он тогда на 30% жручее до CPU? В чём профит тогда? В обновляемости congestion control'а? Так фуфло это. Гуглу одинаково легко обновить что bbr.ko, что код веб-сервера. А сторона клиента значения не имеет от слова вообще (если ты только не загружаешь что-то). Я уже не говорю про конкретные реализации QUIC с их конкретными глюками и затупами. Чего только в 2-5 раз более медленная загрузка на Firefox/QUIC стоит.

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

60. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 06-Май-22, 17:06 
Жручее по сравнению с чем?
Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

62. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от timur.davletshin (ok), 06-Май-22, 18:56 
> Жручее по сравнению с чем?

В сравнении с TCP.

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

63. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 06-Май-22, 19:21 
Э, а ничего, что там SSL сверху?
Тогда уж с HTTPS сравнивай.
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

64. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от timur.davletshin (ok), 06-Май-22, 21:45 
> Э, а ничего, что там SSL сверху?
> Тогда уж с HTTPS сравнивай.

Сравнивали и не один раз:
https://www.fastly.com/cimages/6pk8mg3yh2ee/495gZP7ZprKQUsEj...

Если сравнивать BBR vs CUBIC, то первый сливает везде, кроме линий с большим дропом и большой задержкой.

Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

65. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 06-Май-22, 22:04 
Опять какое-то тёплое с мягким.
Можно CPU usage при одинаковом throughput, а не сферических коней в вакууме?
Впрочем я уверен, у QUIC он будет больше - разбирать подобие DTLS (мелкими блоками) - так себе затея.
Другое дело, что он не для передачи гигабит в секунду, он больше для контроля latency на куче смузи-опилок, из которых современные говносайты построены.
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

67. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от timur.davletshin (ok), 06-Май-22, 22:25 
> Можно CPU usage при одинаковом throughput, а не сферических коней в вакууме?

Можно: https://conferences.sigcomm.org/sigcomm/2020/files/slides/ep...

Советую почитать выводы. Протокол, который обещал при создании обновления алгоритма без вмешательства в систему, требует сетевое оборудование с GSO и нужно патчить реализацию UDP sendmsg для обеспечения более-менее сравнимой скорости. Я нахожу это ироничным.

> Другое дело, что он не для передачи гигабит в секунду, он больше
> для контроля latency на куче смузи-опилок, из которых современные говносайты построены.

Посмотри обоснование для его создания.

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

68. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 08-Май-22, 18:20 
> Можно: https://conferences.sigcomm.org/sigcomm/2020/files/slides/ep...

Опять какие-то сферические гуглы в вакууме.
Но даже если попытаться из этой ахинеи какие-то выводы сделать - то оно реально колышется где-то на уровне HTTPS ныне, плюс минус вечность в зависимости от имплементации.

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

69. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 08-Май-22, 18:22 
Но кстати вот эта смузи-презенташка моё предположение подтвердила неожиданно, разбирать и слать DTLS - очень накладно.

Но я вангую что с клюком нас ждёт огромная масса смешного секса, и в итоге оно будет о полутора землекопах. Не потому, что там с производительностью плохо. Я тут погуглил на тему интеропа имплементаций этого счастья, и мне поплохело.

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

66. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 06-Май-22, 22:06 
К слову, в том, что кряк - говно, я не сомневаюсь ни разу.
Но там дело не в том, что он не в ядре.
Дело в попытке соплями и скотчем примотать L4 к L7.
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

61. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 06-Май-22, 17:06 
И да, всё правильно. В обновляемости алкоритмов, написанных с бодуна под смузи.
Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

38. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от timur.davletshin (ok), 04-Май-22, 19:47 
> Почему? Разработчики, что тупее тебя были? Нет, они как раз были умнее.
> QUIC -- это сырой протокол. Из которого хрен знает, что выйдет, и
> выйдет ли. Вероятно гугл применил кучу теории, для того, чтобы предсказать
> результат, но теория на то и теория, чтобы проверяться практикой.

Разрабы Google, выходит, у тебя лохи печальные, а в Wireguard ну просто гении. Дружище, научись писать внутренне непротиворечивые тексты для начала. А там, может, и до деталей реализации RTP дойдём.

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

24. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Аноним (7), 04-Май-22, 16:44 
Скажи это провайдерам.
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

28. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Мохнатый пись (?), 04-Май-22, 17:20 
Говорю каждый раз, пора бы уже ipv6 внедрять. Внедрение ipv6 во всём постсовсовке на уровне стран африки.
Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 04-Май-22, 23:58 
Открою тебе секрет - и не только в постсовке.
У нас есть полтора пользователя IPv6, Европа, причём западная.
Они даже им вроде как пользуются.
Но абсолютное и подавляющее большинство им не интересуется вообще.
Не взлетело.
Ответить | Правка | Наверх | Cообщить модератору

46. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 05-Май-22, 00:00 
(нет, мы можем всем выдать по /64 автоматом, и даже пробовали на все серверы его развесить (не зашло, поубирали) - и после бодро отрапортоваться о 100% пенетрации, но клиентам от этого будет только хуже - жалобы на откровенно хреновую работу при попытке подобное делать были, есть, и будут есть)
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

47. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 05-Май-22, 00:02 
А не зашло потому, что какому-то <beep> пришло в дурную голову AAAA при резолве DNS сделать приоритетным.
В итоге некоторые внешние юзеры того же хостинга начинают вместо 30-40мс отклика иметь 80-120, а то и вообще ничего не иметь, и начинают жаловаться.
Ответить | Правка | Наверх | Cообщить модератору

49. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +1 +/
Сообщение от Мохнатый пись (?), 05-Май-22, 00:34 
> А не зашло потому, что какому-то <beep> пришло в дурную голову AAAA
> при резолве DNS сделать приоритетным.
> В итоге некоторые внешние юзеры того же хостинга начинают вместо 30-40мс отклика
> иметь 80-120, а то и вообще ничего не иметь, и начинают
> жаловаться.

Кулстори какие-то. Сижу через туннель, ибо провайдер дебил, пинг из-за европейского сервера выше на 80мс до яндекса. И знаешь что? Различий вообще почти не вижу, может у вас такая реализация была классная? А чтобы колическо пользователей выросло, то надо свои роутеры через TR-69 настраивать и пользователям говорить, чтобы ipv6 включали, либо (что менее вероятно из-за кривых приложений с захардкоженным ipv4 адресом) сразу отрубать ipv4, выпускать только с ipv6 и NAT64. Так кстати некоторые новые провайдеры делают и мобильные операторы, ибо ipv4 уже на вес золота.

Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +1 +/
Сообщение от Онаним (?), 05-Май-22, 22:05 
> отрубать ipv4, выпускать только с ipv6 и NAT64

Эдак у вас число пользователей уменьшаться начнёт, а не вырастет.

Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 05-Май-22, 22:21 
Ну а чего кулстори. Есть провайдеры в местных (ну, не местных, соседние страны) залупищенсках, трасса по IPv6 от которых идёт через такие дрындыня, что закачаешься. И вот когда на сервере вывешиваешь IPv6, из этой страны начинают ходить по болотам вприпрыжку, потому что академичные дятлы заприорили AAAA, всем по IPv6 и нивалнуед, что там потери, и лейтенси двукратный. А между странами всего 150 км расстояния, и они друг к другу в магазины ходят :D
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

53. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 05-Май-22, 22:22 
Это сейчас ещё хецнеровские туннели убились - стало полегче, раньше можно было легко на них нарваться, там вообще благодать была.
Ответить | Правка | Наверх | Cообщить модератору

15. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +1 +/
Сообщение от pashev.ru (?), 04-Май-22, 15:40 
Теперь народ начнёт понимать, почему glibc такая "жирная" 🙂
Ответить | Правка | Наверх | Cообщить модератору

32. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  –1 +/
Сообщение от Аноним (32), 04-Май-22, 18:20 
Думаешь в glibc нет бэкдоров? Поверь мне, их там еще больше.
Ответить | Правка | Наверх | Cообщить модератору

39. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Онаним (?), 04-Май-22, 19:53 
Системы с glibc обычно не проблема обновить.
А вот то, где uclibc - многое из этого уже (древнющее и не очень) легаси, в т.ч. разряда хоаксного iot, для которого вендор прошивку выпускать уже не будет, да и есть ли он.
Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Аноним (41), 04-Май-22, 22:31 
Обновишь и получишь еще больше бэкдоров, руткитов, вирусов, телеметрии, малвари и фингерпринтинга.
Сомнительное преимущество.
Ответить | Правка | Наверх | Cообщить модератору

42. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +1 +/
Сообщение от Онаним (?), 04-Май-22, 22:33 
Всё ещё сидишь на ядре 2.0?
Ответить | Правка | Наверх | Cообщить модератору

35. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +/
Сообщение от Аноним (-), 04-Май-22, 18:44 
Все кто любят юникс, первым делом выпиливают юниксовые "убства" в первую очередь. Либси должна содержать наборчик макросов 90% скопипащеных с ядра и неболее ящитаю.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

40. "Уязвимость в uClibc и uClibc-ng, позволяющая подменить данны..."  +1 +/
Сообщение от Аноним (40), 04-Май-22, 21:30 
Гордый суффикс "-ng" прикрутили, а на прикрутить рандом "не в состоянии исправить"? :D
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру