| |
| 2.9, Аноним (9), 23:07, 28/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Как ни странно, исправить баг на "опасном" си - быстрее и проще, чем написать на "безопасном" расте.
| | |
| |
| 3.35, Аноним (1), 10:07, 29/10/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
При чем тут си?
Просто сссупербезопасная ось (в очередной раз) оказалась просто неуловимым Джо, который нафиг никому не сдался.
| | |
| |
| 4.57, анонимуслинус (?), 23:59, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
нет просто ipv6 еще долго будет всем отдаваться икотой от его проблем. пока не вычистят стандарт и реализации. как было с ipv4|.
| | |
|
| 3.37, Аноним (37), 10:31, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Только божественно одаренный мог сравнить трудоемкость исправления ошибки в одной функции огромной системы, форкнутой от другой системы, написанной на Си в лохматые годы и трудоемкость написания такой же ОС на относительно безопасном языке, в которой такой ошибки и не возникло бы. Но кто знает, может со временем новый Тео де Раадт, также повернутый на безопасности, напишет какую-нибудь OpenRedox форкнув Redox и там такие ошибки всплывать будут значительно реже, разве что в каких-нибудь кастомных/проприетарных драйверах юзерспейса, написанных в unsafe-режиме.
| | |
|
|
| 1.2, JL2001 (ok), 22:18, 28/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 > использованию уже освобождённой области памяти mbuf (use-after-free)
rust, приди!! порядок наведи!!!
| | |
| |
| 2.3, Аноним (-), 22:24, 28/10/2020 [^] [^^] [^^^] [ответить]
| +12 +/– |
С достаточным опытом в сишке никакой раст не нужен. За следующие десять лет еще опыта поднаберут разработчики, и можно будет пользоваться.
| | |
| |
| 3.7, Аноним (7), 22:58, 28/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Я тут вчера покопался в коде утилитки которую написал 10 лет назад. Свежий компилятор указал на баг в (!'\n' == buf[li]) -- скобочка не там, ну, исправил. Даже не заметил, использовалась она все эти годы. Это была проверка на некорректные данные. Заметил бы я ошибку без помощи компилятора? Ещё в одном месте было выделение из кучи в принте, поменял на выделение на стеке (валгринд жаловался). Ну и по мелочи подвигал код, как вообще можно улучшить код на си? Он же идеален.
| | |
| |
| 4.10, Аноним (9), 23:12, 28/10/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
Если сейчас погромисты на си путаются в указателях, то на расте будут путаться между a+b и a+c
| | |
| |
| 5.25, JL2001 (ok), 06:44, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Если сейчас погромисты на си путаются в указателях, то на расте будут
> путаться между a+b и a+c
зато это будут наши a и c (мои и индуса), а не васи-хацкера
| | |
|
| 4.13, Аноним (13), 23:52, 28/10/2020 [^] [^^] [^^^] [ответить]
| +9 +/– |
Вот погромисты, которые не знают о существовании оператора !=, громче всех про rust и кукарекают.
| | |
| |
| |
| 6.43, JL2001 (ok), 15:42, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> скоро начнут путать приоритеты * и +
всегда путали (в том числе и на Си, на асемблере тока не путали)
| | |
|
| 5.16, Аноним (7), 00:15, 29/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Скорее всего наоборот: те кто знают о существовании такого оператора и думают, что лучше инвертировать смысл (особенно когда там по соседству несколько проверок в духе !(0) && !(0)).
| | |
|
| 4.49, Аноним (49), 18:48, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Я тут вчера покопался в коде утилитки которую написал 10 лет назад. Свежий компилятор указал на баг в (!'\n' == buf[li])
Видимо писали ещё не выучив ни операции ни приоритеты.
PS. я когда начинал учить С первым делом зазубрил приоритеты, вторым стадии трансляции.
| | |
| |
| 5.52, Аноним (7), 19:17, 29/10/2020 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Видимо писали ещё не выучив ни операции ни приоритеты.
ну, это маловероятно, я всё же ставлю на неверно размещённую скобочку (иначе бы её там вообще не было, да и логические операции всегда везде последними идут)
> PS. я когда начинал учить С первым делом зазубрил приоритеты, вторым стадии
> трансляции.
это полезно только для того, чтобы знать в каком порядке изменится
i=i+(++i+i++) и есть более полезные вещи на самом деле (кроме того, почему-то менее квалифицированные специалисты очень косо смотрят на такой код, видимо, завидуют, не иначе)
| | |
| |
| 6.53, Аноним (7), 19:21, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
пс. да, там где-то рядом было ещё в духе
i=i+(++i+i++) только с битовым отрицанием (не припомню зачем, но красивее было никак).
| | |
| 6.59, Ordu (ok), 05:55, 30/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > кроме того, почему-то менее квалифицированные специалисты очень косо смотрят на такой код, видимо, завидуют, не иначе
Более квалифицированные программисты за такой код лупят по заднице ремнём: это UB.
| | |
|
|
|
| 3.71, Аноньимъс (?), 10:36, 31/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
 Тоесть получается сишке нужно 58 лет учиться?
Но есть ли гарантии что через 10 программисты таки научатся на ней писать?
А если 10 лет не хватит?
| | |
|
| |
| 3.24, JL2001 (ok), 06:42, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> на расте такое сложно написать, ещё никто не смог
хм, и правда, в redox ipv6 пока не завезли
но ipv4 же есть и функционал сравним?
| | |
|
| 2.36, Аноним (34), 10:09, 29/10/2020 [^] [^^] [^^^] [ответить]
| –3 +/– | |
>rust, приди!! порядок наведи!!!
Братство свидетелей святого Rust.
| | |
| |
| 3.75, Аноним (-), 16:25, 31/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Нет это весёлые тролли. Не обращайте внимания. Они сами исчезнут.
| | |
|
|
| 1.8, Аноним (-), 23:00, 28/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
> Степень опасности проблемы и возможность
> создания эксплоита не уточняется.
А что так? Не хотят давать возможность для ловли лулзов?
Да ладно, мы уже привыкли...
| | |
| |
| 2.11, Аноним (9), 23:14, 28/10/2020 [^] [^^] [^^^] [ответить]
| –4 +/– |
Да там как обычно, надо сырцы эксплоита патчить под свою систему, компилять и запускать под рутом, чтобы хоть какой-то отклик получить.
| | |
|
| 1.12, Дон Ягон (ok), 23:14, 28/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Мда, ещё более бессодерждательно нежели недавняя новость про "дыры в netbsd" (по меньшей мере 3-4 из которых тот же исследователь тремя годами ранее нашёл в openbsd без какого либо дополнительного освещения).
Про текущее: там даже в ссылках на еррату более вопиющее есть (например: Incorrect use of getpeername(2) storage for outgoing IPv6 connections corrupts stack memory), а если прошлые почитать, там похожего ещё вагон (как и примерно везде).
В чём событие - не понятно, в общем. Как будто никогда такого не было )
| | |
| |
| 2.15, Аноним (15), 00:14, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Про текущее: там даже в ссылках на еррату более вопиющее есть (например: 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-october-2020-security-up). Особенно в Google Project Zero любят из use-after-free багов, на которые кричат, что они не опасны, делать рабочие эксплоиты.
| | |
| |
| 3.18, Аноним (7), 00:41, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Лучше может быть только безусловное выполнение от рута любой присланной извне команды в network manager, Там, кстати, текстовый скрипт был.
| | |
| 3.21, Дон Ягон (ok), 03:42, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Немного повтыкал я в суть проблемы.
Ты прав, весьма похоже на CVE-2020-16898. Там правда вроде не uaf (хотя я глубоко не погружался). А в остальном довольно похоже: не слишком высокий шанс на успешную эксплуатацию + возможность эксплуатации только внутри локальной сети.
Но если таки всё сложится, то, по-видимому, возможно RCE.
Ещё напомнило CVE-2007-1365.
| | |
| |
| |
| 5.42, Дон Ягон (ok), 13:03, 29/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
О даа! Тео ЛИЧНО запретил, мммм, не знаю, портировать KASAN из netbsd ради 1% производительности! Конечно, дело ни в коем случае, например, не в том, что свободных рук не хватает или не в чём-то похожем!
Жаль, когда портировали, например, KUBSAN из netbsd Тео потерял бдительность и примерно -2% производительности прорвались в ядро!
---
Спой лучше ещё раз про DAC, иксперд.
PS: а если бы kasan таки портировали или что-то аналогичное по смыслу - было бы неплохо, да.
| | |
| |
| 6.63, Аноним (63), 16:16, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> ещё раз про DAC
Для тебя персонально, в DAC необходимо также включать процессы в оперативке!
Покажи вывод:
ls -l /proc
| | |
| |
| 7.64, Дон Ягон (ok), 17:02, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> ещё раз про DAC
> Для тебя персонально, в DAC необходимо также включать процессы в оперативке!
> Покажи вывод:
> ls -l /proc
uname && ls -l /proc
OpenBSD
colorls: /proc: No such file or directory
| | |
|
|
| 5.58, Дон Ягон (ok), 01:15, 30/10/2020 [^] [^^] [^^^] [ответить]
| +2 +/– | |
А, да, 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 +/- аналогично по смыслу).
Потому что нельзя сделать ничего хорошего обкладывая плохо написанные программы костылями, чтобы они работали правильно. Надо исправлять ошибки, а не нагромождать вокруг потенциальных ошибок костыли. Сами по себе костыли эти может не так и дорого стоят, а вот все вместе - уже ощутимо. А по-отдельности в них смысла просто нет.
| | |
| |
| 6.62, Аноним (63), 16:08, 30/10/2020 [^] [^^] [^^^] [ответить] | +/– | Нет В виде неофициальных патчей к ядру Linux была раньше По ссылкам правильная... большой текст свёрнут, показать | | |
| |
| 7.65, Дон Ягон (ok), 18:15, 30/10/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
>> В ядре openbsd это есть и ЕМНИП появилось там это раньше чем в linux.
> Нет. В виде неофициальных патчей к ядру Linux была раньше.
И именно поэтому всем на это начхать.
>> Потому что нельзя сделать ничего хорошего обкладывая плохо написанные программы костылями, чтобы они работали правильно.
> Это единственный путь который дает гарантии безопасности. Другого просто не существует.
> Процессор с ядром OS должен следить за корректность работы программы. Самим
> программам/компиляторам доверять нельзя.
Нет, это костыльный и неправильный путь, сиюминутное решение вместо правильного.
Если в программе ошибка (т.е. именно программа работает неправильно) надо не лепить костыли, заставляющие ядро помогать программе работать правильно, а устранять ошибку.
И работать надо в первую очередь над тем, чтобы ошибок было как можно меньше. Подход с нахлобучиванием костылей приведёт к тому, что у нас будет куча странно работающего кода, непонятно как взаимодействующего друг с другом и непредсказуемо падающего.
> Ошибки были есть и будут. Технологии защиты много ресурсов не требуют. Сегодня
> не 1980-тые, ресурсов процессора хватает с избытком.
И это не повод бедумно просирать их, а не то снова не будет хватать. Но в первую очередь дело не в этом, а в простоте архитектуры и прозрачности конструкции. Какой шанс, что эту ошибку бы нашли и исправили, если бы в ядре были костыли, которые предотвращают её эксплуатацию как уязвимости? Очень незначительные, т.е. изредка ядро могло бы случайным образом падать, например. Делает ли такой подход ОС лучше? Нет, он добавляет лишь избыточную сложность и маскирует проблему.
Нужно расширять средства, которые позволят найти и устранить как можно больше подобных и не только ошибок, а также техники снижающие вред от попыток эксплуатации тех ошибок, что найти не удалось - w^X, KASLR/KARL и т.п.
| | |
| |
| 8.70, Аноним (70), 10:27, 31/10/2020 [^] [^^] [^^^] [ответить] | +/– | Строгий контроль со стороны процессора и ядра OS -- единственное решение которое... большой текст свёрнут, показать | | |
| |
| |
| 10.80, Аноним (80), 08:12, 01/11/2020 [^] [^^] [^^^] [ответить] | –1 +/– | В свободном ПО есть возможность независимой верификации Средства контроля прост... большой текст свёрнут, показать | | |
|
| 9.78, Дон Ягон (ok), 22:05, 31/10/2020 [^] [^^] [^^^] [ответить] | +1 +/– | В твоих устах это больше похоже на религиозную мантру, чем на аргумент Баги и д... большой текст свёрнут, показать | | |
| |
| 10.81, Аноним (80), 08:35, 01/11/2020 [^] [^^] [^^^] [ответить] | +/– | Компилятор с хорошими опциями компиляции укажет программисту на ошибки безопасно... большой текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 2.32, пох. (?), 09:31, 29/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Мда, ещё более бессодерждательно
_remote_ code exec, куда еще содержательней?
> например: Incorrect use of getpeername
это local по сути - вызывается действиями на стороне системы.
> там похожего ещё вагон (как и примерно везде)
не везде же "in a heck of a long time..." а, простите, имелось в виду - выключенной из розетки?
| | |
| |
| 3.41, Дон Ягон (ok), 12:54, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> _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, с риском обрушить ядро в случае неуспеха.
Так что не удивлюсь, если со слоганом ничего не случится.
| | |
|
|
| 1.20, б.б. (?), 03:31, 29/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
никогда не использовал ipv6, но в этот раз точно буду. протокол от народа.
| | |
| |
| 2.87, Аноним (87), 20:49, 22/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
правильно, должен же кто-то за "дефицитные" ipv4 платить, всего 2 бакса в месяц за право аренды 4 байтов и они ваши - а что поделать, байтов на всех не хватает, поразвели компьютеров и мобил, понимаешь
| | |
|
| 1.22, Аноним (22), 05:26, 29/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
** Only two remote holes in the default install, in a heck of a long time!
**
сайт забыли обновить, там уже давно не two )
| | |
| |
| 2.27, Аноним (27), 08:09, 29/10/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Там просто речь всегда идет о двух последних найденных дырах. А те, что до них, это уже "very long time. Longer than anyone can remember."
| | |
|
| 1.38, Аноним (38), 10:44, 29/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Надо устроить опрос, что, по мнению опеннетовских аналитиков, более эффективно против подобных уязвимостей:
неиспользование ipv6 или неиспользование Си?
| | |
| |
| 2.45, Аноним (34), 16:00, 29/10/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Неиспользование C более мощно. Оно автоматически влечёт неиспользование IPv6..., а также IPv4 и всех остальных подсистем ядра.
| | |
|
| |
| |
| 3.46, псевдонимус (?), 16:41, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> А когда он появится у твоего провайдера, что делать будешь?
Попробую муравью хрен приделать -;)
Он не появится, ибо бесполезен.
| | |
| 3.50, Аноним (9), 18:49, 29/10/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
Расскажи, сколько провайдеров в Штатах раздают белые IPv6 обладателям яойфонов? Ой, все за натом, почему-то...
| | |
| |
| 4.54, псевдонимус (?), 22:28, 29/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Расскажи, сколько провайдеров в Штатах раздают белые IPv6 обладателям яойфонов? Ой, все
> за натом, почему-то...
Если обычного юзера с ведром или гейфоном, с хромобраузером на борту выпустить в сеть с белым айп , то либо кирпич, либо часть ботнета. И опсосы об этом знают, потому никакого ипв6, к счастью, не будет.
| | |
| |
| |
| 6.76, псевдонимус (?), 18:51, 31/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Будет. Всё будет.
> Алсо, белый опи v6 не так работает как v4.
Его тоже прекрасно трахают. И работает он также
| | |
| |
| 7.83, Аноньимъ (ok), 17:02, 01/11/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Его тоже прекрасно трахают. И работает он также
Так он и должен трахаться, в этом вся суть.
| | |
|
|
| 5.88, Аноним (87), 20:52, 22/11/2020 [^] [^^] [^^^] [ответить]
| +/– |
ботнетом они и так становятся, наставив апкшек от неПети, а кирпич вообще проблемы юзерей, с другой стороны оборудование для nat не бесплатное и требует обсдуги и электричества, однажды будет соблазн просто утилизировать это
| | |
|
|
|
|
| 1.47, Аноним (-), 17:43, 29/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Уважаемые Анонимные Эксперты!
Напоминаю Вам, что с каждой загрузкой в OpenBSD новое уникальное ядро.
И если цель не просто крэшнуть ядро, а получить рута нужно правильно вычислить memory layout ядра и лишь потом можно будет предпринять попытку захвата контроля. Ошибка на любом этапе приведёт к повреждению ядра и остановке системы.
Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно. Если только кто-то не будет заботливо поднимать систему до тех пор, пока у атакующего не наступит успех. Кстати, после перезагрузки ядро будет уже снова другое.
| | |
| |
| 2.48, псевдонимус (?), 18:46, 29/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Уважаемые Анонимные Эксперты!
> Напоминаю Вам, что с каждой загрузкой в OpenBSD новое уникальное ядро.
> И если цель не просто крэшнуть ядро, а получить рута нужно правильно
> вычислить memory layout ядра и лишь потом можно будет предпринять попытку
> захвата контроля. Ошибка на любом этапе приведёт к повреждению ядра и
> остановке системы.
> Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно. Если только
> кто-то не будет заботливо поднимать систему до тех пор, пока у
> атакующего не наступит успех. Кстати, после перезагрузки ядро будет уже снова
> другое.
Уважаемый Разработчик! Если система с опенбсд на борту используется в качестве шлюза, ее падение означает прекращение работы офиса/васян локалки. Это богоподобные Разработчики Неуязвимой ОС уязвимостью не считают?
| | |
| |
| 3.74, Аноньимъс (?), 11:02, 31/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
>Если система с опенбсд на борту используется в качестве шлюза, ее падение означает прекращение работы офиса/васян локалки.
А если используется линукс, виндовс, или проприетарная ос, её падение не будет означать тогоже?
| | |
| |
| 4.77, псевдонимус (?), 18:53, 31/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>Если система с опенбсд на борту используется в качестве шлюза, ее падение означает прекращение работы офиса/васян локалки.
> А если используется линукс, виндовс, или проприетарная ос, её падение не будет
> означать тогоже?
Как это оправдывает опенбсд?
| | |
| |
| 5.79, Аноньимъ (ok), 23:22, 31/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Как это оправдывает опенбсд?
От чего оправдывает? Кто-то в чем-то обвиняет OpenBSD?
Мы тут на суде?
| | |
|
|
|
| 2.60, Ordu (ok), 05:59, 30/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно.
Брутфорсить не обязательно, надо подождать когда найдут очередной способ обойти aslr, потому что где-нибудь что-нибудь в кеше каком-нибудь осело, или ещё как-нибудь информация об адресах раскрылась.
| | |
| |
| 3.66, Дон Ягон (ok), 18:16, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно.
> Брутфорсить не обязательно, надо подождать когда найдут очередной способ обойти aslr, потому
> что где-нибудь что-нибудь в кеше каком-нибудь осело, или ещё как-нибудь информация
> об адресах раскрылась.
Удалённо?
| | |
| |
| 4.67, Ordu (ok), 19:13, 30/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>> Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно.
>> Брутфорсить не обязательно, надо подождать когда найдут очередной способ обойти aslr, потому
>> что где-нибудь что-нибудь в кеше каком-нибудь осело, или ещё как-нибудь информация
>> об адресах раскрылась.
> Удалённо?
Это по-разному бывает. Дыры довольно непредсказуемые вещи. Посмотри на современные эксплоиты, которые берут и увязывают десяток разных багов (каждый из которых даже дырой не назвать -- просто баг) в одну огромную зияющую дырень.
| | |
| |
| 5.68, Дон Ягон (ok), 19:44, 30/10/2020 [^] [^^] [^^^] [ответить]
| +/– | |
> Это по-разному бывает.
Согласен. Но всё же удалённая утечка инфы о структурах ядра - имхо, это что-то, что тянет на отдельную уязвимость.
| | |
|
|
|
|
| 1.69, Дон Ягон (ok), 22:13, 30/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Тео про еррату, степень опасности, слоган и пр.:
"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."
Запасаемся попкорном и ждём продолжения (эксплоита?).
| | |
| 1.86, Аноним (-), 20:45, 21/11/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
ping of the death? опять? на чужих ошибках учиться не того? почему это сейчас, а не 10 лет назад то? это первый кто код ipv6 в bsd прочитал?
| | |
|
