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

Удалённая уязвимость в IPv6-стеке OpenBSD, opennews (??), 28-Окт-20, (0) [смотреть все] Ha-ha, classic , Аноним (1), 22:17 , 28-Окт-20, (1) +8 // ку-ка-ре-ку in a heck of a long time ку-ка-ре-ку , Аноним123 (?), 22:56 , 28-Окт-20, (6) –1 Как ни странно, исправить баг на опасном си - быстрее и проще, чем написать на, Аноним (9), 23:07 , 28-Окт-20, (9) +1 // У тебя Си головного мозга Никто же не заикался про Си или Раст в ветке , Ненавижу SJW (?), 10:05 , 29-Окт-20, (33) +7 При чем тут си Просто сссупербезопасная ось в очередной раз оказалась просто н, Аноним (1), 10:07 , 29-Окт-20, (35) –3 // нет просто ipv6 еще долго будет всем отдаваться икотой от его проблем пока не в, анонимуслинус (?), 23:59 , 29-Окт-20, (57) +1 Только божественно одаренный мог сравнить трудоемкость исправления ошибки в одно, Аноним (37), 10:31 , 29-Окт-20, (37) // А ты ещё удивляешься, почему на расте не пишут , Аноним (9), 18:58 , 29-Окт-20, (51) +2 Fracta1L, залогинься , Аноним (34), 10:07 , 29-Окт-20, (34) +1 rust, приди порядок наведи , JL2001 (ok), 22:18 , 28-Окт-20, (2) –2 // С достаточным опытом в сишке никакой раст не нужен За следующие десять лет еще , Аноним (-), 22:24 , 28-Окт-20, (3) +12 // Я тут вчера покопался в коде утилитки которую написал 10 лет назад Свежий компи, Аноним (7), 22:58 , 28-Окт-20, (7) // Если сейчас погромисты на си путаются в указателях, то на расте будут путаться м, Аноним (9), 23:12 , 28-Окт-20, (10) +4 зато это будут наши a и c мои и индуса , а не васи-хацкера, JL2001 (ok), 06:44 , 29-Окт-20, (25) Вот погромисты, которые не знают о существовании оператора , громче всех про r, Аноним (13), 23:52 , 28-Окт-20, (13) +9 скоро начнут путать приоритеты и , Аноним (9), 23:59 , 28-Окт-20, (14) всегда путали в том числе и на Си, на асемблере тока не путали , JL2001 (ok), 15:42 , 29-Окт-20, (43) +1 Скорее всего наоборот те кто знают о существовании такого оператора и думают, ч, Аноним (7), 00:15 , 29-Окт-20, (16) –1 В итоге закономерно страдают Всё правильно , Онаним (?), 08:45 , 29-Окт-20, (29) +2 n - это прекрасно А никак нельзя было , Онаним (?), 08:44 , 29-Окт-20, (28) +4 Видимо писали ещё не выучив ни операции ни приоритеты PS я когда начинал учить , Аноним (49), 18:48 , 29-Окт-20, (49) +1 ну, это маловероятно, я всё же ставлю на неверно размещённую скобочку иначе бы , Аноним (7), 19:17 , 29-Окт-20, (52) +3 пс да, там где-то рядом было ещё в духе 8232 8232 8232 8232 8232 82, Аноним (7), 19:21 , 29-Окт-20, (53) +1 Более квалифицированные программисты за такой код лупят по заднице ремнём это U, Ordu (ok), 05:55 , 30-Окт-20, (59) +1 Видимо, 30 лет опыта разработчикам не хватило , Siborgium (ok), 05:34 , 29-Окт-20, (23) +2 Настолько тонко что даже толсто , Fracta1L (ok), 08:02 , 29-Окт-20, (26) // У Вас integer overflow , Michael Shigorin (ok), 22:55 , 29-Окт-20, (56) +1 Тоесть получается сишке нужно 58 лет учиться Но есть ли гарантии что через 10 пр, Аноньимъс (?), 10:36 , 31-Окт-20, (71) на расте такое сложно написать, ещё никто не смог, Аноним (9), 22:56 , 28-Окт-20, (5) +1 // хм, и правда, в redox ipv6 пока не завезлино ipv4 же есть и функционал сравним , JL2001 (ok), 06:42 , 29-Окт-20, (24) Братство свидетелей святого Rust , Аноним (34), 10:09 , 29-Окт-20, (36) –3 // Нет это весёлые тролли Не обращайте внимания Они сами исчезнут , Аноним (-), 16:25 , 31-Окт-20, (75) Отродясь такого не бывало, и опять то же самое , Аноним (4), 22:24 , 28-Окт-20, (4) +1 А что так Не хотят давать возможность для ловли лулзов Да ладно, мы уже привыкл, Аноним (-), 23:00 , 28-Окт-20, (8) +3 // Да там как обычно, надо сырцы эксплоита патчить под свою систему, компилять и за, Аноним (9), 23:14 , 28-Окт-20, (11) –4 Мда, ещё более бессодерждательно нежели недавняя новость про дыры в netbsd по, Дон Ягон (ok), 23:14 , 28-Окт-20, (12) +2 // Ну там outgoing IPv6 connections , а здесь, по сути, есть ненулевая вероятность, Аноним (15), 00:14 , 29-Окт-20, (15) +1 // Лучше может быть только безусловное выполнение от рута любой присланной извне ко, Аноним (7), 00:41 , 29-Окт-20, (18) +1 Ну и не такая большая вероятность RCE, на самом деле, зависит очень от многого Н, Дон Ягон (ok), 01:54 , 29-Окт-20, (19) –2 Немного повтыкал я в суть проблемы Ты прав, весьма похоже на CVE-2020-16898 Там, Дон Ягон (ok), 03:42 , 29-Окт-20, (21) +1   // Ядро OS должно очищать память перед освобождением https en m wikibooks org w i, Аноним (31), 08:56 , 29-Окт-20, (31) –5   О даа Тео ЛИЧНО запретил, мммм, не знаю, портировать KASAN из netbsd ради 1 пр, Дон Ягон (ok), 13:03 , 29-Окт-20, (42) –1   Для тебя персонально, в DAC необходимо также включать процессы в оперативке Пока, Аноним (63), 16:16 , 30-Окт-20, (63)   uname ls -l procOpenBSDcolorls proc No such file or directory, Дон Ягон (ok), 17:02 , 30-Окт-20, (64)   А, да, memory poisoning В ядре openbsd это есть и ЕМНИП появилось там это раньше, Дон Ягон (ok), 01:15 , 30-Окт-20, (58) +2   Нет В виде неофициальных патчей к ядру Linux была раньше По ссылкам правильная , Аноним (63), 16:08 , 30-Окт-20, (62)   И именно поэтому всем на это начхать Нет, это костыльный и неправильный путь, си, Дон Ягон (ok), 18:15 , 30-Окт-20, (65) +2   Строгий контроль со стороны процессора и ядра OS -- единственное решение которое, Аноним (70), 10:27 , 31-Окт-20, (70)   Строгий контроль граждан государством - единственный способ избежать революции Н, Аноньимъс (?), 10:56 , 31-Окт-20, (72) +1   В свободном ПО есть возможность независимой верификации Средства контроля прост, Аноним (80), 08:12 , 01-Ноя-20, (80) –1   И поэтому постоянно находят всё новые и новые ошибки, наберите воздуха, готовы , Аноньимъ (ok), 16:44 , 01-Ноя-20, (82)   В твоих устах это больше похоже на религиозную мантру, чем на аргумент Баги и д, Дон Ягон (ok), 22:05 , 31-Окт-20, (78) +1   Компилятор с хорошими опциями компиляции укажет программисту на ошибки безопасно, Аноним (80), 08:35 , 01-Ноя-20, (81)   Они - это кто Линус и Шпенглер Ничего, что Brad Spengler - это как раз из grse, Дон Ягон (ok), 18:10 , 01-Ноя-20, (84)   _remote_ code exec, куда еще содержательней это local по сути - вызывается дейст, пох. (?), 09:31 , 29-Окт-20, (32) –1 // А это изначально из текста новости было неясно Ссылку на твиттер Вилларда в неё, Дон Ягон (ok), 12:54 , 29-Окт-20, (41) никогда не использовал ipv6, но в этот раз точно буду протокол от народа , б.б. (?), 03:31 , 29-Окт-20, (20) –2 // правильно, должен же кто-то за дефицитные ipv4 платить, всего 2 бакса в месяц , Аноним (87), 20:49 , 22-Ноя-20, (87) Only two remote holes in the default install, in a heck of a long time сайт, Аноним (22), 05:26 , 29-Окт-20, (22) +2 // Там просто речь всегда идет о двух последних найденных дырах А те, что до них, , Аноним (27), 08:09 , 29-Окт-20, (27) +3 // Наверняка список найденных дыр золотая рыбка обновляла , Онаним (?), 08:45 , 29-Окт-20, (30) +3 Надо устроить опрос, что, по мнению опеннетовских аналитиков, более эффективно п, Аноним (38), 10:44 , 29-Окт-20, (38) +1 // Неиспользование C более мощно Оно автоматически влечёт неиспользование IPv6 ,, Аноним (34), 16:00 , 29-Окт-20, (45) +2 Как хорошо, что я запрещаю ипв6 ещё при установке - , псевдонимус (?), 12:01 , 29-Окт-20, (39) +1 // А когда он появится у твоего провайдера, что делать будешь , Аноним (34), 15:55 , 29-Окт-20, (44) +1 // Попробую муравью хрен приделать - Он не появится, ибо бесполезен , псевдонимус (?), 16:41 , 29-Окт-20, (46) +1 Расскажи, сколько провайдеров в Штатах раздают белые IPv6 обладателям яойфонов , Аноним (9), 18:49 , 29-Окт-20, (50) +4 // Если обычного юзера с ведром или гейфоном, с хромобраузером на борту выпустить в, псевдонимус (?), 22:28 , 29-Окт-20, (54) +1 На гейфонах нет хромобраузера Если что , Аноним (61), 13:37 , 30-Окт-20, (61) +1 Будет Всё будет Алсо, белый опи v6 не так работает как v4 , Аноньимъс (?), 10:59 , 31-Окт-20, (73) +1 Его тоже прекрасно трахают И работает он также, псевдонимус (?), 18:51 , 31-Окт-20, (76) Так он и должен трахаться, в этом вся суть , Аноньимъ (ok), 17:02 , 01-Ноя-20, (83) ботнетом они и так становятся, наставив апкшек от неПети, а кирпич вообще пробле, Аноним (87), 20:52 , 22-Ноя-20, (88) Уважаемые Анонимные Эксперты Напоминаю Вам, что с каждой загрузкой в OpenBSD нов, Аноним (-), 17:43 , 29-Окт-20, (47) +1 // Уважаемый Разработчик Если система с опенбсд на борту используется в качестве ш, псевдонимус (?), 18:46 , 29-Окт-20, (48) // А если используется линукс, виндовс, или проприетарная ос, её падение не будет о, Аноньимъс (?), 11:02 , 31-Окт-20, (74) // Как это оправдывает опенбсд , псевдонимус (?), 18:53 , 31-Окт-20, (77) –1 От чего оправдывает Кто-то в чем-то обвиняет OpenBSD Мы тут на суде , Аноньимъ (ok), 23:22 , 31-Окт-20, (79) +1 Брутфорсить не обязательно, надо подождать когда найдут очередной способ обойти , Ordu (ok), 05:59 , 30-Окт-20, (60) +1 // Удалённо , Дон Ягон (ok), 18:16 , 30-Окт-20, (66) // Это по-разному бывает Дыры довольно непредсказуемые вещи Посмотри на современн, Ordu (ok), 19:13 , 30-Окт-20, (67) +1 Согласен Но всё же удалённая утечка инфы о структурах ядра - имхо, это что-то, , Дон Ягон (ok), 19:44 , 30-Окт-20, (68) Тео про еррату, степень опасности, слоган и пр We ve released the errata as se, Дон Ягон (ok), 22:13 , 30-Окт-20, (69) ping of the death опять на чужих ошибках учиться не того почему это сейчас, а, Аноним (-), 20:45 , 21-Ноя-20, (86) 1,2,4,8,12,20,22,38,39,47,69,86

Сообщения

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

	21. "Удалённая уязвимость в IPv6-стеке OpenBSD"	+1 +/–
	Сообщение от Дон Ягон (ok), 29-Окт-20, 03:42
	Немного повтыкал я в суть проблемы. Ты прав, весьма похоже на CVE-2020-16898. Там правда вроде не uaf (хотя я глубоко не погружался). А в остальном довольно похоже: не слишком высокий шанс на успешную эксплуатацию + возможность эксплуатации только внутри локальной сети. Но если таки всё сложится, то, по-видимому, возможно RCE. Ещё напомнило CVE-2007-1365.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	31. "Удалённая уязвимость в IPv6-стеке OpenBSD"	–5 +/–
	Сообщение от Аноним (31), 29-Окт-20, 08:56
	Ядро OS должно очищать память перед освобождением! https://en.m.wikibooks.org/w/index.php?title=Grsecurity/Appe... https://en.m.wikibooks.org/w/index.php?title=Grsecurity/Appe... Memory poisoning: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... А OpenBSD не очищает память перед освобождением? Им жалко потерять 1% производительности? Да, эта OpenBSD еще использование JIT допускает. Похоже Тео вообще готов н_а_с_р_а_т_ь на безопасность ради мнимых 2% производительности.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Удалённая уязвимость в IPv6-стеке OpenBSD"	–1 +/–
	Сообщение от Дон Ягон (ok), 29-Окт-20, 13:03
	О даа! Тео ЛИЧНО запретил, мммм, не знаю, портировать KASAN из netbsd ради 1% производительности! Конечно, дело ни в коем случае, например, не в том, что свободных рук не хватает или не в чём-то похожем! Жаль, когда портировали, например, KUBSAN из netbsd Тео потерял бдительность и примерно -2% производительности прорвались в ядро! --- Спой лучше ещё раз про DAC, иксперд. PS: а если бы kasan таки портировали или что-то аналогичное по смыслу - было бы неплохо, да.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Удалённая уязвимость в IPv6-стеке OpenBSD"	+/–
	Сообщение от Аноним (63), 30-Окт-20, 16:16
	> ещё раз про DAC Для тебя персонально, в DAC необходимо также включать процессы в оперативке! Покажи вывод: ls -l /proc
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Удалённая уязвимость в IPv6-стеке OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 30-Окт-20, 17:02
	>> ещё раз про DAC > Для тебя персонально, в DAC необходимо также включать процессы в оперативке! > Покажи вывод: > ls -l /proc uname && ls -l /proc OpenBSD colorls: /proc: No such file or directory
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Удалённая уязвимость в IPv6-стеке OpenBSD"	+2 +/–
	Сообщение от Дон Ягон (ok), 30-Окт-20, 01:15
	А, да, memory poisoning. В ядре openbsd это есть и ЕМНИП появилось там это раньше чем в linux. https://www.openbsd.org/papers/dev-sw-hostile-env.html Про ссылки на pax, которые я перечитал чуть менее по диагонали чем в прошлый раз - там не про kasan, как я подумал, да. Лучше бы про него - в отличие от он уже по меньшей мере в 2х с половиной ОС есть (в openbsd его нет, но https://man.openbsd.org/malloc.9#DIAGNOSTICS +/- аналогично по смыслу). Потому что нельзя сделать ничего хорошего обкладывая плохо написанные программы костылями, чтобы они работали правильно. Надо исправлять ошибки, а не нагромождать вокруг потенциальных ошибок костыли. Сами по себе костыли эти может не так и дорого стоят, а вот все вместе - уже ощутимо. А по-отдельности в них смысла просто нет.
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	62. "Удалённая уязвимость в IPv6-стеке OpenBSD"	+/–
	Сообщение от Аноним (63), 30-Окт-20, 16:08
	> В ядре openbsd это есть и ЕМНИП появилось там это раньше чем в linux. Нет. В виде неофициальных патчей к ядру Linux была раньше. > Про ссылки на pax, которые я перечитал чуть менее по диагонали По ссылкам правильная и быстрая реализация очистки памяти при освобождении. > Потому что нельзя сделать ничего хорошего обкладывая плохо написанные программы костылями, чтобы они работали правильно. Это единственный путь который дает гарантии безопасности. Другого просто не существует. Процессор с ядром OS должен следить за корректность работы программы. Самим программам/компиляторам доверять нельзя. > Надо исправлять ошибки, а не нагромождать вокруг потенциальных ошибок костыли. Сами по себе костыли эти может не так и дорого стоят, а вот все вместе - уже ощутимо. А по-отдельности в них смысла просто нет. Ошибки были есть и будут. Технологии защиты много ресурсов не требуют. Сегодня не 1980-тые, ресурсов процессора хватает с избытком.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Удалённая уязвимость в IPv6-стеке OpenBSD"	+2 +/–
	Сообщение от Дон Ягон (ok), 30-Окт-20, 18:15
	>> В ядре openbsd это есть и ЕМНИП появилось там это раньше чем в linux. > Нет. В виде неофициальных патчей к ядру Linux была раньше. И именно поэтому всем на это начхать. >> Потому что нельзя сделать ничего хорошего обкладывая плохо написанные программы костылями, чтобы они работали правильно. > Это единственный путь который дает гарантии безопасности. Другого просто не существует. > Процессор с ядром OS должен следить за корректность работы программы. Самим > программам/компиляторам доверять нельзя. Нет, это костыльный и неправильный путь, сиюминутное решение вместо правильного. Если в программе ошибка (т.е. именно программа работает неправильно) надо не лепить костыли, заставляющие ядро помогать программе работать правильно, а устранять ошибку. И работать надо в первую очередь над тем, чтобы ошибок было как можно меньше. Подход с нахлобучиванием костылей приведёт к тому, что у нас будет куча странно работающего кода, непонятно как взаимодействующего друг с другом и непредсказуемо падающего. > Ошибки были есть и будут. Технологии защиты много ресурсов не требуют. Сегодня > не 1980-тые, ресурсов процессора хватает с избытком. И это не повод бедумно просирать их, а не то снова не будет хватать. Но в первую очередь дело не в этом, а в простоте архитектуры и прозрачности конструкции. Какой шанс, что эту ошибку бы нашли и исправили, если бы в ядре были костыли, которые предотвращают её эксплуатацию как уязвимости? Очень незначительные, т.е. изредка ядро могло бы случайным образом падать, например. Делает ли такой подход ОС лучше? Нет, он добавляет лишь избыточную сложность и маскирует проблему. Нужно расширять средства, которые позволят найти и устранить как можно больше подобных и не только ошибок, а также техники снижающие вред от попыток эксплуатации тех ошибок, что найти не удалось - w^X, KASLR/KARL и т.п.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Удалённая уязвимость в IPv6-стеке OpenBSD"	+/–
	Сообщение от Аноним (70), 31-Окт-20, 10:27
	> Нет, это костыльный и неправильный путь, сиюминутное решение вместо правильного. Строгий контроль со стороны процессора и ядра OS -- единственное решение которое дает гарантии невозможности эксплуатации уязвимостей. > Если в программе ошибка (т.е. именно программа работает неправильно) надо не лепить костыли, заставляющие ядро помогать программе работать правильно, а устранять ошибку. Плевать на программистов, языки программирования и компиляторы. Ошибки - были, есть и будут (компилятор тоже важен: генерация позиционно независимого кода для работы ASLR, канарейки для защиты от переполнения стека SSP, автоматическая фортификация небезопасны функций; и правильная работа линковщика тоже важна: ....). Строгий контроль со стороны процессора и ядра OS -- единственное решение которое дает гарантии невозможности эксплуатации уязвимостей. > Какой шанс, что эту ошибку бы нашли и исправили, если бы в ядре были костыли, которые предотвращают её эксплуатацию как уязвимости? Очень незначительные, т.е. изредка ядро могло бы случайным образом падать, например. Делает ли такой подход ОС лучше? Ты даже сути проблемы не понимаешь. Если процессор с ядром OS не контролирую память то при наличии ошибки будет эксплуатируемая уязвимость которую вирусы будут незаметно использовать. Если защита со стороны процессора и OS реализована, то при наличии ошибки, например переполнения буфера, попытка эксплуатации ее вирусом будет присечена, а сам факт задокументирован в системном журнале, отослан по почте и станет сразу известен. Конечно известную ошибку исправят быстрее. Строгий контроль со стороны процессора и ядра OS -- единственное решение которое дает гарантии невозможности эксплуатации уязвимостей. > Нужно расширять средства, которые позволят найти и устранить как можно больше подобных и не только ошибок, а также техники снижающие вред от попыток эксплуатации тех ошибок, что найти не удалось - w^X, KASLR/KARL и т.п. Они уже есть. Надо их просто использовать. Почему в дистрибутивах не используют средства защиты от разных уязвимостей, а вместо этого внедряют средства препятствующие защите: JIT, ...?
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Удалённая уязвимость в IPv6-стеке OpenBSD"	+1 +/–
	Сообщение от Аноньимъс (?), 31-Окт-20, 10:56
	Строгий контроль граждан государством - единственный способ избежать революции. Нет. Это так не работает. В сложных системах есть много сложных факторов. Ну например уязвимости в средствах контроля. Привет интелME. Привет секурбут. Ну а дальше системные  неустранимые недостатки, вроде Си процессоров в которых ни о каком контроле и речи не идет и Си программ которые тоже ничего о разделении памяти не знают. То, что вы называете "контролем" у нормальных людей называется управление памятью. И в лисп машинах было 30 лет назад сделано. А так же во всяких приличных ЦП для Ады.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Удалённая уязвимость в IPv6-стеке OpenBSD"	–1 +/–
	Сообщение от Аноним (80), 01-Ноя-20, 08:12
	> Ну например уязвимости в средствах контроля. В свободном ПО есть возможность независимой верификации. Средства контроля просты. > Привет интелME. Исходя из темы обсуждения привет надо передавать Intel NX. Проблемы с этой инструкцией уже были в ранних версия Pentium4. Есть вариант чисто программой защиты, без использования специальных инструкций процессора, на пару процентов снизит производительность. > Привет секурбут. SecureBOOT, TPM - хорошие вещи. Производителям кроме верификации по цифровым подписям стоит добавить на платы джемпер физически запрещающий запись в SPI где хранится UEFI/BIOS. > Ну а дальше системные  неустранимые недостатки, вроде Си процессоров в которых ни о каком контроле и речи не идет Компилять только на отключенных от сети компах. Система повторяемые сборок для верификации бинарей. >  Си программ которые тоже ничего о разделении памяти не знают. Им и знать не надо. YAMA в ядре Linux знает.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Удалённая уязвимость в IPv6-стеке OpenBSD"	+/–
	Сообщение от Аноньимъ (ok), 01-Ноя-20, 16:44
	> В свободном ПО есть возможность независимой верификации. Средства контроля просты. И поэтому постоянно находят всё новые и новые ошибки, наберите воздуха, готовы? переполнения буфера. > Исходя из темы обсуждения привет надо передавать Intel NX. Да всему этому x86/RISC цирку нужно привет передавать. > SecureBOOT, TPM - хорошие вещи. Для ограничения свободы пользователей. > Компилять только на отключенных от сети компах. Как это поможет с концептуальными недостатками сишки? > Система повторяемые сборок для верификации бинарей. Это далеко не все линуксы освоили для ядра хотя бы. Это хорошо конечно всё и замечательно. Но что-то с индустрией принципиально не так если требуются титанические усилия для создания системы повторяемой сборки. Вообще, кроме GuixSD кто-то это из линуксов обеспечивает? > Им и знать не надо. YAMA в ядре Linux знает. You known nothing, YAMA Linux.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Удалённая уязвимость в IPv6-стеке OpenBSD"	+1 +/–
	Сообщение от Дон Ягон (ok), 31-Окт-20, 22:05
	> Строгий контроль со стороны процессора и ядра OS -- единственное решение которое дает гарантии невозможности эксплуатации уязвимостей. В твоих устах это больше похоже на религиозную мантру, чем на аргумент. Баги и дыры есть и в процессорах и в средствах защиты в ОС. Али local root в grsec-патчах (которого не было в ванильном linux, CVE-2007-0257) уже забылся? Или kernel panic в нём же (https://xakep.ru/2016/04/28/grsecurity-ban/)? Или забылся dirty cow, который успешно эксплуатировался даже с включёнными pax-патчами? Про новомодные meltdown и его друзей как-то даже напоминать неудобно. > Плевать на программистов, языки программирования и компиляторы. Нет. Профессионализм программистов и правильно выбранные средства гораздо важнее. > Ошибки - были, есть и будут Ага. И ловить их, по-возможности, лучше не в рантайме, а на стадии компиляции. Или хотя бы в какой-то тестовой среде. Вмешиваться в работу прикладных программ или модулей/компонентов ядра всяческими "проактивными средствами защиты" нужно как можно аккуратнее, ибо можно замедлить приложение/ядро. Или обрушить его. Или всё будет +/- ок, но портирование ядерной защиты на другую архитектуру будет неадекватно сложно. Почитай, ради интереса, как Попов из PT переносил PAX_STACKLEAK из остатков grsec-патчей в ванильное ядро (на русском, например, тут - https://habr.com/ru/company/pt/blog/424633/ + в коментариях есть полезные ссылки на lwn). И высказывания линуса и шпенглера по поводу этих патчей (выдержке попова можно только позавидовать, не каждый довёл бы пусть и нужное дело до конца под таким давлением. он большой молодец, как по мне). И сроки выполнения работ оцени. Не всё так просто и однозначно, короче. > Они уже есть. Надо их просто использовать. Почему в дистрибутивах не используют средства защиты от разных уязвимостей, а вместо этого внедряют средства препятствующие защите: JIT, ...? У тебя какая-то болезненая фиксация на jit. В то время как это вполне законный способ ускорить транслируемые языки (стандарт позволяет). Да и не всякий jit требует W|X, некоторые, типа того, что у мозиллы, требует только возможности переключений RW -> RX, что _значительно_ лучше. А та же java, например, хотя и требует W|X, зато достаточно быстра и предотвращает многие типовые проблемы в безопасности приложений. И, самое главное, есть востребованные бизнесом приложения на той же java. Это ты можешь собрать себе дистрибутив без jit вообще, если у тебя много свободного времени, а бизнес не будет переписывать решение c java на что-то там ещё, если решение на java их устраивает. Ради чего просто? Ради иллюзии безопасности? При таких раскладах проще уж будет, имхо, вложиться в аудит и поиск дыр в условном jvm дабы пофиксить их - в конце концов, реализация jit даже и требующая W|X может и не иметь в себе эксплуатируемых уязвимостей.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	81. "Удалённая уязвимость в IPv6-стеке OpenBSD"	+/–
	Сообщение от Аноним (80), 01-Ноя-20, 08:35
	> Профессионализм программистов Компилятор с хорошими опциями компиляции укажет программисту на ошибки безопасности. Вот профессионализм проявляется тогда когда программист сам исправляет ошибки по рекомендации компилятора. Когда исправляет после багрепорта тоже еще можно терпеть. > портирование ядерной защиты на другую архитектуру будет неадекватно сложно. Это тема большого отдельного разговора. По этому поводу я согласен с Н. Виртом. > высказывания линуса и шпенглера по поводу этих патчей Они не любят PaX & Grsecurity и противятся включению этих патчей в ядро уже 20 лет. То что включается в ядро, не все но часть дырява и сделана хуже чем в оригинальном PaX & Grsecurity. > У тебя какая-то болезненая фиксация на jit. Да, причем очень заостренная. Иначе пионеры этот JIT напихают во весь софт. У меня строгая реализация защиты не допускающая любого JIT, соответственно ПО которое не собирается без JIT у меня и на многих архитектура процессоров mips, ppc, ... просто не будет работать. Мы не можем использовать ПО с JIT по этому и громко кричим, что JIT - зло и надо во всех программах иметь опцию configure --jitless --no-jit для сборки проги без JIT. > реализация jit даже и требующая W|X может и не иметь в себе эксплуатируемых уязвимостей. Гарантий отсутствия уязвимостей вылизывая код с JIT не получишь. А ядро OS с процессором может дать гарантии отсутствия эксплуатации уязвимостей переполнения буфера.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Удалённая уязвимость в IPv6-стеке OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 01-Ноя-20, 18:10
	> Они не любят PaX & Grsecurity Они - это кто? Линус и Шпенглер? Ничего, что Brad Spengler - это как раз из grsec?) > сделана хуже чем в оригинальном PaX & Grsecurity. А обосновать почему PAX_SECSTACK им. Попова из Ptsecurity хуже оригинального своими словами рассказать сможешь?) > JIT - зло и надо во всех программах иметь опцию configure --jitless --no-jit для сборки проги без JIT. Жаль, что ты не способен понимать даже то, что ты сам пишешь. Ну зачем делать опции "jitless", если jit вообще не нужен? По существу: нет, не надо. > может дать гарантии О, ты пошёл очередной круг нарезать. Я сливаюсь, у меня уже и так отпечаток ладони на лице который день болит.
	Ответить | Правка | Наверх | Cообщить модератору

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

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