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

"Удалённая уязвимость в IPv6-стеке OpenBSD"	+/–
Сообщение от opennews (??), 28-Окт-20, 22:17
В OpenBSD устранена уязвимость в IPv6-стеке, которая может привести к использованию уже освобождённой области памяти mbuf (use-after-free) в процессе генерации ICMP6-ответа на пакет IPv6.... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53985
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 28-Окт-20, 22:17	+8 +/–
Ha-ha, classic!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #9, #34

2. Сообщение от JL2001 (ok), 28-Окт-20, 22:18	–2 +/–
> использованию уже освобождённой области памяти mbuf (use-after-free) rust, приди!! порядок наведи!!!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #5, #36

3. Сообщение от Аноним (-), 28-Окт-20, 22:24	+12 +/–
С достаточным опытом в сишке никакой раст не нужен. За следующие десять лет еще опыта поднаберут разработчики, и можно будет пользоваться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #7, #23, #26, #71

4. Сообщение от Аноним (4), 28-Окт-20, 22:24	+1 +/–
Отродясь такого не бывало, и опять то же самое!
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от Аноним (9), 28-Окт-20, 22:56	+1 +/–
на расте такое сложно написать, ещё никто не смог
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #24

6. Сообщение от Аноним123 (?), 28-Окт-20, 22:56	–1 +/–
ку-ка-ре-ку... in a heck of a long time... ку-ка-ре-ку...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

7. Сообщение от Аноним (7), 28-Окт-20, 22:58	+/–
Я тут вчера покопался в коде утилитки которую написал 10 лет назад. Свежий компилятор указал на баг в (!'\n' == buf[li]) -- скобочка не там, ну, исправил. Даже не заметил, использовалась она все эти годы. Это была проверка на некорректные данные. Заметил бы я ошибку без помощи компилятора? Ещё в одном месте было выделение из кучи в принте, поменял на выделение на стеке (валгринд жаловался). Ну и по мелочи подвигал код, как вообще можно улучшить код на си? Он же идеален.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #10, #13, #28, #49

8. Сообщение от Аноним (-), 28-Окт-20, 23:00	+3 +/–
> Степень опасности проблемы и возможность > создания эксплоита не уточняется. А что так? Не хотят давать возможность для ловли лулзов? Да ладно, мы уже привыкли...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11

9. Сообщение от Аноним (9), 28-Окт-20, 23:07	+1 +/–
Как ни странно, исправить баг на "опасном" си - быстрее и проще, чем написать на "безопасном" расте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #33, #35, #37

10. Сообщение от Аноним (9), 28-Окт-20, 23:12	+4 +/–
Если сейчас погромисты на си путаются в указателях, то на расте будут путаться между a+b и a+c
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #25

11. Сообщение от Аноним (9), 28-Окт-20, 23:14	–4 +/–
Да там как обычно, надо сырцы эксплоита патчить под свою систему, компилять и запускать под рутом, чтобы хоть какой-то отклик получить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

12. Сообщение от Дон Ягон (ok), 28-Окт-20, 23:14	+2 +/–
Мда, ещё более бессодерждательно нежели недавняя новость про "дыры в netbsd" (по меньшей мере 3-4 из которых тот же исследователь тремя годами ранее нашёл в openbsd без какого либо дополнительного освещения). Про текущее: там даже в ссылках на еррату более вопиющее есть (например: Incorrect use of getpeername(2) storage for outgoing IPv6 connections corrupts stack memory), а если прошлые почитать, там похожего ещё вагон (как и примерно везде). В чём событие - не понятно, в общем. Как будто никогда такого не было )
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #32

13. Сообщение от Аноним (13), 28-Окт-20, 23:52	+9 +/–
Вот погромисты, которые не знают о существовании оператора !=, громче всех про rust и кукарекают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #14, #16

14. Сообщение от Аноним (9), 28-Окт-20, 23:59	+/–
скоро начнут путать приоритеты * и +
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #43

15. Сообщение от Аноним (15), 29-Окт-20, 00:14	+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-octobe.... Особенно в Google Project Zero любят из use-after-free багов, на которые кричат, что они не опасны, делать рабочие эксплоиты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #18, #19, #21

16. Сообщение от Аноним (7), 29-Окт-20, 00:15	–1 +/–
Скорее всего наоборот: те кто знают о существовании такого оператора и думают, что лучше инвертировать смысл (особенно когда там по соседству несколько проверок в духе !(0) && !(0)).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #29

18. Сообщение от Аноним (7), 29-Окт-20, 00:41	+1 +/–
Лучше может быть только безусловное выполнение от рута любой присланной извне команды в network manager, Там, кстати, текстовый скрипт был.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

19. Сообщение от Дон Ягон (ok), 29-Окт-20, 01:54	–2 +/–
Ну и не такая большая вероятность RCE, на самом деле, зависит очень от многого. Насколько тут большая проблема мне пока не понятно. Но я, по крайней мере, теперь вижу смысл в новости: https://twitter.com/m00nbsd/status/1321524807473782784 - тут намекают, что RCE таки возможен. Тогда всё интереснее. Посмотрим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

20. Сообщение от б.б. (?), 29-Окт-20, 03:31	–2 +/–
никогда не использовал ipv6, но в этот раз точно буду. протокол от народа.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #87

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

22. Сообщение от Аноним (22), 29-Окт-20, 05:26	+2 +/–
** Only two remote holes in the default install, in a heck of a long time! ** сайт забыли обновить, там уже давно не two )
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27

23. Сообщение от Siborgium (ok), 29-Окт-20, 05:34	+2 +/–
Видимо, 30 лет опыта разработчикам не хватило.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

24. Сообщение от JL2001 (ok), 29-Окт-20, 06:42	+/–
> на расте такое сложно написать, ещё никто не смог хм, и правда, в redox ipv6 пока не завезли но ipv4 же есть и функционал сравним?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

25. Сообщение от JL2001 (ok), 29-Окт-20, 06:44	+/–
> Если сейчас погромисты на си путаются в указателях, то на расте будут > путаться между a+b и a+c зато это будут наши a и c (мои и индуса), а не васи-хацкера
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

26. Сообщение от Fracta1L (ok), 29-Окт-20, 08:02	+/–
Настолько тонко что даже толсто))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #56

27. Сообщение от Аноним (27), 29-Окт-20, 08:09	+3 +/–
Там просто речь всегда идет о двух последних найденных дырах. А те, что до них, это уже "very long time. Longer than anyone can remember."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #30

28. Сообщение от Онаним (?), 29-Окт-20, 08:44	+4 +/–
!'\n' - это прекрасно. А != никак нельзя было?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

29. Сообщение от Онаним (?), 29-Окт-20, 08:45	+2 +/–
В итоге закономерно страдают. Всё правильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

30. Сообщение от Онаним (?), 29-Окт-20, 08:45	+3 +/–
Наверняка список найденных дыр золотая рыбка обновляла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

31. Сообщение от Аноним (31), 29-Окт-20, 08:56	–5 +/–
Ядро 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ообщить модератору
Родитель: #21 Ответы: #42, #58

32. Сообщение от пох. (?), 29-Окт-20, 09:31	–1 +/–
> Мда, ещё более бессодерждательно _remote_ code exec, куда еще содержательней? > например: Incorrect use of getpeername это local по сути - вызывается действиями на стороне системы. > там похожего ещё вагон (как и примерно везде) не везде же "in a heck of a long time..." а, простите, имелось в виду - выключенной из розетки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #41

33. Сообщение от Ненавижу SJW (?), 29-Окт-20, 10:05	+7 +/–
У тебя Си головного мозга. Никто же не заикался про Си или Раст в ветке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

34. Сообщение от Аноним (34), 29-Окт-20, 10:07	+1 +/–
Fracta1L, залогинься.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

35. Сообщение от Аноним (1), 29-Окт-20, 10:07	–3 +/–
При чем тут си? Просто сссупербезопасная ось (в очередной раз) оказалась просто неуловимым Джо, который нафиг никому не сдался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #57

36. Сообщение от Аноним (34), 29-Окт-20, 10:09	–3 +/–
>rust, приди!! порядок наведи!!! Братство свидетелей святого Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #75

37. Сообщение от Аноним (37), 29-Окт-20, 10:31	+/–
Только божественно одаренный мог сравнить трудоемкость исправления ошибки в одной функции огромной системы, форкнутой от другой системы, написанной на Си в лохматые годы и трудоемкость написания такой же ОС на относительно безопасном языке, в которой такой ошибки и не возникло бы. Но кто знает, может со временем новый Тео де Раадт, также повернутый на безопасности, напишет какую-нибудь OpenRedox форкнув Redox и там такие ошибки всплывать будут значительно реже, разве что в каких-нибудь кастомных/проприетарных драйверах юзерспейса, написанных в unsafe-режиме.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #51

38. Сообщение от Аноним (38), 29-Окт-20, 10:44	+1 +/–
Надо устроить опрос, что, по мнению опеннетовских аналитиков, более эффективно против подобных уязвимостей: неиспользование ipv6 или неиспользование Си?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45

39. Сообщение от псевдонимус (?), 29-Окт-20, 12:01	+1 +/–
Как хорошо, что я запрещаю ипв6 ещё при установке:-)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44

41. Сообщение от Дон Ягон (ok), 29-Окт-20, 12:54	+/–
> _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, с риском обрушить ядро в случае неуспеха. Так что не удивлюсь, если со слоганом ничего не случится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

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

43. Сообщение от JL2001 (ok), 29-Окт-20, 15:42	+1 +/–
> скоро начнут путать приоритеты * и + всегда путали (в том числе и на Си, на асемблере тока не путали)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

44. Сообщение от Аноним (34), 29-Окт-20, 15:55	+1 +/–
А когда он появится у твоего провайдера, что делать будешь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #46, #50

45. Сообщение от Аноним (34), 29-Окт-20, 16:00	+2 +/–
Неиспользование C более мощно. Оно автоматически влечёт неиспользование IPv6..., а также IPv4 и всех остальных подсистем ядра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

46. Сообщение от псевдонимус (?), 29-Окт-20, 16:41	+1 +/–
> А когда он появится у твоего провайдера, что делать будешь? Попробую муравью хрен приделать -;) Он не появится, ибо бесполезен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

47. Сообщение от Аноним (-), 29-Окт-20, 17:43	+1 +/–
Уважаемые Анонимные Эксперты! Напоминаю Вам, что с каждой загрузкой в OpenBSD новое уникальное ядро. И если цель не просто крэшнуть ядро, а получить рута нужно правильно вычислить memory layout ядра и лишь потом можно будет предпринять попытку захвата контроля. Ошибка на любом этапе приведёт к повреждению ядра и остановке системы. Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно. Если только кто-то не будет заботливо поднимать систему до тех пор, пока у атакующего не наступит успех. Кстати, после перезагрузки ядро будет уже снова другое.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48, #60

48. Сообщение от псевдонимус (?), 29-Окт-20, 18:46	+/–
> Уважаемые Анонимные Эксперты! > Напоминаю Вам, что с каждой загрузкой в OpenBSD новое уникальное ядро. > И если цель не просто крэшнуть ядро, а получить рута нужно правильно > вычислить memory layout ядра и лишь потом можно будет предпринять попытку > захвата контроля. Ошибка на любом этапе приведёт к повреждению ядра и > остановке системы. > Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно. Если только > кто-то не будет заботливо поднимать систему до тех пор, пока у > атакующего не наступит успех. Кстати, после перезагрузки ядро будет уже снова > другое. Уважаемый Разработчик! Если система с опенбсд на борту используется в качестве шлюза, ее падение означает прекращение работы офиса/васян локалки. Это богоподобные Разработчики Неуязвимой ОС уязвимостью не считают?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #74

49. Сообщение от Аноним (49), 29-Окт-20, 18:48	+1 +/–
> Я тут вчера покопался в коде утилитки которую написал 10 лет назад. Свежий компилятор указал на баг в (!'\n' == buf[li]) Видимо писали ещё не выучив ни операции ни приоритеты. PS. я когда начинал учить С первым делом зазубрил приоритеты, вторым стадии трансляции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #52

50. Сообщение от Аноним (9), 29-Окт-20, 18:49	+4 +/–
Расскажи, сколько провайдеров в Штатах раздают белые IPv6 обладателям яойфонов? Ой, все за натом, почему-то...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #54

51. Сообщение от Аноним (9), 29-Окт-20, 18:58	+2 +/–
А ты ещё удивляешься, почему на расте не пишут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

52. Сообщение от Аноним (7), 29-Окт-20, 19:17	+3 +/–
> Видимо писали ещё не выучив ни операции ни приоритеты. ну, это маловероятно, я всё же ставлю на неверно размещённую скобочку (иначе бы её там вообще не было, да и логические операции всегда везде последними идут) > PS. я когда начинал учить С первым делом зазубрил приоритеты, вторым стадии > трансляции. это полезно только для того, чтобы знать в каком порядке изменится i=i+(++i+i++) и есть более полезные вещи на самом деле (кроме того, почему-то менее квалифицированные специалисты очень косо смотрят на такой код, видимо, завидуют, не иначе)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #53, #59

53. Сообщение от Аноним (7), 29-Окт-20, 19:21	+1 +/–
пс. да, там где-то рядом было ещё в духе i=i+(++i+i++) только с битовым отрицанием (не припомню зачем, но красивее было никак).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

54. Сообщение от псевдонимус (?), 29-Окт-20, 22:28	+1 +/–
> Расскажи, сколько провайдеров в Штатах раздают белые IPv6 обладателям яойфонов? Ой, все > за натом, почему-то... Если обычного юзера с ведром или гейфоном, с хромобраузером на борту выпустить в сеть с белым айп , то либо кирпич, либо часть ботнета. И опсосы об этом знают, потому никакого ипв6, к счастью, не будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #61, #73, #88

56. Сообщение от Michael Shigorin (ok), 29-Окт-20, 22:55	+1 +/–
У Вас integer overflow? :]
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

57. Сообщение от анонимуслинус (?), 29-Окт-20, 23:59	+1 +/–
нет просто ipv6 еще долго будет всем отдаваться икотой от его проблем. пока не вычистят стандарт и реализации. как было с ipv4|.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

58. Сообщение от Дон Ягон (ok), 30-Окт-20, 01:15	+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 +/- аналогично по смыслу). Потому что нельзя сделать ничего хорошего обкладывая плохо написанные программы костылями, чтобы они работали правильно. Надо исправлять ошибки, а не нагромождать вокруг потенциальных ошибок костыли. Сами по себе костыли эти может не так и дорого стоят, а вот все вместе - уже ощутимо. А по-отдельности в них смысла просто нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #62

59. Сообщение от Ordu (ok), 30-Окт-20, 05:55	+1 +/–
> кроме того, почему-то менее квалифицированные специалисты очень косо смотрят на такой код, видимо, завидуют, не иначе Более квалифицированные программисты за такой код лупят по заднице ремнём: это UB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

60. Сообщение от Ordu (ok), 30-Окт-20, 05:59	+1 +/–
> Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно. Брутфорсить не обязательно, надо подождать когда найдут очередной способ обойти aslr, потому что где-нибудь что-нибудь в кеше каком-нибудь осело, или ещё как-нибудь информация об адресах раскрылась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #66

61. Сообщение от Аноним (61), 30-Окт-20, 13:37	+1 +/–
На гейфонах нет хромобраузера. Если что.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

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

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

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

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

66. Сообщение от Дон Ягон (ok), 30-Окт-20, 18:16	+/–
>> Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно. > Брутфорсить не обязательно, надо подождать когда найдут очередной способ обойти aslr, потому > что где-нибудь что-нибудь в кеше каком-нибудь осело, или ещё как-нибудь информация > об адресах раскрылась. Удалённо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #67

67. Сообщение от Ordu (ok), 30-Окт-20, 19:13	+1 +/–
>>> Реальное исполнение подобного без возможности "брутфорсить" aslr невозможно. >> Брутфорсить не обязательно, надо подождать когда найдут очередной способ обойти aslr, потому >> что где-нибудь что-нибудь в кеше каком-нибудь осело, или ещё как-нибудь информация >> об адресах раскрылась. > Удалённо? Это по-разному бывает. Дыры довольно непредсказуемые вещи. Посмотри на современные эксплоиты, которые берут и увязывают десяток разных багов (каждый из которых даже дырой не назвать -- просто баг) в одну огромную зияющую дырень.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #68

68. Сообщение от Дон Ягон (ok), 30-Окт-20, 19:44	+/–
> Это по-разному бывает. Согласен. Но всё же удалённая утечка инфы о структурах ядра - имхо, это что-то, что тянет на отдельную уязвимость.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

69. Сообщение от Дон Ягон (ok), 30-Окт-20, 22:13	+/–
Тео про еррату, степень опасности, слоган и пр.: "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." Запасаемся попкорном и ждём продолжения (эксплоита?).
Ответить | Правка | Наверх | Cообщить модератору

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

71. Сообщение от Аноньимъс (?), 31-Окт-20, 10:36	+/–
Тоесть получается сишке нужно 58 лет учиться? Но есть ли гарантии что через 10 программисты таки научатся на ней писать? А если 10 лет не хватит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

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

73. Сообщение от Аноньимъс (?), 31-Окт-20, 10:59	+1 +/–
Будет. Всё будет. Алсо, белый опи v6 не так работает как v4.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #76

74. Сообщение от Аноньимъс (?), 31-Окт-20, 11:02	+/–
>Если система с опенбсд на борту используется в качестве шлюза, ее падение означает прекращение работы офиса/васян локалки. А если используется линукс, виндовс, или проприетарная ос, её падение не будет означать тогоже?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #77

75. Сообщение от Аноним (-), 31-Окт-20, 16:25	+/–
Нет это весёлые тролли. Не обращайте внимания. Они сами исчезнут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

76. Сообщение от псевдонимус (?), 31-Окт-20, 18:51	+/–
> Будет. Всё будет. > Алсо, белый опи v6 не так работает как v4. Его тоже прекрасно трахают. И работает он также
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #83

77. Сообщение от псевдонимус (?), 31-Окт-20, 18:53	–1 +/–
>>Если система с опенбсд на борту используется в качестве шлюза, ее падение означает прекращение работы офиса/васян локалки. > А если используется линукс, виндовс, или проприетарная ос, её падение не будет > означать тогоже? Как это оправдывает опенбсд?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #79

78. Сообщение от Дон Ягон (ok), 31-Окт-20, 22:05	+1 +/–
> Строгий контроль со стороны процессора и ядра 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 может и не иметь в себе эксплуатируемых уязвимостей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #81

79. Сообщение от Аноньимъ (ok), 31-Окт-20, 23:22	+1 +/–
> Как это оправдывает опенбсд? От чего оправдывает? Кто-то в чем-то обвиняет OpenBSD? Мы тут на суде?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

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

81. Сообщение от Аноним (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ообщить модератору
Родитель: #78 Ответы: #84

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

83. Сообщение от Аноньимъ (ok), 01-Ноя-20, 17:02	+/–
> Его тоже прекрасно трахают. И работает он также Так он и должен трахаться, в этом вся суть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

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

86. Сообщение от Аноним (-), 21-Ноя-20, 20:45	+/–
ping of the death? опять? на чужих ошибках учиться не того? почему это сейчас, а не 10 лет назад то? это первый кто код ipv6 в bsd прочитал?
Ответить | Правка | Наверх | Cообщить модератору

87. Сообщение от Аноним (87), 22-Ноя-20, 20:49	+/–
правильно, должен же кто-то за "дефицитные" ipv4 платить, всего 2 бакса в месяц за право аренды 4 байтов и они ваши - а что поделать, байтов на всех не хватает, поразвели компьютеров и мобил, понимаешь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

88. Сообщение от Аноним (87), 22-Ноя-20, 20:52	+/–
ботнетом они и так становятся, наставив апкшек от неПети, а кирпич вообще проблемы юзерей, с другой стороны оборудование для nat не бесплатное и требует обсдуги и электричества, однажды будет соблазн просто утилизировать это
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

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

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