В NetBSD устранена уязвимость, вызванная отсутствием проверки границ буфера при обработке jumbo-пакетов в драйверах для сетевых адаптеров, подключаемых по USB. Проблема приводит к копированию части пакета за пределы буфера, выделенного в кластере mbuf, что потенциально может использоваться для выполнения кода атакующего на уровне ядра через отправку определённых кадров из локальной сети. Исправление для блокирования уязвимости внесено 28 августа, но сведения о проблеме раскрыты только сейчас. Проблема затрагивает драйверы atu, axe, axen, otus, run и ure...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53888
Exploitable-over-net-BSD
Ну отключи NetBSD от Net
От USB-адаптера Ethernet. Саму по себе NetBSD можно встретить довольно редко, а уж системы с NetBSD и такими сетевыми картами вообще, наверное, по пальцам пересчитать можно. Почему-то представился гик-хипстер, установивший NetBSD на Macbook, который при этом предпочитает не пользоваться WiFi.
правильно объединили новости : бсд и венда
> правильно объединили новости : бсд и вендаНу да, хоть в новостях будет единение, WSB им-то не светит!
Правильно добавили в список ссылок ниже, первым пунктом:
OpenNews: Удалённая уязвимость в systemd-networkd
Если WSL - это немного оптимизированная виртуалка с линуксом - то WSB существует уже давно.
Ваш Вайн это виртуалка, а wsl это интерпретатор. Двуличные сектанты-представители свободки
А кого wsl интерпретирует?
В Гугле забанили? Понимаю
https://ru.m.wikipedia.org/wiki/Windows_Subsystem_for_Linux
>jumbo-пакетовЭто, вроде, называется jumbo frame. Кадр. По аналогии с Ethernet кадрами. По ссылке "packet", но мне кажется это опечатка.
>>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" Что они ожидали?
Вся автоконфигурация в v6 - одна большая сплошная дыра.
Упреждая вопли про DHCP в v4, сразу же:
В отличие от v4, руками конфигурировать те же v6 адреса - ад адешный.
Плюс надо не забыть отключить линк-локал, шлак и приём RA.
> В отличие от v4, руками конфигурировать те же v6 адреса - ад адешный.by design, угу. Предполагалось что все сделают за тебя умные технологии (ну мы помним, да - ключи от всего у кого-то поумнее хозяина системы), и тебе никогда в жизни не придется запоминать и безошибочно набирать эту бредятину (по-моему, разработчики были из неосиляторов v4, и реально думали, что все кругом испытывают те же трудности) - правда, как обычно, на пол-дороге выяснилось, что RA - это еще немного не все, и dhcp, ну надо же, ТОЖЕ нужно - кто бы мог подумать, и было ли ему - чем?
Всё потому что тебя там не было.
Его, не его, но судя по количеству глупостей в протоколе и по триумфальному внедрению IPv6 там крайне не хватало практикующих сетевых инженеров.
Не надо переоценивать умственные способности большинства практикующих сетевых инженеров.Практикующий сетевой инженер лучше сделает приватную сеть из 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-адреса определённый абонент в определённое время выходил в интернет и ему ли принадлежит трафик с определённого порта.
Как говорится, мне некогда точить пилу, мне нужно пилить.
эт точно !
Сразу видно что большими сетями вы не занимались...
> Сразу видно что большими сетями вы не занимались...Сам не занимался, наблюдал как этим занимаются другие. Хотя, "большие сети" - понятие растяжимое. Это сеть самого популярного провайдера в городе-миллионнике и различных посёлках вокруг него.
>Предполагалось что все сделают за тебя умные технологии (ну мы помним, да - ключи от всего у кого-то поумнее хозяина системы)Мьсе из тех, кто ARP-, FDB-таблицы и таблицы маршрутизации на каждом сетевом узле заполняет вручную? DHCP, LLDP, VGRP, VTP, BGP, OSPF, RIP никогда не пользуется? RA из той же оперы, если что.
>на пол-дороге выяснилось, что RA - это еще немного не все, и dhcp, ну надо же, ТОЖЕ нужно - кто бы мог подумать, и было ли ему - чем?
DHCP не нужен, если устройству достаточно получить IPv6-префикс и узнать IPv6-адрес маршрутизатора. Мне коммутаторы попадались, на которых DNS-серверы в принципе некуда указать. Вот таким устройствам этого достаточно.
Всё остальное отдано наоткуп DHCPv6, где можно и адреса DNS-, NTP- и даже TFTP-серверов раздавать или там статические маршруты. Вполне разумно, я считаю.
> руками конфигурировать те же v6 адреса - ад адешныйЧоита?
iface eth0 inet6 static
address 2a0x:xxxx:xx:xxx:x::2/64
gateway 2a0x:xxxx:xx:xxx:x::1
> Чоита?
> iface eth0 inet6 static
> address 2a0x:xxxx:xx:xxx:x::2/64
> gateway 2a0x:xxxx:xx:xxx:x::1Сконфигурируй мне v6 без DHCP на PPPoE, который может подключаться к концентраторам, на которых разные подсети.
Без link-local и без RA с шлаком.
Я тебе сразу отвечу: не получится.
Потому что в PPP эти мажоры от академиков механизма конфигурации не-link-local вообще не предусмотрели.
За что могут гореть в аду.
Ну и угу, потом если у тебя приём RA при этом не отключен, прилетает RA от левого устройства, и вся твоя конфигурация благополучно ложится.
> Ну и угу, потом если у тебя приём RA при этом не
> отключен, прилетает RA от левого устройства, и вся твоя конфигурация благополучно
> ложится.Не отключал (в явном виде). Не ложится.
Насчёт "сконфигурируй мне" - не буду, потому что ты сначала сделал общее утверждение о сложности, а затем внезапно перешёл к частностям. При этом не отрицаю, что описанный тобой частный случай может быть проблематичным, но утверждаю, что мой частный случай совершенно беспроблемен.
Ну, сеансовые подключения, что ты хочешь. Ты и сетку IPv4 в описанной ситуации вряд ли сможешь перероутить без использования какого-нибудь протокола динамической маршрутизации.
Да это нeoсилятoр обыкновенный, что с него взять…
Не осилил обыкновенный IPv6, предоставляющий кучу инструментария для конфигурения.
А если сему джентльмену понадобится отконфигурить A2EA (ISO)? Или, скажем, X.121?
Представляю себе количество воплей.
> приводит к копированию части пакета за пределы буфера*facepalm*
даже комментировать не хочется... а то сразу набегут сами знаете кто
Прокоментируй как будешь писать драйвер без unsafe кода, я подожду.
Прокомментируй, как будешь писать драйвер, работающий с сетью, начисто забив на проверку длины и выход за границы, я подожду.
Хотя, зачем твой коммент ? Тут бы коммент автора, который УЖЕ написал тот драйвер.
> Stack smashing protection No
> Forward-edge control flow protection No
> Backward-edge control flow protection (e.g., shadow and safe stack) Noдаже комментировать не хочется... а то сразу набегут сами знаете кто (растовики со смузи доказывать что вы фсё фрёте)
https://www.cvedetails.com/vulnerability-list/vendor_id-1902...Совсем нет переполнений, угу :^)
> отсутствием проверки границ буфера при обработке jumbo-кадровНу в принципе любой может ошибиться, от языка это не зависит. На любом языке можно внести дыру безопасности.
На любом языке кроме языка Ада
А в Аде совсем нет возможности перейти к работе напрямую с адресами памяти?
Конечно. А ещё там - парсеры, способные абсолютно безошибочно разбирать мусор любого, даже заранее неизвестного формата( включая битый ), приходящий от сторонних источников. Ну это, если верить анонам, именующим его нереально-безопасным( аноны, правда, и про рубин_на_рельсах и про его невероятную скорость и удобство что-то говорили, но.. какой с анонов спрос ? )
>> кроме языка Ада
> в Аде совсем нет возможностиТам аватарка намекает, что вы о разных языках ...
Нет, мы об одном и том-же языке. Ада насколько мне хватает моих знаний гораздо безопаснее плюсов и всяческой кофейной гущи.
>> насколько мне хватает моих знанийАда просто заставляет писать обработчики исключительных ситуаций.
Правильно это будет написано или нет зависит - от человека. А то можно и заглушку поставить.Эрудит,мля :)
Ada не устраняет человеческий фактор. Софт Ariane-5, между прочим, на ней был написан
Это другое™
Верно
>На любом языке можно внести дыру безопасности.Даже на языке жестов?
На нём особенно. В разных культурах одни и те же жесты имеют совершенно разный смысл. Лучше никогда не используйте за границей привычные вам жесты, если вы на 100% не уверены в их значении для местного населения.
> В NetBSD устранена уязвимость, вызванная отсутствием проверки границ буфера при обработкеУважаемый FractaL, NetBSD это вам не GNU/Linux, хоть и написан на C. Любые эксплоиты использующие переполнение буфера в ядре ОС NetBSD или программах исполняющихся на ядре NetBSD работать не будут.
Почему переполнение буфера, в ядре NetBSD написанном на C и прогах написанных на C, запущенных на ядре NetBSD, работать не будет?
Так почему же, интересно? Какая-то защита, сборка с флагами или что?
Ядро OS NetBSD строго следит за соблюдением главного правила безопасности DAC: https://www.opennet.dev/openforum/vsluhforumID3/122116.html#112
DAC от атак, связанных с переполнением буфера не помогает. К тому же неясно, что иненно уникального в DAC netbsd. Ну как у всех же её DAC.
W^X и NX инструкции процессора расширяют DAC на страници оперативной памяти. Ядро NetBSD имеет поддержку W^X как для ядра, так и для всех процессов. W^X это DAC просто права выставляются не файловой системой для файла, а ядром и процессором для страниц оперативной памяти.
> Ядро OS NetBSD строго следит за соблюдением главного правила безопасности DAC: https://www.opennet.dev/openforum/vsluhforumID3/122116.html#112Хватит уже тиражировать свою чушь про DAC. То, на что ты сослался далее (https://www.opennet.dev/opennews/art.shtml?num=50763) не имеет никакого отношения к тому, о чём речь сейчас.
И в ядре netbsd и в ядре openbsd реализован W^X для _ядра_ (в netbsd, ЕМНИП, появилось раньше, чем в openbsd) и именно поэтому уязвимости из новости могут только обрушить их ядра, но не выполнить код с правами ядра.
То, что описано в "Планах по усилению механизма защиты W^X в OpenBSD", на который ты почему-то ссылаешься - это про юзерспейс. То есть, на текущие уязвимости никакого влияния не оказывает. И, если что, решение "не форсить W^X pt 2" было принято сильно раньше того, что описывается в той новости. Хотя, кому надо, может и зафорсить средствами pledge.
> именно поэтому уязвимости из новости могут только обрушить их ядра, но не выполнить код с правами ядра.Об этом и речь,что уязвимости нет. Падение ядра будет.
W^X это от DAC просто область применение не файл на диске, а страницы оперативной памяти и реализация в ядре OS необходима дополнительная. А по сути принцип DAC - пользователь должен иметь право только исполнять бинарь, а не изменять.
> по сути принцип DAC - пользователь должен иметь право только исполнять бинарь, а не изменять.Чего?
DAC = discretionary access control? Или ты имеешь ввиду что-то другое?https://security.stackexchange.com/questions/63518/mac-vs-da... - мне сложно что-то добавить к тому, что здесь написано про DAC.
Т.е. в рамках модели DAC любой пользователь может определить какие права будут иметь другие пользователи на действия с его файлами + рут, который нарушает DAC и может всё. При чём тут W^X / W|X вообще?
Да, 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
DAC - это _модель_ безопасности, т.е. с правами фс или исполняемостью памяти напрямую никак не связано.Прочий поток сознания комментировать не намерен, и так всё понятно.
Я реализацию 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 не ограничивается файлами на диске, она также касается процессов и страниц/сегментов оперативной памяти.
Я уже не вижу смысла спрашивать, способен ли ты прочитать и осознать то, что я тебе пишу и на что ссылаюь, очевидно, что нет. Но понимаешь ли ты, что то, что ты сейчас написал и скинул всё также ни к селу ни к городу?Что ты там к чему относишь - вообще абсолютно безразлично. По _определению_ DAC - это модель безопасности, когда условный пользователь _сам_ определяет доступ для других условных пользователей права доступа для принадлежащих ему объектов. Например: доступ к файлам пользователя в unix'ах или доступ к фоткам/записям/etc пользователя в соцсетях - и там и там пользователь _сам_ определяет, у кого есть права, у кого нет. И какие права.
Возвращаясь к _принудительному_ W^X - в каком месте тут DAC? Ты когда-то прочитал клёвую аббревиатуру и теперь таким образом хочешь показать, что ты прошаренный? Получается пока, увы, иначе.
Камрад, не трать время. Тут персонажа надо к врачу отправлять сразу. Можно было было многое спросить. Например, сможет ли он привести принципиальную матмодель дискреционного монитора обращений или нет. Или является ли NPF реализацией DAC? Но бесполезно...
Реализация DAC связана и с файлами ис памятью:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Мы говорим о разной реализации DAC в разных OS. Где то она полная, где то ограничения.
Как грамотно сделать корень ро?
Как бээсдэшник со стажем скажу просто: вы обделались.
Со всеми бывает.
> Удалённая уязимость в ядре NetBSD, эксплуатируемая из локальной сетиНо как же так? Её же делают профессиональные порфессионалы, а не какие-то лaпчaтые выскачки!
Ага, делают, только не используют - нетка и pkgsrc уже давно кросскомпилится из линукса, дураков, которые используют это на десктопе тем более нет. Поэтому что есть дыра, что нет дыры...
del
Да ладно. В японии много кто на десктопах-то. Как было, так и есть.
Гляньте молодой человек вот это https://www.youtube.com/channel/UCk9NvmsPBC3lTn_L9kFaylA
Простой американский крестьянин вполне себе пользуется и даже показывает разницу в реализации базовой системы опенка фришки нетки и лапчатого.
Так, загибаю большой палец: один пользователь есть. Держу остальные пальцы наготове: посчитаем всех пользователей NetBSD!
Забавное наблюдение -- я в случае пальцевого счёта начинаю с мизинца. Причём даже в том случае если мне приходится задействовать пальцы второй руки.
Забавное наблюдение.
Stahl либо использует для счёта правую руку, либо - считает справа налево, что.. довольно странно для человека, читающего слева направо.
Да, я начинаю счёт с правой руки.
Лучше гляньте в pkgsrc (или погуглите про это) и убедитесь, что линуксоидов и яблочников даже там больше, нежели нетбсдшников.
Да ну, какие они профессионалы? Уязвимостей всего в 15 раз меньше, чем в Линуксе.https://www.cvedetails.com/product/84/Netbsd-Netbsd.html?ven...
https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
А это точно не потому что линукс примерно в 150 раз популярнее? И когда там кстати последний раз remote root в ядре был?
Звучит эпично, но по факту - так себе. Ну в смысле что локальная сеть + usb-свистки - не слишком высокий шанс на реальную эксплуатацию.А вот объединение с новостью про винду позабавило.
Почему? Известно же где они код берут, вроде и не секрет.
> локальная сеть + usb-свисткиraspberry pi
Кто-то может сказать, это действительно драйвера оказались уязвимы, или это Васян-драйвер включили в ядро и поэтому теперь это называют уязвимостью БСД а не уязвимостью Васян-драйвера?
Откуда взялись драйвера можно посмотреть в man'ах, всё как обычно. Драйвера, перечисленные в новости были портированны разработчиками netbsd из openbsd и один драйвер из freebsd. Портированы достаточно давно, т.е. не вчера. Например, axe появился в netbsd 3.0, а otus - в netbsd 6.Про наличие аналогичных уязвимостей в open/free bsd мне ничего не известно.
> Про наличие аналогичных уязвимостей в 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'ы найти-почитать да с оригиналом сравнить. Жаль нетбсдшники не публикуют патчи в секьюрити-анонсах (ну или я в глаза сношаюсь), как опенбсдшники, было бы чуть удобнее.
> Баги нашёл один и тот же человек, к слову.
> Ilja Van SprundelОн, кстати, норм так набрасывать умеет: https://www.csoonline.com/article/3250653/is-the-bsd-os-dyin...
А заголовки в статье так вообще желтушные: "NetBSD the "clear loser" in terms of code quality". Тро-ло-ло.
Это диверсия со стороны OpenBSD! Чтобы стать более безопасной нужно сделать другие ОС менее безопасными.
> Кто-то может сказать, это действительно драйвера оказались уязвимы, или это Васян-драйвер включили в ядро и поэтому теперь это называют уязвимостью БСД а
> не уязвимостью Васян-драйвера?Да все просто!
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 innetbsd-9:
Если драйвер для BSD - значит уязвимость в БСД, ведь там одни неосиляторы и неудачники (мы все так говорим, а значит это правда!)
А вот если бы драйвер был для Пингвинчика, то пришлось бы разбираться, почему очередной Васян налажал!
Скажи net BSD.
"начиная с обновления 1709"
как знал что говнокодят
Радует, что с привычкой на винде и не только отключать IPv6 сразу же после развёртывания системы (а то и вместе с развёртыванием) это не особо страшно :) IPv6 одна большая сплошная дыра в целом, начиная с лёгкой возможности захламления neighbor-таблиц.
Хаха - я вот был немного удивлен, узнав какой танец-с-граблями надо исполнять в современном редхламе, чтобы отключить совсем и навсегда. Полагаю, в следующей версии уже не будет отключаться вообще (а там и винда подтянется)
Да ладно, какой там танец с граблями.
Две строчки в sysctl. Или один параметр в параметры ядра.
Параметр - ipv6.disable=1
sysctl - net.ipv6.conf.all.disable_ipv6=1 , net.ipv6.conf.default.disable_ipv6=1
к сожалению, это не работает.
система игнорирует эти настройки и всё равно поднимает ипв6, если встречает что-нибудь про него в каком-либо из других конфигов, как минимум это /etc/hosts и /etc/ssh/sshd_config.
все конфиги не помню, записаны где-то в мануале "как отключить это сраное дерьмо говна v6" на рабочем компе.
С sysctl может быть беда, если кто-то перепишет /proc/...
Опция ядра работает железно.
У нас немножко другой коленкор, у нас инфраструктурные системы кастомизированы, и по умолчанию интегрирован systemd-networkd, там две строчки в .conf-файле на интерфейсах.LinkLocalAddressing=no
IPv6AcceptRA=noПервое заодно фигачит 169.254.x.x, который в других случаях надо через /etc/sysconfig/network параметро NOZEROCONF=yes выключать.
Тебя ждёт неожиданность, так как Exchange не устанавливается без IPv6
Наш виндоадмин спокойно гоняет Exchange без IPv6 уже лет эннадцать.
Мда ... люди теряют навыки чтения (или понимания того, что написано).Сходи в словарь и найди различия между словами "устанавливается" и "работает"
Ещё раз: нашему виндоадмину это фиолетово :)
Не знаю, может он включал v6, делал major update, и потом выключал, но в любом случае это прошло быстро и незаметно.
Ничего идеального в мире it нет и не будет, дыры есть были и будут. Всё расходимся.
>Уязвимость проявляется начиная с обновления 1709 для Windows 10"СЕМЁРКА НЕБЕЗОПАСНА, ПЕРЕХОДИТЕ НА 10КУ!" - говорили некоторые.
От наличия уязвимости в десятке, семёрка безопаснее не станет. Десятку исправят, в отличие от.
Микромягкие прогнулись и продлили до 2023 года поддержку семерки.
Так что можешь откатиться)
Прогнулись, получая за это деньги.
Зато ХР стаёт безопаснее 10 с каждым обновлением 10.
ни одного (неофициального) аудита кода ХР еще не было.
> ни одного (неофициального) аудита кода ХР еще не было.Ну код приоткрыли же :D
Путин пользуется икспи, по телевизору показывали. Вроде бы икспи единственная сертифицированная (ну просто там следящих компонентов ещё не было.)
A что не Роса с Эльбрусом?
> Путин пользуется икспиэто были понты.
обои дефолтные => система свежепоставленая => никто ей не пользовался.думю что "Путин" использует секретарей-референтов.
Полагаешь, он как и прошлый президент, эплофанбой?
> Полагаешь, он как и прошлый президент, эплофанбой?полагаю, что ему доводят обстановку вслух специально обученные люди.
Ну а дефолтные обои и не засранный рабочий стол это нормально, ты же не удивляешь когда кто-то годами использует только "безмятежность" или новую форточку в качестве обоев. Во всяком случае я всегда так делал.
> Ну а дефолтные обои и не засранный рабочий стол это нормально,1) на дефолтных обоях плохо видны ссылки.
2) если в винде активно работать с документами, то р.стол неизбежно загаживается часто используемыми документами и ссылками для быстрого доступа.
Для быстрого доступа есть каталог с файлами быстрого доступа и панель со ссылками в локации на диске для быстрого доступа к каталогам. Нет ничего более отвратительного, чем засранный документами десктоп -- многое говорит о хозяине. И нет, нормально видно, там всякие тени и разноцветные затенения придумали, а я обои ставлю не для того чтобы на их фоне подписи значков рассматривать.
> каталог с файлами быстрого доступа и панель со ссылкамиэто одно лишнее движение мышью + один лишний клик.
>> каталог с файлами быстрого доступа и панель со ссылками
> это одно лишнее движение мышью + один лишний клик.Только на рабочем столе мало места и с сортировкой и поиском проблемы. Как и с менеджментом.
а вот переписали бы на Rust и таких проблем не было бы
На lua.
так перепиши. я вообще хотел бы глянуть как перепишется любая ось на расте без unsafe))) раст же безопасный. так покажите плюсовикам и прочим как он крут. особенно ядрышко системы и драйвера))))
Смотри A2, blue botle - не на C, без проблем и безопасно.И с безопасностью C нет никаких проблем: https://www.opennet.dev/openforum/vsluhforumID3/122116.html#90
Проблему с C некоторые пытаются создать в ваших головах. И да эта проблема имеет место только в плохих ядрах OS и плохих компилятора, линковщиках.
ну я как раз и понимаю, что проблема не самого языка. скорее тех кто пишет на нем. если уж говорить про с/с++, то он и правда требует более высокой квалификации, но взамен дает боле мощный и управляемый инструмент. просто этот инструмент требует хорошего понимания и знания, а народ малость обленел. им здесь и сейчас и попроще. естественно мало кто хочет тратить столько времени на познание языка. это как авто с механикой и автоматом. механика дает управление точнее, но автомат проще.
За 100500 лет может и смогут поцтеринги что-то переписать на раст.
> В NetBSD устранена уязвимость, вызванная отсутствием проверки границ буфера при обработкеЛюбые эксплоиты использующие переполнение буфера в ядре ОС NetBSD или программах исполняющихся на ядре NetBSD работать не будут.
Данной уязвимости НЕСУЩЕСТВУЕТ!
Возможен максимум DoS или падение ядра NetBSD, в зависимости от политики реализации защиты от переполнения буфера при отсутствии проверки границ буфера в ядре NetBSD.
Очень интересно. В каких ОС ещё есть подобная защита, в каких нет? Особенно интересно про остальное семейство BSD и Linux.
Посмотри информацию на официальных сайтах интересующих 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 - отсутствует.
Спасибо за ответ. А в чём отличие дырявой от строгой?
Строгая это строгая без копромисов. Когда разработчики ядра строго и без копромисов отказывают всем в поддержке JIT-подобным технологиям.Дырявая это когда разрабы ядра прогнулись, пошли на компромисс и оставили возможности запуска JIT-приложений и работы JIT-компиляторов.
Тео Де Раадт прогнулся, стал раком перед JIT и отказался от строгой защиты памяти в OpenBSD: https://www.opennet.dev/opennews/art.shtml?num=50763Теперь в OpenBSD есть возможность запуска ненужных JIT-приложений и большая дырень в W^X для реализации эксплоитов на базе переполнения буфера.
Ты путаешь юзерспейсный и ядерный 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 позволяет что-то гарантировать, а где нет, ага.
>Очевидно, что remote root в netbsd/openbsd невозможен (из-за этих дыр) как раз из-за ядерного W^X.А если в Linux, то возможен?
>>Очевидно, что remote root в netbsd/openbsd невозможен (из-за этих дыр) как раз из-за ядерного W^X.
> А если в Linux, то возможен?Я не слишком хорошо знаком с актуальным состоянием ядра linux в этом месте, точно не знаю.
Но, судя, например, по https://www.opennet.dev/opennews/art.shtml?num=53892 - remote root там таки возможен.
> linux ... remote root там таки возможенТолько в дистрибутивах для быдла.
А какие не для быдла?
Ссылку на пример дал: https://www.opennet.dev/openforum/vsluhforumID3/122116.html#112Проверить любой *NIX, для быдла он или для людей можно двумя командами:
1. paxtest blackhat
2. checksec --file=/bin/ls
То есть, NetBSD - мощь, а Linux маломощный, так сказать.
Все зависит от дистрибутива Linux.
> Я не слишком хорошо знаком с актуальным состоянием ядра 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) невозможна.
> в 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
> Тео отдал программисту право изменят исполняемый код программы.Не Тео, а стандарты 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, но и там есть возможность его выключения как глобально, так и для отдельных бинарников.Короче, блажен кто верует.
> стандарты 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, но и там есть возможность его выключения как глобально, так и для отдельных бинарников.
Это у теба единственная которую ты знаешь.
>> стандарты 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 таки хоть кем-то но используется.
> Сорян, я предпочту поверить примерам netbsd'шников, а не твоим ничем не обоснованным заявлениям.Да, java в W^X работать не будет. Собираю все без java, jit, orc, ...
Надо все пероги пересобирать с правильными опциями компиляции и линковки чтобы они работали с PaX корректно. Неверно собираются единицы, в них надо править код, или использовать нормально написанный аналог.
Gdb в рабочей системе никто не держит - уязвимость.
>Возможно, в мобильной версии. В десктопной - нет.
В новых версиях Mac OSX могли W^X добавить программный для Ынтель процов.
> вот возможность делать переключения RW -> RX
Это неприемлемо в плане безопасности. PaX вполне корректно убивает такой процесс. Исправлять надо именно firefox!
Дополнения в файловом менеджере - как это?
Дополнения к бровзеру должны распространятся стандартным ПАКЕТНЫМ менеджером. У меня emerge их собирает. И пользователь не должен устанавливать левые.
> Данной уязвимости НЕСУЩЕСТВУЕТ!Значит NetBSD обновлять не надо!!! А то и к ней уже добрались и под видом исправления через обновление Троян забросят...
Взломать нельзя, но ядро упасть может. Написано же было.
> ядро упасть можетУ меня нормальные сетевухи, а не usb. Мне и думаю остальным обновлялся не надо.
Почему тогда есть пакет с jit?
https://pkgsrc.se/lang/LuaJIT2
При включенной строгой W^X любые потом с JIT работать не будут.Но для быыыдла, можно перегрузится в режиме с отключеной защитой или отключить защиту для отдел ной потом как в PaX.
Я считаю что проблема безопасности в толерантности, нада жостко, сразу послать всех с JIT на убунту или винду. А то эти сволочи сначала JIT в *опу засунут, с потом и systemd, dbus, polkitd...
s/потом/проги/ - вражеский спелчекер.
А эта защита включена по умолчанию в netbsd?
Не смотрел. Но должно быть да. Иначе тогда какой в ней смысл?Здесь лучше ставить два вопроса:
1. Включена ли защита в OS по умолчанию?
2. Есть ли гарантия невозможности отключения защиты в рабочей системе?От защиты которую можно отключить одной командой толку мало.