The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



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

"Удалённая уязимость в ядре NetBSD, эксплуатируемая из локальной сети"  +/
Сообщение от opennews (??), 14-Окт-20, 11:44 
В NetBSD устранена уязвимость, вызванная отсутствием проверки границ буфера при обработке jumbo-пакетов в драйверах для сетевых адаптеров, подключаемых по USB. Проблема приводит к копированию части пакета за пределы буфера, выделенного в кластере mbuf, что потенциально может использоваться для выполнения кода атакующего на уровне ядра через отправку определённых кадров из локальной сети. Исправление для блокирования уязвимости внесено 28 августа, но сведения о проблеме раскрыты только сейчас. Проблема затрагивает драйверы atu, axe, axen, otus, run и  ure...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53888

Ответить | Правка | Cообщить модератору

Оглавление

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

1. Сообщение от Аноним (1), 14-Окт-20, 11:44   +9 +/
Exploitable-over-net-BSD
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #54

3. Сообщение от little Bobby tables (?), 14-Окт-20, 11:47   +17 +/
правильно объединили новости : бсд и венда
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #34

4. Сообщение от A.Stahl (ok), 14-Окт-20, 11:47   +2 +/
>jumbo-пакетов

Это, вроде, называется jumbo frame. Кадр. По аналогии с Ethernet кадрами. По ссылке "packet", но мне кажется это опечатка.

Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от Аноним (6), 14-Окт-20, 12:02   +2 +/
>>Unfortunately, there are some security risks related to ICMPv6 RA messages. On networks that do not yet use IPv6, the dual-stack hosts sit dormant waiting for an eventual RA message to awaken their IPv6 connectivity.  An attacker can craft a “rogue RA” message on these networks, get the dual-protocol nodes on the network to configure their IPv6 addresses and utilize the attacker’s system as their default gateway.

Оно дырявое by design. Это первое о чём я подумал когда увидел фразу "передачи конфигурации DNS через пакеты ICMPv6" Что они ожидали?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41

7. Сообщение от Аноним (7), 14-Окт-20, 12:18   +2 +/
> приводит к копированию части пакета за пределы буфера

*facepalm*
даже комментировать не хочется... а то сразу набегут сами знаете кто

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #15, #18

8. Сообщение от FractaL (?), 14-Окт-20, 12:28   +2 +/
> отсутствием проверки границ буфера при обработке jumbo-кадров

Ну в принципе любой может ошибиться, от языка это не зависит. На любом языке можно внести дыру безопасности.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14, #53, #56, #89

9. Сообщение от notcurver (?), 14-Окт-20, 12:34   –1 +/
Со всеми бывает.
Ответить | Правка | Наверх | Cообщить модератору

10. Сообщение от Аноним (46), 14-Окт-20, 12:35   +4 +/
> Удалённая уязимость в ядре NetBSD, эксплуатируемая из локальной сети

Но как же так? Её же делают профессиональные порфессионалы, а не какие-то лaпчaтые выскачки!

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #24

11. Сообщение от Аноним (11), 14-Окт-20, 12:38   –4 +/
Прокоментируй как будешь писать драйвер без unsafe кода, я подожду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #25

12. Сообщение от Аноним (12), 14-Окт-20, 12:42   +/
Ага, делают, только не используют - нетка и pkgsrc уже давно кросскомпилится из линукса, дураков, которые используют это на десктопе тем более нет. Поэтому что есть дыра, что нет дыры...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #13, #16, #19

13. Сообщение от A.Stahl (ok), 14-Окт-20, 12:45   –2 +/
del
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

14. Сообщение от zshfan (ok), 14-Окт-20, 12:51   –3 +/
На любом языке кроме языка Ада
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #20, #40

15. Сообщение от Аноним (11), 14-Окт-20, 12:51   –1 +/
> Stack smashing protection     No
> Forward-edge control flow protection     No
> Backward-edge control flow protection (e.g., shadow and safe stack)     No

даже комментировать не хочется... а то сразу набегут сами знаете кто (растовики со смузи доказывать что вы фсё фрёте)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

16. Сообщение от Аноним (-), 14-Окт-20, 12:52   –1 +/
Да ладно. В японии много кто на десктопах-то. Как было, так и есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

17. Сообщение от Дон Ягон (ok), 14-Окт-20, 12:52   +1 +/
Звучит эпично, но по факту - так себе. Ну в смысле что локальная сеть + usb-свистки - не слишком высокий шанс на реальную эксплуатацию.

А вот объединение с новостью про винду позабавило.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #63

18. Сообщение от Аноним (11), 14-Окт-20, 12:53   +2 +/
https://www.cvedetails.com/vulnerability-list/vendor_id-1902...

Совсем нет переполнений, угу :^)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

19. Сообщение от zshfan (ok), 14-Окт-20, 12:54   +/
Гляньте молодой человек вот это https://www.youtube.com/channel/UCk9NvmsPBC3lTn_L9kFaylA
Простой американский крестьянин вполне себе пользуется и даже показывает разницу в реализации базовой системы опенка фришки нетки и лапчатого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #22, #27

20. Сообщение от Аноним (20), 14-Окт-20, 12:57   +/
А в Аде совсем нет возможности перейти к работе напрямую с адресами памяти?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #28, #31

21. Сообщение от Аноним (21), 14-Окт-20, 12:59   +/
Почему? Известно же где они код берут, вроде и не секрет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

22. Сообщение от Аноним (22), 14-Окт-20, 12:59   +/
Так, загибаю большой палец: один пользователь есть. Держу остальные пальцы наготове: посчитаем всех пользователей NetBSD!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #26

23. Сообщение от Аноним (6), 14-Окт-20, 13:01   –1 +/
Кто-то может сказать, это действительно драйвера оказались уязвимы, или это Васян-драйвер включили в ядро и поэтому теперь это называют уязвимостью БСД а не уязвимостью Васян-драйвера?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35, #38

24. Сообщение от Анонас (?), 14-Окт-20, 13:03   +1 +/
Да ну, какие они профессионалы? Уязвимостей всего в 15 раз меньше, чем в Линуксе.

https://www.cvedetails.com/product/84/Netbsd-Netbsd.html?ven...
https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #30

25. Сообщение от Lex (??), 14-Окт-20, 13:12   +1 +/
Прокомментируй, как будешь писать драйвер, работающий с сетью, начисто забив на проверку длины и выход за границы, я подожду.
Хотя, зачем твой коммент ? Тут бы коммент автора, который УЖЕ написал тот драйвер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

26. Сообщение от A.Stahl (ok), 14-Окт-20, 13:14   +/
Забавное наблюдение -- я в случае пальцевого счёта начинаю с мизинца. Причём даже в том случае если мне приходится задействовать пальцы второй руки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #29

27. Сообщение от Аноним (-), 14-Окт-20, 13:14   +/
Лучше гляньте в pkgsrc (или погуглите про это) и убедитесь, что линуксоидов и яблочников даже там больше, нежели нетбсдшников.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

28. Сообщение от Lex (??), 14-Окт-20, 13:16   –2 +/
Конечно. А ещё там - парсеры, способные абсолютно безошибочно разбирать мусор любого, даже заранее неизвестного формата( включая битый ), приходящий от сторонних источников. Ну это, если верить анонам, именующим его нереально-безопасным( аноны, правда, и про рубин_на_рельсах и про его невероятную скорость и удобство  что-то говорили, но.. какой с анонов спрос ? )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

29. Сообщение от Lex (??), 14-Окт-20, 13:19   –1 +/
Забавное наблюдение.
Stahl либо использует для счёта правую руку, либо - считает справа налево, что.. довольно странно для человека, читающего слева направо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #32

30. Сообщение от Аноним (-), 14-Окт-20, 13:20   +/
А это точно не потому что линукс примерно в 150 раз популярнее? И когда там кстати последний раз remote root в ядре был?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

31. Сообщение от Аноним84701 (ok), 14-Окт-20, 13:24   +1 +/
>> кроме языка Ада
> в Аде совсем нет возможности

Там аватарка намекает, что вы о разных языках ...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #33

32. Сообщение от A.Stahl (ok), 14-Окт-20, 13:31   +/
Да, я начинаю счёт с правой руки.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

33. Сообщение от zshfan (ok), 14-Окт-20, 13:36   +/
Нет, мы об одном и том-же языке. Ада насколько мне хватает моих знаний гораздо безопаснее плюсов и всяческой кофейной гущи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #48

34. Сообщение от Аноним (-), 14-Окт-20, 13:50   +5 +/
> правильно объединили новости : бсд и венда

Ну да, хоть в новостях будет единение, WSB им-то не светит!

Правильно добавили в список ссылок ниже, первым пунктом:
OpenNews: Удалённая уязвимость в systemd-networkd

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #46

35. Сообщение от Дон Ягон (ok), 14-Окт-20, 13:52   +/
Откуда взялись драйвера можно посмотреть в man'ах, всё как обычно. Драйвера, перечисленные в новости были портированны разработчиками netbsd из openbsd и один драйвер из freebsd. Портированы достаточно давно, т.е. не вчера. Например, axe появился в netbsd 3.0, а otus - в netbsd 6.

Про наличие аналогичных уязвимостей в open/free bsd мне ничего не известно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #74, #110

36. Сообщение от Онаним (?), 14-Окт-20, 13:57   +/
Скажи net BSD.
Ответить | Правка | Наверх | Cообщить модератору

37. Сообщение от КО (?), 14-Окт-20, 13:58   +/
"начиная с обновления 1709"
как знал что говнокодят
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #39

38. Сообщение от Аноним (-), 14-Окт-20, 13:59   –3 +/
> Кто-то может сказать, это действительно драйвера оказались уязвимы, или это Васян-драйвер включили в ядро и поэтому теперь это называют уязвимостью БСД а
> не уязвимостью Васян-драйвера?

Да все просто!
http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-...
> Some USB network interface drivers are missing a bounds check
> The following drivers were audited and do not appear to be affected in

netbsd-9:

Если драйвер для BSD - значит уязвимость в БСД, ведь там одни неосиляторы и неудачники (мы все так говорим, а значит это правда!)
А вот если бы драйвер был для Пингвинчика, то пришлось бы разбираться, почему очередной Васян налажал!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

39. Сообщение от Онаним (?), 14-Окт-20, 14:01   +1 +/
Радует, что с привычкой на винде и не только отключать IPv6 сразу же после развёртывания системы (а то и вместе с развёртыванием) это не особо страшно :) IPv6 одна большая сплошная дыра в целом, начиная с лёгкой возможности захламления neighbor-таблиц.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #45, #94

40. Сообщение от nomad__email (ok), 14-Окт-20, 14:02   +2 +/
Ada не устраняет человеческий фактор. Софт Ariane-5, между прочим, на ней был написан
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #71

41. Сообщение от Онаним (?), 14-Окт-20, 14:03   +5 +/
Вся автоконфигурация в v6 - одна большая сплошная дыра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #42

42. Сообщение от Онаним (?), 14-Окт-20, 14:05   +1 +/
Упреждая вопли про DHCP в v4, сразу же:
В отличие от v4, руками конфигурировать те же v6 адреса - ад адешный.
Плюс надо не забыть отключить линк-локал, шлак и приём RA.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #44, #78

44. Сообщение от пох. (?), 14-Окт-20, 14:11   +1 +/
> В отличие от v4, руками конфигурировать те же v6 адреса - ад адешный.

by design, угу. Предполагалось что все сделают за тебя умные технологии (ну мы помним, да - ключи от всего у кого-то поумнее хозяина системы), и тебе никогда в жизни не придется запоминать и безошибочно набирать эту бредятину (по-моему, разработчики были из неосиляторов v4, и реально думали, что все кругом испытывают те же трудности) - правда, как обычно, на пол-дороге выяснилось, что RA - это еще немного не все, и dhcp, ну надо же, ТОЖЕ нужно - кто бы мог подумать, и было ли ему - чем?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #62, #82

45. Сообщение от пох. (?), 14-Окт-20, 14:13   –1 +/
Хаха - я вот был немного удивлен, узнав какой танец-с-граблями надо исполнять в современном редхламе, чтобы отключить совсем и навсегда. Полагаю, в следующей версии уже не будет отключаться вообще (а там и винда подтянется)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #59, #61

46. Сообщение от Аноним (46), 14-Окт-20, 15:08   –5 +/
Если WSL - это немного оптимизированная виртуалка с линуксом - то WSB существует уже давно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #80

47. Сообщение от Аноним (47), 14-Окт-20, 16:07   +/
Ничего идеального в мире it нет и не будет, дыры есть были и будут. Всё расходимся.
Ответить | Правка | Наверх | Cообщить модератору

48. Сообщение от Аноним (48), 14-Окт-20, 16:29   +1 +/
>> насколько мне хватает моих знаний

Ада просто заставляет писать обработчики исключительных ситуаций.
Правильно это будет написано или нет зависит - от человека. А то можно и заглушку поставить.

Эрудит,мля :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

49. Сообщение от Аноним (49), 14-Окт-20, 16:39   +/
>Уязвимость проявляется начиная с обновления 1709 для Windows 10

"СЕМЁРКА НЕБЕЗОПАСНА, ПЕРЕХОДИТЕ НА 10КУ!" - говорили некоторые.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50

50. Сообщение от Аноним (100), 14-Окт-20, 17:03   –1 +/
От наличия уязвимости в десятке, семёрка безопаснее не станет. Десятку исправят, в отличие от.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #52, #57

52. Сообщение от Аноним (52), 14-Окт-20, 17:30   +/
Микромягкие прогнулись и продлили до 2023 года поддержку семерки.
Так что можешь откатиться)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #65

53. Сообщение от Аноним (53), 14-Окт-20, 17:41   +/
Верно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

54. Сообщение от VINRARUS (ok), 14-Окт-20, 18:39   –3 +/
Ну отключи NetBSD от Net
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #81

56. Сообщение от VINRARUS (ok), 14-Окт-20, 18:46   +/
>На любом языке можно внести дыру безопасности.

Даже на языке жестов?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #84

57. Сообщение от VINRARUS (ok), 14-Окт-20, 18:50   +1 +/
Зато ХР стаёт безопаснее 10 с каждым обновлением 10.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #77

58. Сообщение от Аноним (58), 14-Окт-20, 18:52   –1 +/
а вот переписали бы на Rust и таких проблем не было бы
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #64, #76, #109

59. Сообщение от Онаним (?), 14-Окт-20, 19:26   +/
Да ладно, какой там танец с граблями.
Две строчки в sysctl. Или один параметр в параметры ядра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #60

60. Сообщение от Онаним (?), 14-Окт-20, 19:27   +/
Параметр - ipv6.disable=1
sysctl - net.ipv6.conf.all.disable_ipv6=1 , net.ipv6.conf.default.disable_ipv6=1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #72

61. Сообщение от Онаним (?), 14-Окт-20, 19:31   +/
У нас немножко другой коленкор, у нас инфраструктурные системы кастомизированы, и по умолчанию интегрирован systemd-networkd, там две строчки в .conf-файле на интерфейсах.

LinkLocalAddressing=no
IPv6AcceptRA=no

Первое заодно фигачит 169.254.x.x, который в других случаях надо через /etc/sysconfig/network параметро NOZEROCONF=yes выключать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

62. Сообщение от Аноним (62), 14-Окт-20, 19:42   –1 +/
Всё потому что тебя там не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #70

63. Сообщение от Аноним (62), 14-Окт-20, 20:07   +/
> локальная сеть + usb-свистки

raspberry pi

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

64. Сообщение от Аноним (62), 14-Окт-20, 20:11   +2 +/
На lua.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

65. Сообщение от ННН (?), 14-Окт-20, 20:21   +/
Прогнулись, получая за это деньги.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

70. Сообщение от Аноним (70), 14-Окт-20, 22:10   +1 +/
Его, не его, но судя по количеству глупостей в протоколе и по триумфальному внедрению IPv6 там крайне не хватало практикующих сетевых инженеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #83

71. Сообщение от Аноним (70), 14-Окт-20, 22:11   +/
Это другое™
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

72. Сообщение от онанимуз (?), 14-Окт-20, 22:28   –1 +/
к сожалению, это не работает.
система игнорирует эти настройки и всё равно поднимает ипв6, если встречает что-нибудь про него в каком-либо из других конфигов, как минимум это /etc/hosts и /etc/ssh/sshd_config.
все конфиги не помню, записаны где-то в мануале "как отключить это сраное дерьмо говна v6" на рабочем компе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #88

74. Сообщение от Дон Ягон (ok), 14-Окт-20, 23:34   +/
> Про наличие аналогичных уязвимостей в open/free bsd мне ничего не известно.

"
revision 1.59
date: 2017/07/20 22:29:26;  author: stsp;  state: Exp;  lines: +6 -1;  commitid: GrlKQv8bl2DbBLNp;
Make otus(4) drop frames larger than MCLBYTES.
Problem reported by Ilja Van Sprundel.
ok deraadt@ tb@
"

По меньшей мере в одном драйвере дыра была и в openbsd, без понятия пока, правда, что там насчёт разрушительности последствий (но, подозреваю, что примерно то же самое).
Правда, пофикшено в 2017 году. Баги нашёл один и тот же человек, к слову.

Пойду-ка попробую и остальные diff'ы найти-почитать да с оригиналом сравнить. Жаль нетбсдшники не публикуют патчи в секьюрити-анонсах (ну или я в глаза сношаюсь), как опенбсдшники, было бы чуть удобнее.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #75

75. Сообщение от Дон Ягон (ok), 14-Окт-20, 23:50   +/
> Баги нашёл один и тот же человек, к слову.
> Ilja Van Sprundel

Он, кстати, норм так набрасывать умеет: https://www.csoonline.com/article/3250653/is-the-bsd-os-dyin...

А заголовки в статье так вообще желтушные: "NetBSD the "clear loser" in terms of code quality". Тро-ло-ло.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

76. Сообщение от анонимуслинус (?), 15-Окт-20, 02:42   +/
так перепиши. я вообще хотел бы глянуть как перепишется любая ось на расте без unsafe))) раст же безопасный. так покажите плюсовикам и прочим как он крут. особенно ядрышко системы и драйвера))))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #91

77. Сообщение от СеменСеменыч777 (?), 15-Окт-20, 02:53   +/
ни одного (неофициального) аудита кода ХР еще не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #79, #92

78. Сообщение от Аноним 80_уровня (ok), 15-Окт-20, 02:55   +/
> руками конфигурировать те же v6 адреса - ад адешный

Чоита?

iface eth0 inet6 static
    address 2a0x:xxxx:xx:xxx:x::2/64
    gateway 2a0x:xxxx:xx:xxx:x::1

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #85, #87

79. Сообщение от VINRARUS (ok), 15-Окт-20, 06:47   –1 +/
> ни одного (неофициального) аудита кода ХР еще не было.

Ну код приоткрыли же :D

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

80. Сообщение от Аноним (80), 15-Окт-20, 07:32   –6 +/
Ваш Вайн это виртуалка, а wsl это интерпретатор. Двуличные сектанты-представители свободки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #96

81. Сообщение от www2 (??), 15-Окт-20, 07:34   –1 +/
От USB-адаптера Ethernet. Саму по себе NetBSD можно встретить довольно редко, а уж системы с NetBSD и такими сетевыми картами вообще, наверное, по пальцам пересчитать можно. Почему-то представился гик-хипстер, установивший NetBSD на Macbook, который при этом предпочитает не пользоваться WiFi.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

82. Сообщение от www2 (??), 15-Окт-20, 07:43   +/
>Предполагалось что все сделают за тебя умные технологии (ну мы помним, да - ключи от всего у кого-то поумнее хозяина системы)

Мьсе из тех, кто ARP-, FDB-таблицы и таблицы маршрутизации на каждом сетевом узле заполняет вручную? DHCP, LLDP, VGRP, VTP, BGP, OSPF, RIP никогда не пользуется? RA из той же оперы, если что.

>на пол-дороге выяснилось, что RA - это еще немного не все, и dhcp, ну надо же, ТОЖЕ нужно - кто бы мог подумать, и было ли ему - чем?

DHCP не нужен, если устройству достаточно получить IPv6-префикс и узнать IPv6-адрес маршрутизатора. Мне коммутаторы попадались, на которых DNS-серверы в принципе некуда указать. Вот таким устройствам этого достаточно.

Всё остальное отдано наоткуп DHCPv6, где можно и адреса DNS-, NTP- и даже TFTP-серверов раздавать или там статические маршруты. Вполне разумно, я считаю.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

83. Сообщение от www2 (??), 15-Окт-20, 07:48   +1 +/
Не надо переоценивать умственные способности большинства практикующих сетевых инженеров.

Практикующий сетевой инженер лучше сделает приватную сеть из 10.0.0.0/8, 192.168.0.0/16, 172.12.0.0/12, 169.254.0.0/16 и завернёт всё это за NAT, а потом будет героически сражаться с нехваткой свободных портов на NAT, множить сначала IP-адреса на одном узле, потом множить узлы NAT, потом решать проблемы с балансировкой трафика между этими NAT-узлами, потом придумывать, как ФСБ-шникам отвечать на запросы, с какого IP-адреса определённый абонент в определённое время выходил в интернет и ему ли принадлежит трафик с определённого порта.

Как говорится, мне некогда точить пилу, мне нужно пилить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #93, #97

84. Сообщение от www2 (??), 15-Окт-20, 07:51   +2 +/
На нём особенно. В разных культурах одни и те же жесты имеют совершенно разный смысл. Лучше никогда не используйте за границей привычные вам жесты, если вы на 100% не уверены в их значении для местного населения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

85. Сообщение от Онаним (?), 15-Окт-20, 07:52   +/
> Чоита?
> iface eth0 inet6 static
>     address 2a0x:xxxx:xx:xxx:x::2/64
>     gateway 2a0x:xxxx:xx:xxx:x::1

Сконфигурируй мне v6 без DHCP на PPPoE, который может подключаться к концентраторам, на которых разные подсети.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #86

86. Сообщение от Онаним (?), 15-Окт-20, 07:53   +/
Без link-local и без RA с шлаком.
Я тебе сразу отвечу: не получится.
Потому что в PPP эти мажоры от академиков механизма конфигурации не-link-local вообще не предусмотрели.
За что могут гореть в аду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

87. Сообщение от Онаним (?), 15-Окт-20, 07:55   +/
Ну и угу, потом если у тебя приём RA при этом не отключен, прилетает RA от левого устройства, и вся твоя конфигурация благополучно ложится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #107

88. Сообщение от Онаним (?), 15-Окт-20, 07:55   +/
С sysctl может быть беда, если кто-то перепишет /proc/...
Опция ядра работает железно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

89. Сообщение от Аноним (89), 15-Окт-20, 08:27   –1 +/
> В NetBSD устранена уязвимость, вызванная отсутствием проверки границ буфера при обработке

Уважаемый FractaL, NetBSD это вам не GNU/Linux, хоть и написан на C. Любые эксплоиты использующие переполнение буфера в ядре ОС NetBSD или программах исполняющихся на ядре NetBSD работать не будут.

Почему переполнение буфера, в ядре NetBSD написанном на C и прогах написанных на C, запущенных на ядре NetBSD, работать не будет?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #100, #139

90. Сообщение от Аноним (89), 15-Окт-20, 08:34   +3 +/
> В NetBSD устранена уязвимость, вызванная отсутствием проверки границ буфера при обработке

Любые эксплоиты использующие переполнение буфера в ядре ОС NetBSD или программах исполняющихся на ядре NetBSD работать не будут.

Данной уязвимости НЕСУЩЕСТВУЕТ!

Возможен максимум DoS или падение ядра NetBSD, в зависимости от политики реализации защиты от переполнения буфера при отсутствии проверки границ буфера в ядре NetBSD.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #101, #117, #150

91. Сообщение от Аноним (89), 15-Окт-20, 08:41   +/
Смотри A2, blue botle - не на C, без проблем и безопасно.

И с безопасностью C нет никаких проблем: https://www.opennet.ru/openforum/vsluhforumID3/122116.html#90

Проблему с C некоторые пытаются создать в ваших головах. И да эта проблема имеет место только в плохих ядрах OS и плохих компилятора, линковщиках.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #108

92. Сообщение от Аноним (21), 15-Окт-20, 08:48   +/
Путин пользуется икспи, по телевизору показывали. Вроде бы икспи единственная сертифицированная (ну просто там следящих компонентов ещё не было.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #99, #142

93. Сообщение от 1 (??), 15-Окт-20, 09:05   +/
эт точно !
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

94. Сообщение от 1 (??), 15-Окт-20, 09:11   +/
Тебя ждёт неожиданность, так как Exchange не устанавливается без IPv6
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #95

95. Сообщение от Онаним (?), 15-Окт-20, 09:12   –1 +/
Наш виндоадмин спокойно гоняет Exchange без IPv6 уже лет эннадцать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #102

96. Сообщение от daemontux (?), 15-Окт-20, 09:25   +/
А кого wsl интерпретирует?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #98

97. Сообщение от daemontux (?), 15-Окт-20, 09:29   +/
Сразу видно что  большими сетями вы не занимались...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

98. Сообщение от Аноним (80), 15-Окт-20, 09:40   –2 +/
В Гугле забанили? Понимаю
https://ru.m.wikipedia.org/wiki/Windows_Subsystem_for_Linux
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

99. Сообщение от Аноним (99), 15-Окт-20, 09:51   +1 +/
A что не Роса с Эльбрусом?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

100. Сообщение от Аноним (100), 15-Окт-20, 10:16   +/
Так почему же, интересно? Какая-то защита, сборка с флагами или что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #113

101. Сообщение от Аноним (100), 15-Окт-20, 10:19   +/
Очень интересно. В каких ОС ещё есть подобная защита, в каких нет? Особенно интересно про остальное семейство BSD и Linux.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #112

102. Сообщение от 1 (??), 15-Окт-20, 11:29   +/
Мда ... люди теряют навыки чтения (или понимания того, что написано).

Сходи в словарь и найди различия между словами "устанавливается" и "работает"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #95 Ответы: #111

107. Сообщение от Аноним 80_уровня (ok), 15-Окт-20, 13:30   +/
> Ну и угу, потом если у тебя приём RA при этом не
> отключен, прилетает RA от левого устройства, и вся твоя конфигурация благополучно
> ложится.

Не отключал (в явном виде). Не ложится.

Насчёт "сконфигурируй мне" - не буду, потому что ты сначала сделал общее утверждение о сложности, а затем внезапно перешёл к частностям. При этом не отрицаю, что описанный тобой частный случай может быть проблематичным, но утверждаю, что мой частный случай совершенно беспроблемен.

Ну, сеансовые подключения, что ты хочешь. Ты и сетку IPv4 в описанной ситуации вряд ли сможешь перероутить без использования какого-нибудь протокола динамической маршрутизации.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #141

108. Сообщение от анонимуслинус (?), 15-Окт-20, 14:14   –1 +/
ну я как раз и понимаю, что проблема не самого языка. скорее тех кто пишет на нем. если уж говорить про с/с++, то он и правда требует более высокой квалификации, но взамен дает боле мощный и управляемый инструмент. просто этот инструмент требует хорошего понимания и знания, а народ малость обленел. им здесь и сейчас и попроще. естественно мало кто хочет тратить столько времени на познание языка. это как авто с механикой и автоматом. механика дает управление точнее, но автомат проще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

109. Сообщение от Аноним (109), 15-Окт-20, 16:30   +/
За 100500 лет может и смогут поцтеринги что-то переписать на раст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

110. Сообщение от Аноним (110), 15-Окт-20, 19:51   +/
Это диверсия со стороны OpenBSD! Чтобы стать более безопасной нужно сделать другие ОС менее безопасными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

111. Сообщение от Онаним (?), 15-Окт-20, 20:38   –1 +/
Ещё раз: нашему виндоадмину это фиолетово :)
Не знаю, может он включал v6, делал major update, и потом выключал, но в любом случае это прошло быстро и незаметно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

112. Сообщение от Аноним (113), 16-Окт-20, 09:07   +/
Посмотри информацию на официальных сайтах интересующих OS.

Надо учитывать что вариантов W^X есть 3:

1. Защита строгая и бескомпромиссная.
2. Защита декларативная и дырявая.
3. Защиты нет.

В тех OS и сообществах где есть пропаганда и насаждение технологий JIT - никакой защиты W^X быть не может в принципе, по определению.

Дискретный контроль доступа (DAC) - фундамент безопасности с 1960-тых. И главное правило DAC: "все что исполняется не должно изменятся, а что изменяется не должно исполнятся" (W^X) сегодня реализован с той или иной степенью строгости и корректности во всех коммерческих OS: Unix, Microsoft, Apple.

Примеры GNU/Linux и *BSD:
NetBSD - строгая
OpenBSD - дырявая
GNU/Linux DYSTRYK - строгая https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../
GNU/Linux Ubuntu - отсутствует.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #114, #119

113. Сообщение от Аноним (113), 16-Окт-20, 09:14   –2 +/
Ядро OS NetBSD строго следит за соблюдением главного правила безопасности DAC: https://www.opennet.ru/openforum/vsluhforumID3/122116.html#112
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #120, #123

114. Сообщение от Аноним (100), 16-Окт-20, 09:29   +/
Спасибо за ответ. А в чём отличие дырявой от строгой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #115

115. Сообщение от Аноним (113), 16-Окт-20, 09:54   –1 +/
Строгая это строгая без копромисов. Когда разработчики ядра строго и без копромисов отказывают всем в поддержке JIT-подобным технологиям.

Дырявая это когда разрабы ядра прогнулись, пошли на компромисс и оставили возможности запуска JIT-приложений и работы JIT-компиляторов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #116

116. Сообщение от Аноним (113), 16-Окт-20, 10:00   –1 +/
Тео Де Раадт прогнулся, стал раком перед JIT и отказался от строгой защиты памяти в OpenBSD: https://www.opennet.ru/opennews/art.shtml?num=50763

Теперь в OpenBSD есть возможность запуска ненужных JIT-приложений и большая дырень в W^X для реализации эксплоитов на базе переполнения буфера.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

117. Сообщение от Аноним (117), 16-Окт-20, 12:24   +/
> Данной уязвимости НЕСУЩЕСТВУЕТ!

Значит NetBSD обновлять не надо!!! А то и к ней уже добрались и под видом исправления через обновление Троян забросят...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #118

118. Сообщение от Аноним (100), 16-Окт-20, 13:08   +/
Взломать нельзя, но ядро упасть может. Написано же было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #126

119. Сообщение от Дон Ягон (ok), 16-Окт-20, 14:42   +/
Ты путаешь юзерспейсный и ядерный W^X. Ыксперд млин.

Очевидно, что remote root в netbsd/openbsd невозможен (из-за этих дыр) как раз из-за ядерного W^X. И очевидно, что юзерспейсный влияет только лишь на прикладные приложения с jit, типа браузеров.

И там да, в openbsd не стали делать самый дубовый из возможных вариантов противодействия, а именно - ломать возможность делать mprotect'ом +x для участка памяти принудительно. Если автор приложения уверен, что подобное его приложению и не нужно - он может отозвать prot_exec через pledge. Причём, в любом нужном участке кода программы, а не только сразу после старта. А не учить своё приложение гадать в рантайме, умеет mprotect в prot_exec или нет (или прибивать, в зависимости от настроек).

Но фанатикам, не умеющим думать, умеющим только повторять за другими, понять этого сложно.

PS: мне тут один "неумный" рассказывал, что умение pax mprotect в dlopen и возможность его (pax mprotect'а) отключения через pax-flags - это достоинство. К разговору о том, где W^X pt2 позволяет что-то гарантировать, а где нет, ага.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #121, #128

120. Сообщение от Consta (?), 16-Окт-20, 14:50   +/
DAC от атак, связанных с переполнением буфера не помогает. К тому же неясно, что иненно уникального в DAC netbsd. Ну как у всех же её DAC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #125

121. Сообщение от Аноним (100), 16-Окт-20, 15:05   +/
>Очевидно, что remote root в netbsd/openbsd невозможен (из-за этих дыр) как раз из-за ядерного W^X.

А если в Linux, то возможен?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #122

122. Сообщение от Дон Ягон (ok), 16-Окт-20, 15:15   –1 +/
>>Очевидно, что remote root в netbsd/openbsd невозможен (из-за этих дыр) как раз из-за ядерного W^X.
> А если в Linux, то возможен?

Я не слишком хорошо знаком с актуальным состоянием ядра linux в этом месте, точно не знаю.
Но, судя, например, по https://www.opennet.ru/opennews/art.shtml?num=53892 - remote root там таки возможен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #129, #138, #162

123. Сообщение от Дон Ягон (ok), 16-Окт-20, 16:24   +1 +/
> Ядро OS NetBSD строго следит за соблюдением главного правила безопасности DAC: https://www.opennet.ru/openforum/vsluhforumID3/122116.html#112

Хватит уже тиражировать свою чушь про DAC. То, на что ты сослался далее (https://www.opennet.ru/opennews/art.shtml?num=50763) не имеет никакого отношения к тому, о чём речь сейчас.

И в ядре netbsd и в ядре openbsd реализован W^X для _ядра_ (в netbsd, ЕМНИП, появилось раньше, чем в openbsd) и именно поэтому уязвимости из новости могут только обрушить их ядра, но не выполнить код с правами ядра.

То, что описано в "Планах по усилению механизма защиты W^X в OpenBSD", на который ты почему-то ссылаешься - это про юзерспейс. То есть, на текущие уязвимости никакого влияния не оказывает. И, если что, решение "не форсить W^X pt 2" было принято сильно раньше того, что описывается в той новости. Хотя, кому надо, может и зафорсить средствами pledge.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #124

124. Сообщение от Аноним (125), 16-Окт-20, 17:05   –1 +/
> именно поэтому уязвимости из новости могут только обрушить их ядра, но не выполнить код с правами ядра.

Об этом и речь,что уязвимости нет. Падение ядра будет.

W^X это от DAC просто область применение не файл на диске, а страницы оперативной памяти и реализация в ядре OS необходима дополнительная. А по сути принцип DAC - пользователь должен иметь право только исполнять бинарь, а не изменять.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #127

125. Сообщение от Аноним (125), 16-Окт-20, 17:10   +/
W^X и NX инструкции процессора расширяют DAC на страници оперативной памяти. Ядро NetBSD имеет поддержку W^X как для ядра, так и для всех процессов. W^X это DAC просто права выставляются не файловой системой для файла, а ядром и процессором для страниц оперативной памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

126. Сообщение от Аноним (125), 16-Окт-20, 17:13   –1 +/
> ядро упасть может

У меня нормальные сетевухи, а не usb. Мне и думаю остальным обновлялся не надо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

127. Сообщение от Дон Ягон (ok), 16-Окт-20, 17:49   +1 +/
> по сути принцип DAC - пользователь должен иметь право только исполнять бинарь, а не изменять.

Чего?
DAC = discretionary access control? Или ты имеешь ввиду что-то другое?

https://security.stackexchange.com/questions/63518/mac-vs-da... - мне сложно что-то добавить к тому, что здесь написано про DAC.

Т.е. в рамках модели DAC любой пользователь может определить какие права будут иметь другие пользователи на действия с его файлами + рут, который нарушает DAC и может всё. При чём тут W^X / W|X вообще?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #131

128. Сообщение от Аноним (125), 16-Окт-20, 18:01   –1 +/
> в openbsd не стали делать самый дубовый из возможных вариантов противодействия, а именно - ломать возможность делать mprotect'ом +x для участка памяти принудительно. Если автор приложения уверен, что подобное его приложению и не нужно - он может отозвать prot_exec через pledge. Причём, в любом нужном участке кода программы, а не только сразу после старта. А не учить своё приложение гадать в рантайме, умеет mprotect в prot_exec или нет (или прибивать, в зависимости от настроек).

В OpenBSD Тео отдал программисту право изменят исполняемый код программы. И это очень плохо. Я на стороне строгой реализации W^X не допускающий JIT в принципе.

Тео поступил плохо, мотивируя что chrome & firefox требуют JIT. Google таки прогнулся под Apple в которых тоже строгая реализация W^X и нетерпимость к JIT - сегодня хромого можно собрать без поддержки JIT!

И какому такому "умному" пользователю OpenBSD нужны проги с JIT?

> умение pax mprotect в dlopen и возможность его (pax mprotect'а) отключения через pax-flags - это достоинство. К разговору о том, где W^X pt2 позволяет что-то гарантировать, а где нет, ага.

PAX - правильная реализация строгой защиты памяти которая таки дает гарантии!

Только если при сборке ядра разрешить отключать защиту для некоторых бинарей:
CONFIG_PAX_XATTR_PAX_FLAGS=y
https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...
то откроется дыра и с помощью paxctl-ng можно отключать, дискретно, некоторую защиту по файлам, храня информацию в xattr файловой системы (может и в заглавиях бинарей) это значит что админ может отключить какую-то защиту:
* постраничный защиту памяти
* посегментную защиту памяти
* защиту памяти mprotect
* мелкие области памяти emutramp
* рандомизацию адресного пространства
Защиту pax атрибутов можно организовать простым патчем к IMA/EVM. И при этом есть гарантии неизменности PAX атрибутов. Если вы отключили защиту для некого бинаря то защиты естественно у вас нет, но это ваш выбор, как и выбор CONFIG_PAX_XATTR_PAX_FLAGS=y

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #130

129. Сообщение от Аноним (125), 16-Окт-20, 18:03   +/
> linux ... remote root там таки возможен

Только в дистрибутивах для быдла.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #158

130. Сообщение от Дон Ягон (ok), 16-Окт-20, 18:25   –1 +/
> Тео отдал программисту право изменят исполняемый код программы.

Не Тео, а стандарты POSIX. Которые предполагают, что память может быть доступна и на запись и на чтение и есть программы, которые на это завязаны.

> Я на стороне строгой реализации W^X не допускающий JIT в принципе.

Как только объективной потребности в этом не будет - её все отключат. Пока это может сломать приложения, так делать нельзя.
(речь в большей степени про запрет на переключения RW -> RX, сам по себе W^X уже ломает не так много)

> Тео поступил плохо, мотивируя что chrome & firefox требуют JIT. Google таки прогнулся под Apple в которых тоже строгая реализация W^X и нетерпимость к JIT - сегодня хромого можно собрать без поддержки JIT!

Судя по https://developer.apple.com/documentation/apple_silicon/port... переключения между RW / WX возможны, т.е. всё аналогично openbsd.

> И какому такому "умному" пользователю OpenBSD нужны проги с JIT?

Мне например - firefox без prot_exec не работает. Firefox не нужен?

>> умение pax mprotect в dlopen и возможность его (pax mprotect'а) отключения через pax-flags - это достоинство. К разговору о том, где W^X pt2 позволяет что-то гарантировать, а где нет, ага.
> PAX - правильная реализация строгой защиты памяти которая таки дает гарантии!

Мне тут рассказывали (проверять поленился, ибо неинтересно), что подгрузить so'шку (со всеми вытекающими) можно даже при включённом pax mprotect. Т.е. строгость, видимо, таки мнимая.

>[оверквотинг удален]
> заглавиях бинарей) это значит что админ может отключить какую-то защиту:
> * постраничный защиту памяти
> * посегментную защиту памяти
> * защиту памяти mprotect
> * мелкие области памяти emutramp
> * рандомизацию адресного пространства
> Защиту pax атрибутов можно организовать простым патчем к IMA/EVM. И при этом
> есть гарантии неизменности PAX атрибутов. Если вы отключили защиту для некого
> бинаря то защиты естественно у вас нет, но это ваш выбор,
> как и выбор CONFIG_PAX_XATTR_PAX_FLAGS=y

Всё вышенаписанное можно свести к более простому, если без фанатичного переливания из пустого в порожнее:

1) Гарантий нет, защиты можно отключить на лету
2) А если собрать ядро так, что их отключить будет нельзя, работать будет не только лишь всё, что для ОС общего назначения неприемлемо.
3) per doll it sya ради "неизменных PAX атрибутов" никто не будет. Единственная ОС общего назначения, где есть pax mprotect из коробки - netbsd, но и там есть возможность его выключения как глобально, так и для отдельных бинарников.

Короче, блажен кто верует.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128 Ответы: #133

131. Сообщение от Аноним (125), 16-Окт-20, 18:25   –2 +/
Да, DAC это именно Дискретный Контроль Доступа. Минимальная дискретность раздачи прав - пользователь.

Да драйвера файловой системы и сама OS реализует DAC через установку прав на файлы RWX.

Но, ядро OS может и безопасное ядро OS должно, устанавливать права RWX и на страници оперативной памяти. W^X это DAC но реализован для страниц оперативной памяти.

Ядро безопасной OS должно разделять процессы по пользователям которые их запустили. Вася не должен видеть процессы Вовы. В Linux это делает yama или патчи grsecurity. И это тоже DAC по пользователям просто объектами есть процессы в оперативке, а не файлы на диске.

Когда я говорю создавать разные разделы /, /home, /tmp, /var и строго соблюдать принцип DAC: W^X то имею ввиду опции монтирования:
/ exec,ro
/home noexec,rw
/tmp noexec,rw
/var noexec,rw

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #132, #143

132. Сообщение от Дон Ягон (ok), 16-Окт-20, 18:33   +/
DAC - это _модель_ безопасности, т.е. с правами фс или исполняемостью памяти напрямую никак не связано.

Прочий поток сознания комментировать не намерен, и так всё понятно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #134, #135

133. Сообщение от Аноним (125), 16-Окт-20, 19:01   –1 +/
> стандарты POSIX. Которые предполагают, что память может быть доступна и на запись и на чтение

На исполнение и на запись одновременно нельзя! Это вопрос безопасности.

> Как только объективной потребности в этом не будет - её все отключат

А объективной потребности и нет. Ее пытаются создать навязывая никому ненужный JIT, чтобы иметь дыру для реализации эксплоитов с переполнение буфера.

> https://developer.apple.com/documentation/apple_silicon/port...

А Google говорит что Apple их с JIT в chrome послали очень грубо и сказали принести такой же но уже без JIT и Google принес: https://v8.dev/blog/jitless

В Appleb iOS реализация W^X таки строгая?

> firefox без prot_exec не работает. Firefox не нужен?

Мне сегодня уже не нужен. Но когда был нужен запускал без JS и с собранными дополнениями в файловом менеджере. JIT firefox нужен для загрузки дополнений пользователем, а это тоже зло. Попробуй может взлетит и сегодня.

> Мне тут рассказывали (проверять поленился, ибо неинтересно), что подгрузить so'шку (со всеми вытекающими) можно даже при включённом pax mprotect. Т.е. строгость, видимо, таки мнимая.

Там много чего надо включать для полной защиты от "всех сишных дыр". И защита таки есть! Вот пример хорошего дистра GNU/Linux: https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../

> 1) Гарантий нет, защиты можно отключить на лету

Ложь. В нормально настроений системе не отключить.

> 2) А если собрать ядро так, что их отключить будет нельзя, работать будет не только лишь всё, что для ОС общего назначения неприемлемо.

Все теперь собирается без JIT и работает, даже шпионский хром.

> Единственная ОС общего назначения, где есть pax mprotect из коробки - netbsd, но и там есть возможность его выключения как глобально, так и для отдельных бинарников.

Это у теба единственная которую ты знаешь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #137, #140

134. Сообщение от Аноним (134), 16-Окт-20, 19:16   –1 +/
Я реализацию W^X ядром в отношении страниц памяти, а также YAMA в отношении процессов отношу к модели безопасности DAC.

https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Модель DAC не ограничивается файлами на диске, она также касается процессов и страниц/сегментов оперативной памяти.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #136

135. Сообщение от Аноним (134), 16-Окт-20, 19:23   –1 +/
Реализация DAC связана и с файлами ис памятью:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Мы говорим о разной реализации DAC в разных OS. Где то она полная, где то ограничения.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

136. Сообщение от Дон Ягон (ok), 16-Окт-20, 19:38   +2 +/
Я уже не вижу смысла спрашивать, способен ли ты прочитать и осознать то, что я тебе пишу и на что ссылаюь, очевидно, что нет. Но понимаешь ли ты, что то, что ты сейчас написал и скинул всё также ни к селу ни к городу?

Что ты там к чему относишь - вообще абсолютно безразлично. По _определению_ DAC - это модель безопасности, когда условный пользователь _сам_ определяет доступ для других условных пользователей права доступа для принадлежащих ему объектов. Например: доступ к файлам пользователя в unix'ах или доступ к фоткам/записям/etc пользователя в соцсетях - и там и там пользователь _сам_ определяет, у кого есть права, у кого нет. И какие права.

Возвращаясь к _принудительному_ W^X - в каком месте тут DAC? Ты когда-то прочитал клёвую аббревиатуру и теперь таким образом хочешь показать, что ты прошаренный? Получается пока, увы, иначе.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #149

137. Сообщение от Дон Ягон (ok), 16-Окт-20, 19:53   +/
>> стандарты POSIX. Которые предполагают, что память может быть доступна и на запись и на чтение
> На исполнение и на запись одновременно нельзя! Это вопрос безопасности.

На колу мочала, начинаем всё сначала. Оставь, пожалуйста, свои "наивные" эмоции и восклицательные знаки. А также очевидные, но бессмысленные утверждения.

>> Как только объективной потребности в этом не будет - её все отключат
> А объективной потребности и нет. Ее пытаются создать навязывая никому ненужный JIT, чтобы иметь дыру для реализации эксплоитов с переполнение буфера.

Ты так считаешь? Ну вот, пока я не закрыл man security нетбсдшный:

"     PaX MPROTECT affects the following three uses:

           ·   Processes that utilize code generation (such as the JVM) might
               need to have MPROTECT disabled.

           ·   Miscompiled programs that have text relocations, will now core
               dump instead of having their relocations corrected.  You will
               need to fix those programs (recompile them properly).

           ·   Debugger breakpoints: gdb(1) needs to be able to write to the
               text segment in order to insert and delete breakpoints.  This
               will not work unless MPROTECT is disabled on the executable.
"

Сорян, я предпочту поверить примерам netbsd'шников, а не твоим ничем не обоснованным заявлениям.

>> https://developer.apple.com/documentation/apple_silicon/port...
> А Google говорит что Apple их с JIT в chrome послали очень грубо и сказали принести такой же но уже без JIT и
> Google принес: https://v8.dev/blog/jitless

Ни слова про грубый посыл от apple. Хром у меня в mac os работал в те времена, когда W^X в ней уже был (10.4+), а jitless в хромом ещё не было. Ты гони, как говорится, но не загоняйся.

> В Appleb iOS реализация W^X таки строгая?

Возможно, в мобильной версии. В десктопной - нет.

>> firefox без prot_exec не работает. Firefox не нужен?
> Мне сегодня уже не нужен. Но когда был нужен запускал без JS и с собранными дополнениями в файловом менеджере. JIT firefox нужен для загрузки дополнений пользователем, а это тоже зло. Попробуй может взлетит и сегодня.

W|X емнип лисе уже не нужен довольно давно. А вот возможность делать переключения RW -> RX (в предыдущем сообщении я ошибочно написал "-> WX", лол) - нужна. А pax mprotect, он же (в терминологии чуваков из hardenedbsd) W^X pt2 ломает как раз именно эту возможность.

> Это у теба единственная которую ты знаешь.

Да, васин самосборный дистрибутив мне правда неинтересен. А netbsd таки хоть кем-то но используется.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #155

138. Сообщение от Аноним (138), 16-Окт-20, 22:52   +1 +/
То есть, NetBSD - мощь, а Linux маломощный, так сказать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #160

139. Сообщение от PereresusNeVlezaetBuggy (ok), 17-Окт-20, 00:59   +/
Как бээсдэшник со стажем скажу просто: вы обделались.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89

140. Сообщение от Карабьян (?), 17-Окт-20, 01:01   +/
Дополнения в файловом менеджере - как это?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #156

141. Сообщение от t28 (?), 17-Окт-20, 08:52   +/
Да это нeoсилятoр обыкновенный, что с него взять…
Не осилил обыкновенный IPv6, предоставляющий кучу инструментария для конфигурения.
А если сему джентльмену понадобится отконфигурить A2EA (ISO)? Или, скажем, X.121?
Представляю себе количество воплей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

142. Сообщение от СеменСеменыч777 (?), 17-Окт-20, 14:59   +/
> Путин пользуется икспи

это были понты.
обои дефолтные => система свежепоставленая => никто ей не пользовался.

думю что "Путин" использует секретарей-референтов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #144, #145

143. Сообщение от Карабьян (?), 17-Окт-20, 15:40   +/
Как грамотно сделать корень ро?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131

144. Сообщение от Аноним (21), 17-Окт-20, 16:21   +/
Полагаешь, он как и прошлый президент, эплофанбой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #146

145. Сообщение от Аноним (21), 17-Окт-20, 16:23   +/
Ну а дефолтные обои и не засранный рабочий стол это нормально, ты же не удивляешь когда кто-то годами использует только "безмятежность" или новую форточку в качестве обоев. Во всяком случае я всегда так делал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142 Ответы: #147

146. Сообщение от СеменСеменыч777 (?), 17-Окт-20, 17:28   +/
> Полагаешь, он как и прошлый президент, эплофанбой?

полагаю, что ему доводят обстановку вслух специально обученные люди.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144

147. Сообщение от СеменСеменыч777 (?), 17-Окт-20, 17:32   +/
> Ну а дефолтные обои и не засранный рабочий стол это нормально,

1) на дефолтных обоях плохо видны ссылки.
2) если в винде активно работать с документами, то р.стол неизбежно загаживается часто используемыми документами и ссылками для быстрого доступа.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #148

148. Сообщение от Аноним (21), 17-Окт-20, 18:08   +/
Для быстрого доступа есть каталог с файлами быстрого доступа и панель со ссылками в локации на диске для быстрого доступа к каталогам. Нет ничего более отвратительного, чем засранный документами десктоп -- многое говорит о хозяине. И нет, нормально видно, там всякие тени и разноцветные затенения придумали, а я обои ставлю не для того чтобы на их фоне подписи значков рассматривать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147 Ответы: #151

149. Сообщение от Consta (?), 18-Окт-20, 10:41   +1 +/
Камрад, не трать время. Тут персонажа надо к врачу отправлять сразу. Можно было было многое спросить. Например, сможет ли он привести принципиальную матмодель дискреционного монитора обращений или нет. Или является ли NPF реализацией DAC? Но бесполезно...  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136

150. Сообщение от Аноним (100), 18-Окт-20, 11:54   +/
Почему тогда есть пакет с jit?
https://pkgsrc.se/lang/LuaJIT2
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #153

151. Сообщение от СеменСеменыч777 (?), 18-Окт-20, 12:24   +/
> каталог с файлами быстрого доступа и панель со ссылками

это одно лишнее движение мышью + один лишний клик.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #152

152. Сообщение от Аноним (21), 18-Окт-20, 12:51   +/
>> каталог с файлами быстрого доступа и панель со ссылками
> это одно лишнее движение мышью + один лишний клик.

Только на рабочем столе мало места и с сортировкой и поиском проблемы. Как и с менеджментом.

https://www.youtube.com/watch?v=eEdiC-W4L7c

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

153. Сообщение от Аноним (155), 18-Окт-20, 14:26   +/
При включенной строгой W^X любые потом с JIT работать не будут.

Но для быыыдла, можно перегрузится в режиме с отключеной защитой или отключить защиту для отдел ной потом как в PaX.

Я считаю что проблема безопасности в толерантности, нада жостко, сразу послать всех с JIT на убунту или винду. А то эти сволочи сначала JIT в *опу засунут, с потом и systemd, dbus, polkitd...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #154, #157

154. Сообщение от Аноним (155), 18-Окт-20, 14:27   +/
s/потом/проги/ - вражеский спелчекер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

155. Сообщение от Аноним (155), 18-Окт-20, 14:43   +1 +/
> Сорян, я предпочту поверить примерам netbsd'шников, а не твоим ничем не обоснованным заявлениям.

Да, java в W^X работать не будет. Собираю все без java, jit, orc, ...

Надо все пероги пересобирать с правильными опциями компиляции и линковки чтобы они работали с PaX корректно. Неверно собираются единицы, в них надо править код, или использовать нормально написанный аналог.

Gdb в рабочей системе никто не держит - уязвимость.

>Возможно, в мобильной версии. В десктопной - нет.

В новых версиях Mac OSX могли W^X добавить программный для Ынтель процов.

> вот возможность делать переключения RW -> RX

Это неприемлемо в плане безопасности. PaX вполне корректно убивает такой процесс. Исправлять надо именно firefox!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137

156. Сообщение от Аноним (155), 18-Окт-20, 14:47   +/
Дополнения к бровзеру должны распространятся стандартным ПАКЕТНЫМ менеджером. У меня emerge их собирает. И пользователь не должен устанавливать левые.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

157. Сообщение от Аноним (100), 18-Окт-20, 16:24   +/
А эта защита включена по умолчанию в netbsd?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #159

158. Сообщение от Аноним (100), 18-Окт-20, 22:29   +/
А какие не для быдла?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #161

159. Сообщение от Аноним (160), 19-Окт-20, 08:14   +/
Не смотрел. Но должно быть да. Иначе тогда какой в ней смысл?

Здесь лучше ставить два вопроса:

1. Включена ли защита в OS по умолчанию?
2. Есть ли гарантия невозможности отключения защиты в рабочей системе?

От защиты которую можно отключить одной командой толку мало.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

160. Сообщение от Аноним (160), 19-Окт-20, 08:19   +/
Все зависит от дистрибутива Linux.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

161. Сообщение от Аноним (161), 19-Окт-20, 08:54   +/
Ссылку на пример дал: https://www.opennet.ru/openforum/vsluhforumID3/122116.html#112

Проверить любой *NIX, для быдла он или для людей можно двумя командами:

1. paxtest blackhat

2. checksec --file=/bin/ls

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158

162. Сообщение от Аноним (161), 19-Окт-20, 09:12   +/
> Я не слишком хорошо знаком с актуальным состоянием ядра linux в этом месте, точно не знаю.

А давай посмотрим на корень проблемы?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Executable code and read-only data must not be writable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Any areas of the kernel with executable memory must not be writable.
While this obviously includes the kernel text itself, we must consider
all additional places too: kernel modules, JIT memory, etc. (There are
temporary exceptions to this rule to support things like instruction
alternatives, breakpoints, kprobes, etc. If these must exist in a
kernel, they are implemented in a way where the memory is temporarily
made writable during the update, and then returned to the original
permissions.)

In support of this are ``CONFIG_STRICT_KERNEL_RWX`` and
``CONFIG_STRICT_MODULE_RWX``, which seek to make sure that code is not
writable, data is not executable, and read-only data is neither writable
nor executable.

Most architectures have these options on by default and not user selectable.
For some architectures like arm that wish to have these be selectable...

Корнем проблемы и раздора есть фраза: "There are
temporary exceptions to this rule to support things like ..." вот из-за этих временных исключений в некоторых дистрибутивах GNU/Linux есть дыры. В строгих дистрах GNU/Linux исключений не делают, в них уязвимостей нет, нет и дерьма типа: firefox, JIT, orc, java, ...

> remote root там таки возможен.

Не во всех дистрибутивах GNU/Linux. Есть дистрибутивы GNU/Linux в ко орых эксплуатация любых уязвимостей переполнения буфера (bufferoverwrite) невозможна.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122


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

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




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру