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

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

Сообщения

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

1. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+9 +/–
Сообщение от Аноним (1), 14-Окт-20, 11:44
Exploitable-over-net-BSD
Ответить | Правка | Наверх | Cообщить модератору

	54. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–3 +/–
	Сообщение от VINRARUS (ok), 14-Окт-20, 18:39
	Ну отключи NetBSD от Net
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	34. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+5 +/–
	Сообщение от Аноним (-), 14-Окт-20, 13:50
	> правильно объединили новости : бсд и венда Ну да, хоть в новостях будет единение, WSB им-то не светит! Правильно добавили в список ссылок ниже, первым пунктом: OpenNews: Удалённая уязвимость в systemd-networkd
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	96. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от daemontux (?), 15-Окт-20, 09:25
	А кого wsl интерпретирует?
	Ответить | Правка | Наверх | Cообщить модератору

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

4. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+2 +/–
Сообщение от A.Stahl (ok), 14-Окт-20, 11:47
>jumbo-пакетов Это, вроде, называется jumbo frame. Кадр. По аналогии с Ethernet кадрами. По ссылке "packet", но мне кажется это опечатка.
Ответить | Правка | Наверх | Cообщить модератору

6. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+2 +/–
Сообщение от Аноним (6), 14-Окт-20, 12:02
>>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. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+5 +/–
	Сообщение от Онаним (?), 14-Окт-20, 14:03
	Вся автоконфигурация в v6 - одна большая сплошная дыра.
	Ответить | Правка | Наверх | Cообщить модератору

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

	44. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+1 +/–
	Сообщение от пох. (?), 14-Окт-20, 14:11
	> В отличие от v4, руками конфигурировать те же v6 адреса - ад адешный. by design, угу. Предполагалось что все сделают за тебя умные технологии (ну мы помним, да - ключи от всего у кого-то поумнее хозяина системы), и тебе никогда в жизни не придется запоминать и безошибочно набирать эту бредятину (по-моему, разработчики были из неосиляторов v4, и реально думали, что все кругом испытывают те же трудности) - правда, как обычно, на пол-дороге выяснилось, что RA - это еще немного не все, и dhcp, ну надо же, ТОЖЕ нужно - кто бы мог подумать, и было ли ему - чем?
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	83. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+1 +/–
	Сообщение от www2 (??), 15-Окт-20, 07:48
	Не надо переоценивать умственные способности большинства практикующих сетевых инженеров. Практикующий сетевой инженер лучше сделает приватную сеть из 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ообщить модератору

	93. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от 1 (??), 15-Окт-20, 09:05
	эт точно !
	Ответить | Правка | Наверх | Cообщить модератору

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

	163. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от www2 (??), 11-Дек-20, 14:14
	> Сразу видно что  большими сетями вы не занимались... Сам не занимался, наблюдал как этим занимаются другие. Хотя, "большие сети" - понятие растяжимое. Это сеть самого популярного провайдера в городе-миллионнике и различных посёлках вокруг него.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от 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-серверов раздавать или там статические маршруты. Вполне разумно, я считаю.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	78. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним 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
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	85. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Онаним (?), 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ообщить модератору

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

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

	107. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним 80_уровня (ok), 15-Окт-20, 13:30
	> Ну и угу, потом если у тебя приём RA при этом не > отключен, прилетает RA от левого устройства, и вся твоя конфигурация благополучно > ложится. Не отключал (в явном виде). Не ложится. Насчёт "сконфигурируй мне" - не буду, потому что ты сначала сделал общее утверждение о сложности, а затем внезапно перешёл к частностям. При этом не отрицаю, что описанный тобой частный случай может быть проблематичным, но утверждаю, что мой частный случай совершенно беспроблемен. Ну, сеансовые подключения, что ты хочешь. Ты и сетку IPv4 в описанной ситуации вряд ли сможешь перероутить без использования какого-нибудь протокола динамической маршрутизации.
	Ответить | Правка | Наверх | Cообщить модератору

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

7. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+2 +/–
Сообщение от Аноним (7), 14-Окт-20, 12:18
> приводит к копированию части пакета за пределы буфера *facepalm* даже комментировать не хочется... а то сразу набегут сами знаете кто
Ответить | Правка | Наверх | Cообщить модератору

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

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

	15. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
	Сообщение от Аноним (11), 14-Окт-20, 12:51
	> Stack smashing protection     No > Forward-edge control flow protection     No > Backward-edge control flow protection (e.g., shadow and safe stack)     No даже комментировать не хочется... а то сразу набегут сами знаете кто (растовики со смузи доказывать что вы фсё фрёте)
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	18. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+2 +/–
	Сообщение от Аноним (11), 14-Окт-20, 12:53
	https://www.cvedetails.com/vulnerability-list/vendor_id-1902... Совсем нет переполнений, угу :^)
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

8. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+2 +/–
Сообщение от FractaL (?), 14-Окт-20, 12:28
> отсутствием проверки границ буфера при обработке jumbo-кадров Ну в принципе любой может ошибиться, от языка это не зависит. На любом языке можно внести дыру безопасности.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

	31. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+1 +/–
	Сообщение от Аноним84701 (ok), 14-Окт-20, 13:24
	>> кроме языка Ада > в Аде совсем нет возможности Там аватарка намекает, что вы о разных языках ...
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

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

	48. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+1 +/–
	Сообщение от Аноним (48), 14-Окт-20, 16:29
	>> насколько мне хватает моих знаний Ада просто заставляет писать обработчики исключительных ситуаций. Правильно это будет написано или нет зависит - от человека. А то можно и заглушку поставить. Эрудит,мля :)
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+2 +/–
	Сообщение от nomad__ (ok), 14-Окт-20, 14:02
	Ada не устраняет человеческий фактор. Софт Ariane-5, между прочим, на ней был написан
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	71. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (70), 14-Окт-20, 22:11
	Это другое™
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (53), 14-Окт-20, 17:41
	Верно
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	56. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от VINRARUS (ok), 14-Окт-20, 18:46
	>На любом языке можно внести дыру безопасности. Даже на языке жестов?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

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

	89. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
	Сообщение от Аноним (89), 15-Окт-20, 08:27
	> В NetBSD устранена уязвимость, вызванная отсутствием проверки границ буфера при обработке Уважаемый FractaL, NetBSD это вам не GNU/Linux, хоть и написан на C. Любые эксплоиты использующие переполнение буфера в ядре ОС NetBSD или программах исполняющихся на ядре NetBSD работать не будут. Почему переполнение буфера, в ядре NetBSD написанном на C и прогах написанных на C, запущенных на ядре NetBSD, работать не будет?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

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

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

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

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

	123. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+1 +/–
	Сообщение от Дон Ягон (ok), 16-Окт-20, 16:24
	> Ядро 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.
	Ответить | Правка | К родителю #113 | Наверх | Cообщить модератору

	124. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
	Сообщение от Аноним (125), 16-Окт-20, 17:05
	> именно поэтому уязвимости из новости могут только обрушить их ядра, но не выполнить код с правами ядра. Об этом и речь,что уязвимости нет. Падение ядра будет. W^X это от DAC просто область применение не файл на диске, а страницы оперативной памяти и реализация в ядре OS необходима дополнительная. А по сути принцип DAC - пользователь должен иметь право только исполнять бинарь, а не изменять.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+1 +/–
	Сообщение от Дон Ягон (ok), 16-Окт-20, 17:49
	> по сути принцип DAC - пользователь должен иметь право только исполнять бинарь, а не изменять. Чего? DAC = discretionary access control? Или ты имеешь ввиду что-то другое? https://security.stackexchange.com/questions/63518/mac-vs-da... - мне сложно что-то добавить к тому, что здесь написано про DAC. Т.е. в рамках модели DAC любой пользователь может определить какие права будут иметь другие пользователи на действия с его файлами + рут, который нарушает DAC и может всё. При чём тут W^X / W|X вообще?
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–2 +/–
	Сообщение от Аноним (125), 16-Окт-20, 18:25
	Да, 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ообщить модератору

	132. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Дон Ягон (ok), 16-Окт-20, 18:33
	DAC - это _модель_ безопасности, т.е. с правами фс или исполняемостью памяти напрямую никак не связано. Прочий поток сознания комментировать не намерен, и так всё понятно.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
	Сообщение от Аноним (134), 16-Окт-20, 19:16
	Я реализацию 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ообщить модератору

	136. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+2 +/–
	Сообщение от Дон Ягон (ok), 16-Окт-20, 19:38
	Я уже не вижу смысла спрашивать, способен ли ты прочитать и осознать то, что я тебе пишу и на что ссылаюь, очевидно, что нет. Но понимаешь ли ты, что то, что ты сейчас написал и скинул всё также ни к селу ни к городу? Что ты там к чему относишь - вообще абсолютно безразлично. По _определению_ DAC - это модель безопасности, когда условный пользователь _сам_ определяет доступ для других условных пользователей права доступа для принадлежащих ему объектов. Например: доступ к файлам пользователя в unix'ах или доступ к фоткам/записям/etc пользователя в соцсетях - и там и там пользователь _сам_ определяет, у кого есть права, у кого нет. И какие права. Возвращаясь к _принудительному_ W^X - в каком месте тут DAC? Ты когда-то прочитал клёвую аббревиатуру и теперь таким образом хочешь показать, что ты прошаренный? Получается пока, увы, иначе.
	Ответить | Правка | Наверх | Cообщить модератору

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

	135. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
	Сообщение от Аноним (134), 16-Окт-20, 19:23
	Реализация DAC связана и с файлами ис памятью: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... Мы говорим о разной реализации DAC в разных OS. Где то она полная, где то ограничения.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

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

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

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

10. Скрыто модератором	+4 +/–
Сообщение от Аноним (46), 14-Окт-20, 12:35
> Удалённая уязимость в ядре NetBSD, эксплуатируемая из локальной сети Но как же так? Её же делают профессиональные порфессионалы, а не какие-то лaпчaтые выскачки!
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

	32. Скрыто модератором	+/–
	Сообщение от A.Stahl (ok), 14-Окт-20, 13:31
	Да, я начинаю счёт с правой руки.
	Ответить | Правка | Наверх | Cообщить модератору

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

	24. Скрыто модератором	+1 +/–
	Сообщение от Анонас (?), 14-Окт-20, 13:03
	Да ну, какие они профессионалы? Уязвимостей всего в 15 раз меньше, чем в Линуксе. https://www.cvedetails.com/product/84/Netbsd-Netbsd.html?ven... https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

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

17. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+1 +/–
Сообщение от Дон Ягон (ok), 14-Окт-20, 12:52
Звучит эпично, но по факту - так себе. Ну в смысле что локальная сеть + usb-свистки - не слишком высокий шанс на реальную эксплуатацию. А вот объединение с новостью про винду позабавило.
Ответить | Правка | Наверх | Cообщить модератору

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

	63. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (62), 14-Окт-20, 20:07
	> локальная сеть + usb-свистки raspberry pi
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

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

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

	74. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Дон Ягон (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ообщить модератору

	75. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Дон Ягон (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ообщить модератору

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

	38. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–3 +/–
	Сообщение от Аноним (-), 14-Окт-20, 13:59
	> Кто-то может сказать, это действительно драйвера оказались уязвимы, или это Васян-драйвер включили в ядро и поэтому теперь это называют уязвимостью БСД а > не уязвимостью Васян-драйвера? Да все просто! 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 - значит уязвимость в БСД, ведь там одни неосиляторы и неудачники (мы все так говорим, а значит это правда!) А вот если бы драйвер был для Пингвинчика, то пришлось бы разбираться, почему очередной Васян налажал!
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

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

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

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

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

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

	60. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Онаним (?), 14-Окт-20, 19:27
	Параметр - ipv6.disable=1 sysctl - net.ipv6.conf.all.disable_ipv6=1 , net.ipv6.conf.default.disable_ipv6=1
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	61. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Онаним (?), 14-Окт-20, 19:31
	У нас немножко другой коленкор, у нас инфраструктурные системы кастомизированы, и по умолчанию интегрирован systemd-networkd, там две строчки в .conf-файле на интерфейсах. LinkLocalAddressing=no IPv6AcceptRA=no Первое заодно фигачит 169.254.x.x, который в других случаях надо через /etc/sysconfig/network параметро NOZEROCONF=yes выключать.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

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

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

	102. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от 1 (??), 15-Окт-20, 11:29
	Мда ... люди теряют навыки чтения (или понимания того, что написано). Сходи в словарь и найди различия между словами "устанавливается" и "работает"
	Ответить | Правка | Наверх | Cообщить модератору

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

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

49. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
Сообщение от Аноним (49), 14-Окт-20, 16:39
>Уязвимость проявляется начиная с обновления 1709 для Windows 10 "СЕМЁРКА НЕБЕЗОПАСНА, ПЕРЕХОДИТЕ НА 10КУ!" - говорили некоторые.
Ответить | Правка | Наверх | Cообщить модератору

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

	52. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (52), 14-Окт-20, 17:30
	Микромягкие прогнулись и продлили до 2023 года поддержку семерки. Так что можешь откатиться)
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	77. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от СеменСеменыч777 (?), 15-Окт-20, 02:53
	ни одного (неофициального) аудита кода ХР еще не было.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
	Сообщение от VINRARUS (ok), 15-Окт-20, 06:47
	> ни одного (неофициального) аудита кода ХР еще не было. Ну код приоткрыли же :D
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	142. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от СеменСеменыч777 (?), 17-Окт-20, 14:59
	> Путин пользуется икспи это были понты. обои дефолтные => система свежепоставленая => никто ей не пользовался. думю что "Путин" использует секретарей-референтов.
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

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

	146. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от СеменСеменыч777 (?), 17-Окт-20, 17:28
	> Полагаешь, он как и прошлый президент, эплофанбой? полагаю, что ему доводят обстановку вслух специально обученные люди.
	Ответить | Правка | Наверх | Cообщить модератору

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

	147. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от СеменСеменыч777 (?), 17-Окт-20, 17:32
	> Ну а дефолтные обои и не засранный рабочий стол это нормально, 1) на дефолтных обоях плохо видны ссылки. 2) если в винде активно работать с документами, то р.стол неизбежно загаживается часто используемыми документами и ссылками для быстрого доступа.
	Ответить | Правка | Наверх | Cообщить модератору

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

	151. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от СеменСеменыч777 (?), 18-Окт-20, 12:24
	> каталог с файлами быстрого доступа и панель со ссылками это одно лишнее движение мышью + один лишний клик.
	Ответить | Правка | Наверх | Cообщить модератору

	152. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (21), 18-Окт-20, 12:51
	>> каталог с файлами быстрого доступа и панель со ссылками > это одно лишнее движение мышью + один лишний клик. Только на рабочем столе мало места и с сортировкой и поиском проблемы. Как и с менеджментом. https://www.youtube.com/watch?v=eEdiC-W4L7c
	Ответить | Правка | Наверх | Cообщить модератору

58. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
Сообщение от Аноним (58), 14-Окт-20, 18:52
а вот переписали бы на Rust и таких проблем не было бы
Ответить | Правка | Наверх | Cообщить модератору

	64. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+2 +/–
	Сообщение от Аноним (62), 14-Окт-20, 20:11
	На lua.
	Ответить | Правка | Наверх | Cообщить модератору

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

	91. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (89), 15-Окт-20, 08:41
	Смотри A2, blue botle - не на C, без проблем и безопасно. И с безопасностью C нет никаких проблем: https://www.opennet.dev/openforum/vsluhforumID3/122116.html#90 Проблему с C некоторые пытаются создать в ваших головах. И да эта проблема имеет место только в плохих ядрах OS и плохих компилятора, линковщиках.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

90. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+3 +/–
Сообщение от Аноним (89), 15-Окт-20, 08:34
> В NetBSD устранена уязвимость, вызванная отсутствием проверки границ буфера при обработке Любые эксплоиты использующие переполнение буфера в ядре ОС NetBSD или программах исполняющихся на ядре NetBSD работать не будут. Данной уязвимости НЕСУЩЕСТВУЕТ! Возможен максимум DoS или падение ядра NetBSD, в зависимости от политики реализации защиты от переполнения буфера при отсутствии проверки границ буфера в ядре NetBSD.
Ответить | Правка | Наверх | Cообщить модератору

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

	112. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (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ообщить модератору

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

	115. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
	Сообщение от Аноним (113), 16-Окт-20, 09:54
	Строгая это строгая без копромисов. Когда разработчики ядра строго и без копромисов отказывают всем в поддержке JIT-подобным технологиям. Дырявая это когда разрабы ядра прогнулись, пошли на компромисс и оставили возможности запуска JIT-приложений и работы JIT-компиляторов.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "OpenBSD с JIT и дырой в W^X."	+/–
	Сообщение от Аноним (113), 16-Окт-20, 10:00
	Тео Де Раадт прогнулся, стал раком перед JIT и отказался от строгой защиты памяти в OpenBSD: https://www.opennet.dev/opennews/art.shtml?num=50763 Теперь в OpenBSD есть возможность запуска ненужных JIT-приложений и большая дырень в W^X для реализации эксплоитов на базе переполнения буфера.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Дон Ягон (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 позволяет что-то гарантировать, а где нет, ага.
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	121. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (100), 16-Окт-20, 15:05
	>Очевидно, что remote root в netbsd/openbsd невозможен (из-за этих дыр) как раз из-за ядерного W^X. А если в Linux, то возможен?
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
	Сообщение от Дон Ягон (ok), 16-Окт-20, 15:15
	>>Очевидно, что remote root в netbsd/openbsd невозможен (из-за этих дыр) как раз из-за ядерного W^X. > А если в Linux, то возможен? Я не слишком хорошо знаком с актуальным состоянием ядра linux в этом месте, точно не знаю. Но, судя, например, по https://www.opennet.dev/opennews/art.shtml?num=53892 - remote root там таки возможен.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (125), 16-Окт-20, 18:03
	> linux ... remote root там таки возможен Только в дистрибутивах для быдла.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (100), 18-Окт-20, 22:29
	А какие не для быдла?
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (161), 19-Окт-20, 08:54
	Ссылку на пример дал: https://www.opennet.dev/openforum/vsluhforumID3/122116.html#112 Проверить любой *NIX, для быдла он или для людей можно двумя командами: 1. paxtest blackhat 2. checksec --file=/bin/ls
	Ответить | Правка | Наверх | Cообщить модератору

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

	160. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (160), 19-Окт-20, 08:19
	Все зависит от дистрибутива Linux.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (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) невозможна.
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

	128. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
	Сообщение от Аноним (125), 16-Окт-20, 18:01
	> в 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
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

	130. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
	Сообщение от Дон Ягон (ok), 16-Окт-20, 18:25
	> Тео отдал программисту право изменят исполняемый код программы. Не Тео, а стандарты 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ообщить модератору

	133. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
	Сообщение от Аноним (125), 16-Окт-20, 19:01
	> стандарты 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ообщить модератору

	137. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Дон Ягон (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ообщить модератору

	155. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+1 +/–
	Сообщение от Аноним (155), 18-Окт-20, 14:43
	> Сорян, я предпочту поверить примерам netbsd'шников, а не твоим ничем не обоснованным заявлениям. Да, java в W^X работать не будет. Собираю все без java, jit, orc, ... Надо все пероги пересобирать с правильными опциями компиляции и линковки чтобы они работали с PaX корректно. Неверно собираются единицы, в них надо править код, или использовать нормально написанный аналог. Gdb в рабочей системе никто не держит - уязвимость. >Возможно, в мобильной версии. В десктопной - нет. В новых версиях Mac OSX могли W^X добавить программный для Ынтель процов. > вот возможность делать переключения RW -> RX Это неприемлемо в плане безопасности. PaX вполне корректно убивает такой процесс. Исправлять надо именно firefox!
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	117. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+1 +/–
	Сообщение от Аноним (117), 16-Окт-20, 12:24
	> Данной уязвимости НЕСУЩЕСТВУЕТ! Значит NetBSD обновлять не надо!!! А то и к ней уже добрались и под видом исправления через обновление Троян забросят...
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

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

	126. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	–1 +/–
	Сообщение от Аноним (125), 16-Окт-20, 17:13
	> ядро упасть может У меня нормальные сетевухи, а не usb. Мне и думаю остальным обновлялся не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+/–
	Сообщение от Аноним (100), 18-Окт-20, 11:54
	Почему тогда есть пакет с jit? https://pkgsrc.se/lang/LuaJIT2
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

	153. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+1 +/–
	Сообщение от Аноним (155), 18-Окт-20, 14:26
	При включенной строгой W^X любые потом с JIT работать не будут. Но для быыыдла, можно перегрузится в режиме с отключеной защитой или отключить защиту для отдел ной потом как в PaX. Я считаю что проблема безопасности в толерантности, нада жостко, сразу послать всех с JIT на убунту или винду. А то эти сволочи сначала JIT в *опу засунут, с потом и systemd, dbus, polkitd...
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	159. "Удалённая уязимость в ядре NetBSD, эксплуатируемая из локаль..."	+1 +/–
	Сообщение от Аноним (160), 19-Окт-20, 08:14
	Не смотрел. Но должно быть да. Иначе тогда какой в ней смысл? Здесь лучше ставить два вопроса: 1. Включена ли защита в OS по умолчанию? 2. Есть ли гарантия невозможности отключения защиты в рабочей системе? От защиты которую можно отключить одной командой толку мало.
	Ответить | Правка | Наверх | Cообщить модератору

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

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