В OpenBSD устранена уязвимость в IPv6-стеке, которая может привести к использованию уже освобождённой области памяти mbuf (use-after-free) в процессе генерации ICMP6-ответа на пакет IPv6....Подробнее: https://www.opennet.me/opennews/art.shtml?num=53985
Ha-ha, classic!
ку-ка-ре-ку... in a heck of a long time... ку-ка-ре-ку...
Как ни странно, исправить баг на "опасном" си - быстрее и проще, чем написать на "безопасном" расте.
У тебя Си головного мозга. Никто же не заикался про Си или Раст в ветке.
При чем тут си?
Просто сссупербезопасная ось (в очередной раз) оказалась просто неуловимым Джо, который нафиг никому не сдался.
нет просто ipv6 еще долго будет всем отдаваться икотой от его проблем. пока не вычистят стандарт и реализации. как было с ipv4|.
Только божественно одаренный мог сравнить трудоемкость исправления ошибки в одной функции огромной системы, форкнутой от другой системы, написанной на Си в лохматые годы и трудоемкость написания такой же ОС на относительно безопасном языке, в которой такой ошибки и не возникло бы. Но кто знает, может со временем новый Тео де Раадт, также повернутый на безопасности, напишет какую-нибудь OpenRedox форкнув Redox и там такие ошибки всплывать будут значительно реже, разве что в каких-нибудь кастомных/проприетарных драйверах юзерспейса, написанных в unsafe-режиме.
А ты ещё удивляешься, почему на расте не пишут.
Fracta1L, залогинься.
> использованию уже освобождённой области памяти mbuf (use-after-free)rust, приди!! порядок наведи!!!
С достаточным опытом в сишке никакой раст не нужен. За следующие десять лет еще опыта поднаберут разработчики, и можно будет пользоваться.
Я тут вчера покопался в коде утилитки которую написал 10 лет назад. Свежий компилятор указал на баг в (!'\n' == buf[li]) -- скобочка не там, ну, исправил. Даже не заметил, использовалась она все эти годы. Это была проверка на некорректные данные. Заметил бы я ошибку без помощи компилятора? Ещё в одном месте было выделение из кучи в принте, поменял на выделение на стеке (валгринд жаловался). Ну и по мелочи подвигал код, как вообще можно улучшить код на си? Он же идеален.
Если сейчас погромисты на си путаются в указателях, то на расте будут путаться между a+b и a+c
> Если сейчас погромисты на си путаются в указателях, то на расте будут
> путаться между a+b и a+cзато это будут наши a и c (мои и индуса), а не васи-хацкера
Вот погромисты, которые не знают о существовании оператора !=, громче всех про rust и кукарекают.
скоро начнут путать приоритеты * и +
> скоро начнут путать приоритеты * и +всегда путали (в том числе и на Си, на асемблере тока не путали)
Скорее всего наоборот: те кто знают о существовании такого оператора и думают, что лучше инвертировать смысл (особенно когда там по соседству несколько проверок в духе !(0) && !(0)).
В итоге закономерно страдают. Всё правильно.
!'\n' - это прекрасно. А != никак нельзя было?
> Я тут вчера покопался в коде утилитки которую написал 10 лет назад. Свежий компилятор указал на баг в (!'\n' == buf[li])Видимо писали ещё не выучив ни операции ни приоритеты.
PS. я когда начинал учить С первым делом зазубрил приоритеты, вторым стадии трансляции.
> Видимо писали ещё не выучив ни операции ни приоритеты.ну, это маловероятно, я всё же ставлю на неверно размещённую скобочку (иначе бы её там вообще не было, да и логические операции всегда везде последними идут)
> PS. я когда начинал учить С первым делом зазубрил приоритеты, вторым стадии
> трансляции.это полезно только для того, чтобы знать в каком порядке изменится i=i+(++i+i++) и есть более полезные вещи на самом деле (кроме того, почему-то менее квалифицированные специалисты очень косо смотрят на такой код, видимо, завидуют, не иначе)
пс. да, там где-то рядом было ещё в духе i=i+(++i+i++) только с битовым отрицанием (не припомню зачем, но красивее было никак).
> кроме того, почему-то менее квалифицированные специалисты очень косо смотрят на такой код, видимо, завидуют, не иначеБолее квалифицированные программисты за такой код лупят по заднице ремнём: это UB.
Видимо, 30 лет опыта разработчикам не хватило.
Настолько тонко что даже толсто))
У Вас integer overflow? :]
Тоесть получается сишке нужно 58 лет учиться?Но есть ли гарантии что через 10 программисты таки научатся на ней писать?
А если 10 лет не хватит?
на расте такое сложно написать, ещё никто не смог
> на расте такое сложно написать, ещё никто не смогхм, и правда, в redox ipv6 пока не завезли
но ipv4 же есть и функционал сравним?
>rust, приди!! порядок наведи!!!Братство свидетелей святого Rust.
Нет это весёлые тролли. Не обращайте внимания. Они сами исчезнут.
Отродясь такого не бывало, и опять то же самое!
> Степень опасности проблемы и возможность
> создания эксплоита не уточняется.А что так? Не хотят давать возможность для ловли лулзов?
Да ладно, мы уже привыкли...
Да там как обычно, надо сырцы эксплоита патчить под свою систему, компилять и запускать под рутом, чтобы хоть какой-то отклик получить.
Мда, ещё более бессодерждательно нежели недавняя новость про "дыры в netbsd" (по меньшей мере 3-4 из которых тот же исследователь тремя годами ранее нашёл в openbsd без какого либо дополнительного освещения).Про текущее: там даже в ссылках на еррату более вопиющее есть (например: Incorrect use of getpeername(2) storage for outgoing IPv6 connections corrupts stack memory), а если прошлые почитать, там похожего ещё вагон (как и примерно везде).
В чём событие - не понятно, в общем. Как будто никогда такого не было )
> Про текущее: там даже в ссылках на еррату более вопиющее есть (например: Incorrect use of getpeername(2) storage for outgoing IPv6 connections corrupts stack memory),Ну там "outgoing IPv6 connections", а здесь, по сути, есть ненулевая вероятность словить выполнение кода простой отправкой пакета, как недавно в Windows (https://www.zerodayinitiative.com/blog/2020/10/13/the-octobe...). Особенно в Google Project Zero любят из use-after-free багов, на которые кричат, что они не опасны, делать рабочие эксплоиты.
Лучше может быть только безусловное выполнение от рута любой присланной извне команды в network manager, Там, кстати, текстовый скрипт был.
Ну и не такая большая вероятность RCE, на самом деле, зависит очень от многого.Насколько тут большая проблема мне пока не понятно. Но я, по крайней мере, теперь вижу смысл в новости: https://twitter.com/m00nbsd/status/1321524807473782784 - тут намекают, что RCE таки возможен.
Тогда всё интереснее. Посмотрим.
Немного повтыкал я в суть проблемы.
Ты прав, весьма похоже на CVE-2020-16898. Там правда вроде не uaf (хотя я глубоко не погружался). А в остальном довольно похоже: не слишком высокий шанс на успешную эксплуатацию + возможность эксплуатации только внутри локальной сети.
Но если таки всё сложится, то, по-видимому, возможно RCE.Ещё напомнило CVE-2007-1365.
Ядро 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% производительности.
О даа! Тео ЛИЧНО запретил, мммм, не знаю, портировать KASAN из netbsd ради 1% производительности! Конечно, дело ни в коем случае, например, не в том, что свободных рук не хватает или не в чём-то похожем!
Жаль, когда портировали, например, KUBSAN из netbsd Тео потерял бдительность и примерно -2% производительности прорвались в ядро!---
Спой лучше ещё раз про DAC, иксперд.
PS: а если бы kasan таки портировали или что-то аналогичное по смыслу - было бы неплохо, да.
> ещё раз про DACДля тебя персонально, в DAC необходимо также включать процессы в оперативке!
Покажи вывод:
ls -l /proc
>> ещё раз про DAC
> Для тебя персонально, в DAC необходимо также включать процессы в оперативке!
> Покажи вывод:
> ls -l /procuname && ls -l /proc
OpenBSD
colorls: /proc: No such file or directory
А, да, 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 +/- аналогично по смыслу).
Потому что нельзя сделать ничего хорошего обкладывая плохо написанные программы костылями, чтобы они работали правильно. Надо исправлять ошибки, а не нагромождать вокруг потенциальных ошибок костыли. Сами по себе костыли эти может не так и дорого стоят, а вот все вместе - уже ощутимо. А по-отдельности в них смысла просто нет.
> В ядре openbsd это есть и ЕМНИП появилось там это раньше чем в linux.Нет. В виде неофициальных патчей к ядру Linux была раньше.
> Про ссылки на pax, которые я перечитал чуть менее по диагонали
По ссылкам правильная и быстрая реализация очистки памяти при освобождении.
> Потому что нельзя сделать ничего хорошего обкладывая плохо написанные программы костылями, чтобы они работали правильно.
Это единственный путь который дает гарантии безопасности. Другого просто не существует. Процессор с ядром OS должен следить за корректность работы программы. Самим программам/компиляторам доверять нельзя.
> Надо исправлять ошибки, а не нагромождать вокруг потенциальных ошибок костыли. Сами по себе костыли эти может не так и дорого стоят, а вот все вместе - уже ощутимо. А по-отдельности в них смысла просто нет.
Ошибки были есть и будут. Технологии защиты много ресурсов не требуют. Сегодня не 1980-тые, ресурсов процессора хватает с избытком.
>> В ядре openbsd это есть и ЕМНИП появилось там это раньше чем в linux.
> Нет. В виде неофициальных патчей к ядру Linux была раньше.И именно поэтому всем на это начхать.
>> Потому что нельзя сделать ничего хорошего обкладывая плохо написанные программы костылями, чтобы они работали правильно.
> Это единственный путь который дает гарантии безопасности. Другого просто не существует.
> Процессор с ядром OS должен следить за корректность работы программы. Самим
> программам/компиляторам доверять нельзя.Нет, это костыльный и неправильный путь, сиюминутное решение вместо правильного.
Если в программе ошибка (т.е. именно программа работает неправильно) надо не лепить костыли, заставляющие ядро помогать программе работать правильно, а устранять ошибку.И работать надо в первую очередь над тем, чтобы ошибок было как можно меньше. Подход с нахлобучиванием костылей приведёт к тому, что у нас будет куча странно работающего кода, непонятно как взаимодействующего друг с другом и непредсказуемо падающего.
> Ошибки были есть и будут. Технологии защиты много ресурсов не требуют. Сегодня
> не 1980-тые, ресурсов процессора хватает с избытком.И это не повод бедумно просирать их, а не то снова не будет хватать. Но в первую очередь дело не в этом, а в простоте архитектуры и прозрачности конструкции. Какой шанс, что эту ошибку бы нашли и исправили, если бы в ядре были костыли, которые предотвращают её эксплуатацию как уязвимости? Очень незначительные, т.е. изредка ядро могло бы случайным образом падать, например. Делает ли такой подход ОС лучше? Нет, он добавляет лишь избыточную сложность и маскирует проблему.
Нужно расширять средства, которые позволят найти и устранить как можно больше подобных и не только ошибок, а также техники снижающие вред от попыток эксплуатации тех ошибок, что найти не удалось - w^X, KASLR/KARL и т.п.
> Нет, это костыльный и неправильный путь, сиюминутное решение вместо правильного.Строгий контроль со стороны процессора и ядра OS -- единственное решение которое дает гарантии невозможности эксплуатации уязвимостей.
> Если в программе ошибка (т.е. именно программа работает неправильно) надо не лепить костыли, заставляющие ядро помогать программе работать правильно, а устранять ошибку.
Плевать на программистов, языки программирования и компиляторы. Ошибки - были, есть и будут (компилятор тоже важен: генерация позиционно независимого кода для работы ASLR, канарейки для защиты от переполнения стека SSP, автоматическая фортификация небезопасны функций; и правильная работа линковщика тоже важна: ....).
Строгий контроль со стороны процессора и ядра OS -- единственное решение которое дает гарантии невозможности эксплуатации уязвимостей.
> Какой шанс, что эту ошибку бы нашли и исправили, если бы в ядре были костыли, которые предотвращают её эксплуатацию как уязвимости? Очень незначительные, т.е. изредка ядро могло бы случайным образом падать, например. Делает ли такой подход ОС лучше?
Ты даже сути проблемы не понимаешь. Если процессор с ядром OS не контролирую память то при наличии ошибки будет эксплуатируемая уязвимость которую вирусы будут незаметно использовать. Если защита со стороны процессора и OS реализована, то при наличии ошибки, например переполнения буфера, попытка эксплуатации ее вирусом будет присечена, а сам факт задокументирован в системном журнале, отослан по почте и станет сразу известен. Конечно известную ошибку исправят быстрее. Строгий контроль со стороны процессора и ядра OS -- единственное решение которое дает гарантии невозможности эксплуатации уязвимостей.
> Нужно расширять средства, которые позволят найти и устранить как можно больше подобных и не только ошибок, а также техники снижающие вред от попыток эксплуатации тех ошибок, что найти не удалось - w^X, KASLR/KARL и т.п.
Они уже есть. Надо их просто использовать. Почему в дистрибутивах не используют средства защиты от разных уязвимостей, а вместо этого внедряют средства препятствующие защите: JIT, ...?
Строгий контроль граждан государством - единственный способ избежать революции.Нет.
Это так не работает.
В сложных системах есть много сложных факторов.
Ну например уязвимости в средствах контроля.
Привет интелME. Привет секурбут.Ну а дальше системные неустранимые недостатки, вроде Си процессоров в которых ни о каком контроле и речи не идет и Си программ которые тоже ничего о разделении памяти не знают.
То, что вы называете "контролем" у нормальных людей называется управление памятью.
И в лисп машинах было 30 лет назад сделано. А так же во всяких приличных ЦП для Ады.
> Ну например уязвимости в средствах контроля.В свободном ПО есть возможность независимой верификации. Средства контроля просты.
> Привет интелME.
Исходя из темы обсуждения привет надо передавать Intel NX. Проблемы с этой инструкцией уже были в ранних версия Pentium4. Есть вариант чисто программой защиты, без использования специальных инструкций процессора, на пару процентов снизит производительность.
> Привет секурбут.
SecureBOOT, TPM - хорошие вещи. Производителям кроме верификации по цифровым подписям стоит добавить на платы джемпер физически запрещающий запись в SPI где хранится UEFI/BIOS.
> Ну а дальше системные неустранимые недостатки, вроде Си процессоров в которых ни о каком контроле и речи не идет
Компилять только на отключенных от сети компах.
Система повторяемые сборок для верификации бинарей.
> Си программ которые тоже ничего о разделении памяти не знают.
Им и знать не надо. YAMA в ядре Linux знает.
> В свободном ПО есть возможность независимой верификации. Средства контроля просты.И поэтому постоянно находят всё новые и новые ошибки, наберите воздуха, готовы? переполнения буфера.
> Исходя из темы обсуждения привет надо передавать Intel NX.
Да всему этому x86/RISC цирку нужно привет передавать.
> SecureBOOT, TPM - хорошие вещи.
Для ограничения свободы пользователей.
> Компилять только на отключенных от сети компах.
Как это поможет с концептуальными недостатками сишки?
> Система повторяемые сборок для верификации бинарей.
Это далеко не все линуксы освоили для ядра хотя бы.
Это хорошо конечно всё и замечательно.
Но что-то с индустрией принципиально не так если требуются титанические усилия для создания системы повторяемой сборки.
Вообще, кроме GuixSD кто-то это из линуксов обеспечивает?> Им и знать не надо. YAMA в ядре Linux знает.
You known nothing, YAMA Linux.
> Строгий контроль со стороны процессора и ядра 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 может и не иметь в себе эксплуатируемых уязвимостей.
> Профессионализм программистовКомпилятор с хорошими опциями компиляции укажет программисту на ошибки безопасности.
Вот профессионализм проявляется тогда когда программист сам исправляет ошибки по рекомендации компилятора. Когда исправляет после багрепорта тоже еще можно терпеть.
> портирование ядерной защиты на другую архитектуру будет неадекватно сложно.
Это тема большого отдельного разговора. По этому поводу я согласен с Н. Виртом.
> высказывания линуса и шпенглера по поводу этих патчей
Они не любят PaX & Grsecurity и противятся включению этих патчей в ядро уже 20 лет. То что включается в ядро, не все но часть дырява и сделана хуже чем в оригинальном PaX & Grsecurity.
> У тебя какая-то болезненая фиксация на jit.
Да, причем очень заостренная. Иначе пионеры этот JIT напихают во весь софт. У меня строгая реализация защиты не допускающая любого JIT, соответственно ПО которое не собирается без JIT у меня и на многих архитектура процессоров mips, ppc, ... просто не будет работать. Мы не можем использовать ПО с JIT по этому и громко кричим, что JIT - зло и надо во всех программах иметь опцию configure --jitless --no-jit для сборки проги без JIT.
> реализация jit даже и требующая W|X может и не иметь в себе эксплуатируемых уязвимостей.
Гарантий отсутствия уязвимостей вылизывая код с JIT не получишь.
А ядро OS с процессором может дать гарантии отсутствия эксплуатации уязвимостей переполнения буфера.
> Они не любят PaX & GrsecurityОни - это кто? Линус и Шпенглер? Ничего, что Brad Spengler - это как раз из grsec?)
> сделана хуже чем в оригинальном PaX & Grsecurity.
А обосновать почему PAX_SECSTACK им. Попова из Ptsecurity хуже оригинального своими словами рассказать сможешь?)
> JIT - зло и надо во всех программах иметь опцию configure --jitless --no-jit для сборки проги без JIT.
Жаль, что ты не способен понимать даже то, что ты сам пишешь. Ну зачем делать опции "jitless", если jit вообще не нужен?
По существу: нет, не надо.> может дать гарантии
О, ты пошёл очередной круг нарезать. Я сливаюсь, у меня уже и так отпечаток ладони на лице который день болит.
> Мда, ещё более бессодерждательно_remote_ code exec, куда еще содержательней?
> например: Incorrect use of getpeername
это local по сути - вызывается действиями на стороне системы.
> там похожего ещё вагон (как и примерно везде)
не везде же "in a heck of a long time..." а, простите, имелось в виду - выключенной из розетки?
> _remote_ code exec, куда еще содержательней?А это изначально из текста новости было неясно. Ссылку на твиттер Вилларда в неё добавил я, до этого про RCE там ни слова не было. А uaf не всегда = RCE.
> это local по сути - вызывается действиями на стороне системы.
Ну да, к моменту когда стало понятно про шанс на RCE это уже стало менее удачным примером.
> не везде же "in a heck of a long time..." а, простите, имелось в виду - выключенной из розетки?
Ну так себе.
Других uaf там тоже немало, в т.ч. найденных тем же исследователем - да вот хотя бы: https://www.openbsd.org/errata62.html#p007_etheripЧто касается этого - формально повод изменить слоган есть, что будет по факту я не знаю и зависит это, очевидно, не от меня. И лично для меня это ничего не изменит.
Code exec-то, конечно, remote со всеми вытекающими, только возможен он, насколько я понимаю, лишь в локальной сети и с некоторой вероятностью, отличной от 1, с риском обрушить ядро в случае неуспеха.
Так что не удивлюсь, если со слоганом ничего не случится.
никогда не использовал ipv6, но в этот раз точно буду. протокол от народа.
правильно, должен же кто-то за "дефицитные" ipv4 платить, всего 2 бакса в месяц за право аренды 4 байтов и они ваши - а что поделать, байтов на всех не хватает, поразвели компьютеров и мобил, понимаешь
** Only two remote holes in the default install, in a heck of a long time!
**сайт забыли обновить, там уже давно не two )
Там просто речь всегда идет о двух последних найденных дырах. А те, что до них, это уже "very long time. Longer than anyone can remember."
Наверняка список найденных дыр золотая рыбка обновляла.
Надо устроить опрос, что, по мнению опеннетовских аналитиков, более эффективно против подобных уязвимостей:
неиспользование ipv6 или неиспользование Си?
Неиспользование C более мощно. Оно автоматически влечёт неиспользование IPv6..., а также IPv4 и всех остальных подсистем ядра.
Как хорошо, что я запрещаю ипв6 ещё при установке:-)
А когда он появится у твоего провайдера, что делать будешь?
> А когда он появится у твоего провайдера, что делать будешь?Попробую муравью хрен приделать -;)
Он не появится, ибо бесполезен.
Расскажи, сколько провайдеров в Штатах раздают белые IPv6 обладателям яойфонов? Ой, все за натом, почему-то...
> Расскажи, сколько провайдеров в Штатах раздают белые IPv6 обладателям яойфонов? Ой, все
> за натом, почему-то...Если обычного юзера с ведром или гейфоном, с хромобраузером на борту выпустить в сеть с белым айп , то либо кирпич, либо часть ботнета. И опсосы об этом знают, потому никакого ипв6, к счастью, не будет.
На гейфонах нет хромобраузера. Если что.
Будет. Всё будет.Алсо, белый опи v6 не так работает как v4.
> Будет. Всё будет.
> Алсо, белый опи v6 не так работает как v4.Его тоже прекрасно трахают. И работает он также
> Его тоже прекрасно трахают. И работает он такжеТак он и должен трахаться, в этом вся суть.
ботнетом они и так становятся, наставив апкшек от неПети, а кирпич вообще проблемы юзерей, с другой стороны оборудование для nat не бесплатное и требует обсдуги и электричества, однажды будет соблазн просто утилизировать это
Уважаемые Анонимные Эксперты!Напоминаю Вам, что с каждой загрузкой в OpenBSD новое уникальное ядро.
И если цель не просто крэшнуть ядро, а получить рута нужно правильно вычислить memory layout ядра и лишь потом можно будет предпринять попытку захвата контроля. Ошибка на любом этапе приведёт к повреждению ядра и остановке системы.Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно. Если только кто-то не будет заботливо поднимать систему до тех пор, пока у атакующего не наступит успех. Кстати, после перезагрузки ядро будет уже снова другое.
> Уважаемые Анонимные Эксперты!
> Напоминаю Вам, что с каждой загрузкой в OpenBSD новое уникальное ядро.
> И если цель не просто крэшнуть ядро, а получить рута нужно правильно
> вычислить memory layout ядра и лишь потом можно будет предпринять попытку
> захвата контроля. Ошибка на любом этапе приведёт к повреждению ядра и
> остановке системы.
> Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно. Если только
> кто-то не будет заботливо поднимать систему до тех пор, пока у
> атакующего не наступит успех. Кстати, после перезагрузки ядро будет уже снова
> другое.Уважаемый Разработчик! Если система с опенбсд на борту используется в качестве шлюза, ее падение означает прекращение работы офиса/васян локалки. Это богоподобные Разработчики Неуязвимой ОС уязвимостью не считают?
>Если система с опенбсд на борту используется в качестве шлюза, ее падение означает прекращение работы офиса/васян локалки.А если используется линукс, виндовс, или проприетарная ос, её падение не будет означать тогоже?
>>Если система с опенбсд на борту используется в качестве шлюза, ее падение означает прекращение работы офиса/васян локалки.
> А если используется линукс, виндовс, или проприетарная ос, её падение не будет
> означать тогоже?Как это оправдывает опенбсд?
> Как это оправдывает опенбсд?От чего оправдывает? Кто-то в чем-то обвиняет OpenBSD?
Мы тут на суде?
> Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно.Брутфорсить не обязательно, надо подождать когда найдут очередной способ обойти aslr, потому что где-нибудь что-нибудь в кеше каком-нибудь осело, или ещё как-нибудь информация об адресах раскрылась.
>> Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно.
> Брутфорсить не обязательно, надо подождать когда найдут очередной способ обойти aslr, потому
> что где-нибудь что-нибудь в кеше каком-нибудь осело, или ещё как-нибудь информация
> об адресах раскрылась.Удалённо?
>>> Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно.
>> Брутфорсить не обязательно, надо подождать когда найдут очередной способ обойти aslr, потому
>> что где-нибудь что-нибудь в кеше каком-нибудь осело, или ещё как-нибудь информация
>> об адресах раскрылась.
> Удалённо?Это по-разному бывает. Дыры довольно непредсказуемые вещи. Посмотри на современные эксплоиты, которые берут и увязывают десяток разных багов (каждый из которых даже дырой не назвать -- просто баг) в одну огромную зияющую дырень.
> Это по-разному бывает.Согласен. Но всё же удалённая утечка инфы о структурах ядра - имхо, это что-то, что тянет на отдельную уязвимость.
Тео про еррату, степень опасности, слоган и пр.:"We've released the errata as security because it is possibly exploitable
or could cause a crash, and we have a rapid fix release process. It was
released without even seeing any evidence of a remote crash, nor any
evidence of a remote exploit. Incorrect code gets fixed, and if we
judge it important we release a fix to the public in expedited fashion,
and apparently get judged for doing so.Now that the fix is released and deployed by most openbsd users, we
quickly become uncurious and head back to other work. The only
conversations related to this are asking how we can harden the mbuf
layer to avoid similar issues in the future.I guess many other operating systems would wait weeks or months to
collect all the "facts" and make a fancy disclosure, but we shipped
source and binary fixes in just over 24 hours.So, is it a remote crash? Possibly, but we'd like to see a packet
that causes it.Next after that, is it a remote exploit?
I think it is fair to wait for facts."
Запасаемся попкорном и ждём продолжения (эксплоита?).
ping of the death? опять? на чужих ошибках учиться не того? почему это сейчас, а не 10 лет назад то? это первый кто код ipv6 в bsd прочитал?