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

"Уязвимость в uClibc и uClibc-ng, позволяющая подменить данные в кэше DNS"	+/–
Сообщение от opennews (??), 04-Май-22, 14:40
В стандартных Си-библиотеках uClibc и uClibc-ng, применяемых во многих встраиваемых и портативных устройствах, выявлена уязвимость (CVE не присвоен), позволяющая подставить фиктивные данные в кэш DNS, что можно использовать для подмены в кэше IP-адреса произвольного домена и перенаправления обращений к домену на сервер злоумышленника... Подробнее: https://www.opennet.dev/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
Programs written on C be like:
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

	8. Скрыто модератором	+/–
	Сообщение от Аноним (7), 04-Май-22, 15:06
	Hare внезапно бы сам догадался, что вот здесь надо рандомизировать ID.
	Ответить | Правка | Наверх | 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, позволяющая подменить данны..."	+2 +/–
	Сообщение от 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 | Индекс форумов | Темы | Пред. тема | След. тема