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

Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD, opennews (??), 16-Фев-20, (0) [смотреть все] Но как же хвалёное внимание BSD-шников к безопасности , Аноним (1), 08:44 , 16-Фев-20, (1) +4 // непрерывный аудит и находит такие ошибки, б.б. (?), 08:50 , 16-Фев-20, (2) +3 // Да, тут было бы интересно узнать, какое время эта уязвимость просидела незамечен, Андрей (??), 18:26 , 16-Фев-20, (32) –2 // судя по тому, что патч вышел для 6 6, но не вышел, как обычно, для 6 5, значит у, б.б. (?), 07:15 , 17-Фев-20, (49) Но тогда получается что линуксоиды со своим syzkaller ом и сотнями тестов, аудит, Аноним (-), 20:30 , 16-Фев-20, (38) // Отдельные линуксоиды опеннета, по понтам -- так уж точно , Аноним (-), 22:52 , 16-Фев-20, (43) +1 У кого ж они этому научились Вроде, говорят что BSD до Linux появились , Аноним (-), 23:12 , 16-Фев-20, (44) И часовню - тоже они , Аноним (-), 00:37 , 17-Фев-20, (46) BSDшники написали Unix, да , Аноним (51), 11:48 , 17-Фев-20, (51) Скрыто модератором, Аноним (-), 15:11 , 17-Фев-20, (56) Авотфиг Вон там Euler Linux таки сертифицЫровли как UNIX facepalm А бздов в, Аноним (-), 22:43 , 20-Фев-20, (92) Да , Аноним (60), 17:22 , 17-Фев-20, (60) syzkaller ом и сотнями тестов, аудитов и фуззинга не гарантируют нахождение ошиб, Аноним (61), 17:47 , 17-Фев-20, (61) Стопроцентные гарантии в этом мире даже страховой полис, увы, не дает Работает , Аноним (-), 21:13 , 17-Фев-20, (65) Так вот же оно - были столь внимательны, что обнаружили очередную уязвимость , Валик (?), 08:52 , 16-Фев-20, (3) +2 BSD большой и все 1782 4 BSDшника не смогут выловить все баги до очередного рел, A.Stahl (ok), 08:54 , 16-Фев-20, (4) // По-моему, ваша оценка числа разработчиков опёнка сильно завышена На пару порядк, Аноним (51), 11:50 , 17-Фев-20, (52) Активных разработчиков OpenBSD одномоментно порядка 70, всего 8212 несколько , Аноним (67), 21:35 , 17-Фев-20, (67) Тео изначально сказал что защита памяти в опенке будет не строгая, а со щелями , Аноним (6), 08:58 , 16-Фев-20, (6) // А есть пруфы , Аноним (22), 13:23 , 16-Фев-20, (22) +1 // Были, надо искать, даже здесь писали Смотри планы по защите памяти в опенке, осо, Аноним (68), 08:49 , 18-Фев-20, (68) paxtest запусти , Аноним (68), 09:54 , 18-Фев-20, (74) https security stackexchange com questions 139238 why-does-paxtest-show-openbs, Аноним (68), 09:58 , 18-Фев-20, (75) Так говорил Заратустра , xm (ok), 16:19 , 16-Фев-20, (25) Сейчас тебе расскажут, что поэтому и находят уязвимости, что внимательно следят, llol (?), 11:59 , 16-Фев-20, (20) –2 // Дегенераты из линуксового мира до сих пор не могут понять что основные BSD это , xm (ok), 16:21 , 16-Фев-20, (26) // Знаете, я не специалист по таким состояниям, но Вашу мысль можно было переформул, Michael Shigorin (ok), 18:18 , 16-Фев-20, (30) –5 Жителю Санкт-Петербурга простительно не понимать тонкой разницы между чеченцем и, Аноним (51), 11:51 , 17-Фев-20, (53) Жителям Санкт-Петербурга прежде чем искать всякого рода тонкие разницы недур, xm (ok), 13:07 , 17-Фев-20, (54) Да вот знаете, если так посмотреть кто в парадных ссыт, у них почему-то обычно ч, Аноним (-), 15:23 , 17-Фев-20, (57) Во-первых, не BSD-шников , а опёнковцев Во-вторых, на всякого Акелу в сходяще, Michael Shigorin (ok), 18:13 , 16-Фев-20, (29) –1 // При том если Акелла вдруг удумает лечить что, например, виртуализация не нужна -, Аноним (39), 20:34 , 16-Фев-20, (39) –1 // Потому что аноним, как обычно, слышал звон И ЧСЗ, самозабвенно повторяет его уж, Аноним (45), 23:14 , 16-Фев-20, (45) +1 Во первых, я видел виртуализаторы самого разного пошиба в продакшнах и тестлабах, Аноним (-), 04:50 , 17-Фев-20, (48) –2 Разве что в параллельной вселенной Ну или все эти ваши жирные корпорации с мир, Аноним (-), 14:45 , 17-Фев-20, (55) Это годные сельпо, оно завалили глобус продукцией С хорошей вероятностью вы их , Аноним (-), 16:51 , 17-Фев-20, (58) Вряд ли Два комментария с морем пафоса, воды, повторов одно и того же на разные , анонн (ok), 18:40 , 17-Фев-20, (63) Мегакорпорации штука забавная - ухитряются пролезть в самые неожиданные области , Аноним (-), 21:34 , 17-Фев-20, (66) В OpenBSD защита памяти сделана хуже чем в Linux PAX GrSecurity https pax , Аноним (6), 08:56 , 16-Фев-20, (5) // В дополнение к защите памяти с помощью классических R, W, X, UNIX должен защищат, Аноним (6), 09:13 , 16-Фев-20, (8) +1 // мы выслушали очередную рекламу Grsec не осилившего прочитать штатные средства за, Аноним (13), 09:24 , 16-Фев-20, (13) +6 // После Grsecurity, Аноним (61), 17:50 , 17-Фев-20, (62) да да, вот шнурки отглажу тогда уж grsec спер из Virtuozzo Linux-VServer, Аноним (64), 20:51 , 17-Фев-20, (64) мы выслушали очередную рекламу grsec Как там в у вас с нарушениями GPL , Аноним (13), 09:22 , 16-Фев-20, (11) +2 // https www opennet ru openforum vsluhforumID3 119728 html 31https www opennet, Аноним (6), 09:32 , 16-Фев-20, (14) +1 The restrictions prevent - creating executable anonymous mappings - creatin, Аноним (6), 09:22 , 16-Фев-20, (12) Конечно же, вы правы Только хотелось бы уточнить, почему пользователей дистрибу, Аноним (67), 11:06 , 16-Фев-20, (18) // Хорош вопрос Вернемся к истокам и вспомним историю первого безопасного дистрибут, Аноним (19), 11:57 , 16-Фев-20, (19) // Это был линукс , Consta (?), 12:50 , 16-Фев-20, (21) +1 Да, GNU Linux, но с расширенными возможностями ядра, компилятора, глибс и бинути, Аноним (68), 09:00 , 18-Фев-20, (69) Это не спасает Дело не только в формальной матмодели как таковой как в совокуп, Consta (?), 17:41 , 18-Фев-20, (80) Много писать не хочется, буду краток 1 Если идти путем разработки микроядра с т, Аноним (83), 16:58 , 19-Фев-20, (83) Зачем Там свое Кроме того, я не предлагал такое Смысл моего прсыла был в том,, Consta (?), 13:47 , 20-Фев-20, (89) Доказано что любая реализация DAC и MAC в микроядерных OS будет работать более ч, Аноним (101), 11:48 , 22-Фев-20, (101) –1 Где можно ознакомиться с соответствующими доказательствами Может, хоть у меня п, Consta (?), 15:06 , 22-Фев-20, (102) Мы когда-то посовещались и Я так решил https www opennet ru openforum vsluhfor, Аноним (114), 16:43 , 26-Фев-20, (114) - Вы не хотите настроить простую DAC, спорите о том, что можно выделять память о, Аноним (114), 17:25 , 26-Фев-20, (117) Правильно понимаю, что предлагается в качестве доказательств рассматривать ссылк, Consta (?), 15:24 , 02-Мрт-20, (130) Там вполне достаточно чтобы сложить 2 2 Дополнения для безопасности Писал уже, c, Аноним (135), 16:24 , 04-Мрт-20, (135) Да я и не сомневался, что сразу все ясно Решение, безусловно, новаторское Снач, Consta (?), 11:12 , 06-Мрт-20, (146) Нет времени спорить и что то доказывать Это сложные вещи Кратко Сетевой экран, , Аноним (147), 12:40 , 07-Мрт-20, (147) Теперь это Астра , pin (??), 13:42 , 16-Фев-20, (23) Если вдруг Вы угадали -- то было бы особенно пикантно, потому как несколько лет , Michael Shigorin (ok), 18:27 , 16-Фев-20, (33) Нет не Астра , Аноним (68), 09:01 , 18-Фев-20, (70) Спектре матмодель учитывала , cutlass (?), 14:59 , 16-Фев-20, (24) +3 Это было 10 лет назад , Аноним (68), 09:02 , 18-Фев-20, (71) На ентерпрайз-дистрибутивах можно неплохо попилить, а на твоей разработке как , Аноним (27), 16:23 , 16-Фев-20, (27) +2 Во-первых, если он и претендовал на первый безопасный , это была ложь Во-вторых, Michael Shigorin (ok), 18:24 , 16-Фев-20, (31) Всё уже придумано полвека назад, но только не бздунами под дырявую платформу htt, tensor (?), 19:57 , 16-Фев-20, (36) Да, в донкихотство теперь не верит даже Газпром, им видимо донесли что бюджет вс, Аноним (-), 17:00 , 17-Фев-20, (59) +1 Речь шла об ОС общего назначения , Аноним (68), 09:10 , 18-Фев-20, (72) В ос общего назначения крапа слишком уж много, все предусмотреть имхо малореальн, Аноним (81), 01:00 , 19-Фев-20, (81) +1 Она, главным образом, сделана по другому И OpenBSD, в отличие от NetBSD и Harde, Дон Ягон (ok), 20:18 , 16-Фев-20, (37) +3 // Спасибо за расширенный ответ Неизыблемое правило DAC - все исполняемое не должно, Аноним (68), 09:50 , 18-Фев-20, (73) –2   // Это которая с питоном и шеллскриптами, умеющими в eval и чьи интерпрета, анонн (ok), 13:27 , 18-Фев-20, (77) +2   Интерпретаторы, с питоном включительно, можно обрезать простым DAC Обычному пол, Аноним (83), 17:24 , 19-Фев-20, (84)   Угу, обрежь пакетный менеджер простым DAC И чего он сможет потом А ежели это, Аноним (-), 22:54 , 20-Фев-20, (93) +1   Именно так и надо делать Пакетным менеджером должен рулить отдельный пользовате, Аноним (101), 09:07 , 22-Фев-20, (98)   А как насчет простого тезиса Подлом этого юзера почти эквивалентен подлому рута, Аноним (-), 21:11 , 01-Мрт-20, (127)   О, а попробуйте так сделать вот прям сейчас на localhost Разумеется, используемо, Michael Shigorin (ok), 16:18 , 22-Фев-20, (103)   У меня именно так все и настроено Пользователям права на их shell даю На остал, Аноним (114), 16:48 , 26-Фев-20, (115)   Это общеиспользуемые стандарты, других нет Реальность, увы, иная JIT используе, Дон Ягон (ok), 14:31 , 18-Фев-20, (78) +1   del, Дон Ягон (ok), 14:50 , 18-Фев-20, (79)   Желаю все оптимизировать во время компиляции под свой проц, а во время исполнени, Аноним (83), 17:54 , 19-Фев-20, (85)   Это желания и только Реальность есть реальность Некоторые подвижки есть, но и , Дон Ягон (ok), 07:48 , 20-Фев-20, (87)   У меня source based дистрибутив вопрошающий мои желания в реальность И по этому , Аноним (101), 10:45 , 22-Фев-20, (99)   Нет, это не так Было бы хорошо, если бы это было так, но это не так и игнориров, Дон Ягон (ok), 06:31 , 23-Фев-20, (105)   Потому что никто не хочет лепить свои костыли вместо стандартных возможностей ff, Аноним (114), 17:09 , 26-Фев-20, (116)   Пример, который я описывал был не про обход W X pt 2 pax mprotect , а про обход, Дон Ягон (ok), 23:29 , 26-Фев-20, (118)   Рандомизацтя адресного пространства сильно затрудняет поиск нужного кода Ты не с, Аноним (119), 16:01 , 27-Фев-20, (119)   Я про это, да Я не про это Божечки, да причём тут это Когда-то у меня был арч с , Дон Ягон (ok), 16:11 , 27-Фев-20, (120)   Мое мнение, контроль за памятью должен быть только у ядра Изменение исполняемых, Аноним (121), 15:44 , 28-Фев-20, (121)   Ради бога Почему я считаю, что такой максималистский подход малоприменим для вс, Дон Ягон (ok), 15:49 , 28-Фев-20, (122)   Надеюсь, что всем уже стало понятно необходимость, ядром OS или аппаратно процес, Аноним (123), 09:07 , 29-Фев-20, (123)   Я прочитал сейчас что-то, по меньшей мере, очень странное И в случае pledge, и в, Дон Ягон (ok), 05:07 , 01-Мрт-20, (124)   Нет, в OpenBSD ядро не дает никаких гарантий, оставляя возможность приложениям и, Аноним (126), 15:26 , 01-Мрт-20, (126)   Прости, но ты пишешь ахинею Pledge - это системный вызов, как следствие, вся ра, Дон Ягон (ok), 00:44 , 02-Мрт-20, (129)   Плохо то, что есть в ядре OpenBSD возможность дать программ право изменять испол, Аноним (131), 15:51 , 02-Мрт-20, (131)   Нет, это не плохо, это адекватно требованиям, выдвигаемым к ОС общего назначения, Дон Ягон (ok), 16:10 , 02-Мрт-20, (132)   Нет сегодня возможности проверить логику работы всех программ А безопасность им, Аноним (133), 15:55 , 03-Мрт-20, (133)   Ну, я к тому, что можно и заканчивать Кажется, друг друга мы поняли, друг с дру, Дон Ягон (ok), 16:05 , 03-Мрт-20, (134)   Вы не сказали самый главный аргумент против использования W X А его надо понима, Аноним (135), 16:38 , 04-Мрт-20, (136)   ИМХО, это всё совсем не про ОС общего назначения И даже не только лишь по требо, Дон Ягон (ok), 16:41 , 04-Мрт-20, (137)   Про OS общего назначения это Реализация PaX в GNU Linux очень правильная и преду, Аноним (135), 16:48 , 04-Мрт-20, (138)   Я понял На эту тему все мысли, которые у меня были я уже написал, больше не х, Дон Ягон (ok), 17:20 , 04-Мрт-20, (139)   Классика жанра В спец ПО для райнимации больного допустили ошибку переполнения б, Аноним (140), 17:41 , 04-Мрт-20, (140)   Логика рассуждения мне понятна, спасибо Мне не понятно, почему бы не резервиров, Дон Ягон (ok), 17:58 , 04-Мрт-20, (141)   А кто даст гарантию что не упадет процесс отвечающий за переключения или вообще , Аноним (144), 16:31 , 05-Мрт-20, (144)   Всё зависит от того, как именно всё реализовано Мы этих моментов не уточнили - , Дон Ягон (ok), 17:06 , 05-Мрт-20, (145) +1   Например, переключатель может быть вообще исполнен в железе Есть общая теория пр, Аноним (148), 14:28 , 07-Мрт-20, (148)   А кто за лоббирование бесполезной для жизни и очень вредной для безопасности, те, Аноним (68), 10:02 , 18-Фев-20, (76) Типичная апологетика и двойные стандарты Зато соответствует модели угроз с учёто, недобрый (?), 07:49 , 19-Фев-20, (82) // При чём тут мои критерии Приложения хромиум, java перестанут работать Лично , Дон Ягон (ok), 07:27 , 20-Фев-20, (86) Что ты тут ёрничаешь Перестанут работать, только если не будет способа снять дл, недобрый (?), 12:06 , 20-Фев-20, (88) Ну то есть ещё раз если для некоторых приложений не ОТКЛЮЧИТЬ pax-защиты, они р, Дон Ягон (ok), 17:55 , 20-Фев-20, (90) А если отключить - будут Ещё раз это whitelisting, лучшая практика по индустри, недобрый (?), 22:33 , 20-Фев-20, (91) Вместо решения конкретных проблем - мантры о стандартах индустрии В случае проб, Дон Ягон (ok), 06:34 , 21-Фев-20, (94) ничего себе тут войну и мир пишут можно уже на бумаге издавать, б.б. (?), 08:04 , 21-Фев-20, (95) Это ты сейчас свои отсылки к стандартам хорошо охарактеризовал Да мне всё равно,, недобрый (?), 12:48 , 21-Фев-20, (96) Это твои домыслы В первом комментарии речь шла не про paxd и прочие костыли, чт, Дон Ягон (ok), 06:22 , 22-Фев-20, (97) Ты не читатель ты, судя по этому посту писатель https www opennet ru openf, Аноним (101), 10:59 , 22-Фев-20, (100) Не домыслы, а хорошо обоснованные выводы Уродство - слово литературное Потом ты, недобрый (?), 20:11 , 24-Фев-20, (106) Извини, но далее я буду стараться отвечать только на то, на что есть смысл отвеч, Дон Ягон (ok), 03:29 , 25-Фев-20, (109) Очевидно, что не безразлично Но мне удобнее, чтобы ты не слился, а наоборот про, недобрый (?), 10:47 , 26-Фев-20, (110) Ты можешь быть уверен в чём угодно - я не против Во всех ОС общего назначения по, Дон Ягон (ok), 15:54 , 26-Фев-20, (112) Это ты на словах не против А на деле две недели упражняешься в зарабатывании пр, недобрый (?), 20:42 , 04-Мрт-20, (142) Рассуждать отказался Ну, кто бы сомневался И это твоё замечание могло бы иметь , недобрый (?), 20:44 , 04-Мрт-20, (143) Вопрос выбора абстракций определений Как по мне, меры защиты должны быть реакцие, Дон Ягон (ok), 15:58 , 26-Фев-20, (113) Сразу - это прям сразу Значит, у тебя в голове вместо целостной картины не один, недобрый (?), 10:50 , 26-Фев-20, (111) А где я утверждал, что делали неосознанно и что чинить надо В OpenBSD пусть хот, недобрый (?), 20:13 , 24-Фев-20, (107) Это где _пакетный менеджер_ ругается на битые чексуммы у _пакета_ Если пакетный , недобрый (?), 20:17 , 24-Фев-20, (108) Скрыто модератором, Аноним (9), 09:15 , 16-Фев-20, (9) –13 // Скрыто модератором, neAnonim (?), 09:53 , 16-Фев-20, (15) +5 Скрыто модератором, Ананимус (?), 10:14 , 16-Фев-20, (16) +5 Скрыто модератором, Аноним (17), 10:52 , 16-Фев-20, (17) +2 Скрыто модератором, pda (?), 18:09 , 16-Фев-20, (28) +1 Скрыто модератором, Michael Shigorin (ok), 18:30 , 16-Фев-20, (34) // Скрыто модератором, Аноним (39), 20:37 , 16-Фев-20, (40) // Скрыто модератором, Michael Shigorin (ok), 21:10 , 16-Фев-20, (41) Скрыто модератором, Аноним (-), 21:20 , 16-Фев-20, (42) –1 А ещё лет 10 назад на опеннете Да кому ты нужен, зачем фаервол настраивать, заче, Аноним (35), 18:37 , 16-Фев-20, (35) // 10 лет назад ещё не изобрели китайцев Некомпетентные люди существуют во все вре, Аноним (47), 03:45 , 17-Фев-20, (47) Если помечено уже read-only кем-то третьим, то зачем же второй раз уже самому за, Аноним (50), 08:08 , 17-Фев-20, (50) https marc info l openbsd-tech m 158237030723610 w 2Трололо, там с первого ра, Дон Ягон (ok), 22:33 , 22-Фев-20, (104) // https www opennet ru opennews art shtml num 52418, Аноним (126), 14:30 , 01-Мрт-20, (125) // Спасибо, видел Мой комментарий был раньше, когда я ещё не знал, что Максим план, Дон Ягон (ok), 23:16 , 01-Мрт-20, (128) 1,5,35,50,104

Сообщения

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

	73. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	–2 +/–
	Сообщение от Аноним (68), 18-Фев-20, 09:50
	> ... OpenBSD только "W^X part one". ... Спасибо за расширенный ответ. Неизыблемое правило DAC - все исполняемое не должно изменятся, а изменяемое НИКОГДА не должно исполнятся. Подсистема гарантирующая целостность ОС должна следить за неизменностью, как запускаемого кода с диска, так и исполняемого в оперативной памяти - незыблемое правило Integrity. Стандарты, инструкции, которые противоречат этим правилам печатаете на мягкой бумаге и храните в туалете, может кому пригодятся. JIT - в принципе не нужен. Вся оптимизация двоичного кода должна проводится в момент компиляции. Мне, пользователю Gentoo, использования JIT не даст глобалальный прирост производительности, а безопасность уменьшит точно. JIT - отрава безопасности UNIX, которую специально внедряют, и подгоняют под ее использование стандарты. Тео зря пошел на компромисс с пропогандистами JIT разрешив ранее выделенные, для изменения, страницы памяти переводить в режим исполнения. Пользователи JIT розменивают свою безопасность на мнимую производительность. Надо производительность - пересобери все с оптимизацией под свой процессор. Безопасность ОС, особенно фундаментальная: DAC, MAC, Integrity, ... должна быть гарантирована! Гарантировать ее можно только на уровне аппаратном или ядра ОС. Если оставить дыры и переложить ответственность за безопасность на прикладной софт гарантии безопасности теряются. Дыры будут использованы вирями. А программисты прикладного софта не будут следить за безопасностью у них совсем другие интересы. > W^X (write xor execute) is the name of an implementation specifically in OpenBSD. One might therefor think that OpenBSD would meet this SFR, however it does not, as I will demonstrate below. https://blog.acumensecurity.net/2016/04/21/fpt_wx_ext-1-a-ru.../
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+2 +/–
	Сообщение от анонн (ok), 18-Фев-20, 13:27
	> Подсистема гарантирующая целостность ОС должна следить за неизменностью, как запускаемого кода с диска, так и исполняемого в оперативной памяти - незыблемое правило Integrity. ... >  Пользователи JIT розменивают свою безопасность на мнимую производительность. Надо производительность - пересобери все с оптимизацией под свой процессор. > Безопасность ОС, особенно фундаментальная: DAC, MAC, Integrity, ... должна быть гарантирована! Гарантировать ее ... > пошел на компромисс с пропогандистами JIT разрешив ранее выделенные, для изменения, ... > Мне, пользователю Gentoo, Это которая с питоном и шеллскриптами, умеющими в eval и чьи интерпретаторы плевать хотели на W^X, т.к. они сам себе "execution unit"? А так дышал, так дышал :(
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (83), 19-Фев-20, 17:24
	> Это которая с питоном и шеллскриптами, умеющими в eval и чьи интерпретаторы плевать хотели на W^X, т.к. они сам себе "execution unit"? Интерпретаторы, с питоном включительно, можно обрезать простым DAC. Обычному пользователю и большинству сервисов они не нужны. groupadd shells usermod -a -G shells portage usermod -a -G shells ... chown root:shells /usr/bin/python* /bin/bash ... chmod o-rwx /usr/bin/python* /bin/bash ... У сегодняшнего Gentoo есть недостатки, но решаемы.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+1 +/–
	Сообщение от Аноним (-), 20-Фев-20, 22:54
	> Интерпретаторы, с питоном включительно, можно обрезать простым DAC. Угу, обрежь "пакетный менеджер" простым DAC. И чего он сможет потом? А ежели этот кус крапа заведует софтом в системе - то наверное и поиметь сможет, все что захочет, если захочет, не? На уровне базового анализа взаимодействий компонентов сугубо. > groupadd shells > usermod -a -G shells portage > usermod -a -G shells ... > chown root:shells /usr/bin/python* /bin/bash ... > chmod o-rwx /usr/bin/python* /bin/bash ... Прикольные тантры, а смысл? Можно подумать, это блекхэтам как-то помешает. > У сегодняшнего Gentoo есть недостатки, но решаемы. ...особенно ежели заменой дистра на менее хаотичный.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (101), 22-Фев-20, 09:07
	> > Интерпретаторы, с питоном включительно, можно обрезать простым DAC. > Угу, обрежь "пакетный менеджер" простым DAC. И чего он сможет потом? А ежели этот кус крапа заведует софтом в системе - то наверное и поиметь сможет, все что захочет, если захочет, не? На уровне базового анализа взаимодействий компонентов сугубо. Именно так и надо делать! Пакетным менеджером должен рулить отдельный пользователь (запуск под root, установка под root, а вот загрузки и сборка в изолированном окружении под непривелег рованым пользователем), и только ему в случае Gentoo нужны права к инструментам разработчика. DAC именно для этого и нужен. > > groupadd shells > > usermod -a -G shells portage > > usermod -a -G shells ... > > chown root:shells /usr/bin/python* /bin/bash ... > > chmod o-rwx /usr/bin/python* /bin/bash ... > Прикольные тантры, а смысл? Можно подумать, это блекхэтам как-то помешает. Это не приколы, а разграничения доступа к интерпретаторам и средствам сборки на уровне DAC. В обычном Линукс дистре DAC используют для ограничения запуска программы с /usr/games только пользователи группы games могут запускать программы с этого каталога. Это азы уровня школы, исполнение которых значительно повысит безопасность системы. > > У сегодняшнего Gentoo есть недостатки, но решаемы. > ...особенно ежели заменой дистра на менее хаотичный. Речь идет о интерпретатора и их eval. Для portage есть и бинарные пакетным менеджеры. Система инициализации openrc-run бинарный интерпретатор, а вот netifrc пока проблемное расширение с ворохом eval скриптов.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (-), 01-Мрт-20, 21:11
	> Именно так и надо делать! Пакетным менеджером должен рулить отдельный пользователь (запуск > под root, установка под root, а вот загрузки и сборка в изолированном окружении под > непривелег рованым пользователем), и только ему в случае Gentoo нужны права к > инструментам разработчика. DAC именно для этого и нужен. А как насчет простого тезиса? Подлом этого юзера почти эквивалентен подлому рута, возможно даже более чем в 1 системе. Просто потому что тот юзер может произвольно патчить софт и конфигурацию оного, а потом все это от рута вкатится в систему - и, собственно, в этот момент атакующий сможет снять любые мыслимые сливки. Конечно, есть некая вероятность что между этими этапами спалите что собралось что-то не то, но если для майнтайнера собирающего в бинарном дистре пару пакетов и знающего там каждый байт как облупленый я еще могу допустить, то гентушник ворочающий сотнями мегазов всего и вся, имхо, в этом плане абсолютно без шансов. В итоге получается лишний management overhead с какими-то странными приседаниями, а профит, собственно, в чем? > Это не приколы, а разграничения доступа к интерпретаторам и средствам сборки на уровне DAC. Системная камасутра на мое нескромное мнение. > Это азы уровня школы, исполнение которых значительно повысит безопасность системы. Я не думаю что вы бы вообще что-нибудь поняли в моей инсталляции. Естественно не имеющей ничего общего с этими приседаниями, и не факт что менее секурной чем ваше добро. Я общие идеи содрал у мадам руткитской, а то что запилил малость по своему - так можно, и чего? :) > Речь идет о интерпретатора и их eval. Я рассматриваю это как большой и жирный класс неприятных вулнов. Его малореально заткнуть, а поскольку это в конечном итоге оказывает влияние на то что будет собрано из софта - да какая разница под каким юзером крутится? :) > Для portage есть и бинарные пакетным менеджеры. Система инициализации openrc-run > бинарный интерпретатор, а вот netifrc пока проблемное расширение с ворохом eval скриптов. Ну это в духе гентушников. Потом оказывается что в всех этих гомнопалках dhcp сервак рута получает, etc. Мегаскриптеры они такие.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Michael Shigorin (ok), 22-Фев-20, 16:18
	> Интерпретаторы, с питоном включительно, можно обрезать простым DAC. > Обычному пользователю и большинству сервисов они не нужны. О, а попробуйте так сделать вот прям сейчас на localhost. Разумеется, используемого пользователя вносить в shells незачем. PS: о том, что надо будет бегать и следить за правами по мере обновления бинарников (а также о гонке в процессе при такой наивной реализации) -- помолчу, но вообще-то у нас подобная задача решена.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

	115. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (114), 26-Фев-20, 16:48
	> О, а попробуйте так сделать вот прям сейчас на localhost. Разумеется, используемого пользователя вносить в shells незачем. У меня именно так все и настроено. Пользователям права на их shell даю. На остальные нет.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+1 +/–
	Сообщение от Дон Ягон (ok), 18-Фев-20, 14:31
	>> ... OpenBSD только "W^X part one". ... > Стандарты, инструкции, которые противоречат этим правилам печатаете на мягкой бумаге и храните в туалете, может кому пригодятся. Это общеиспользуемые стандарты, других нет. > JIT - в принципе не нужен. Вся оптимизация двоичного кода должна проводится в момент компиляции. Реальность, увы, иная. JIT используется много где, и понятно зачем. К слову, не каждая реализация JIT должна требовать W|X (примеры были тут - https://www.opennet.ru/opennews/art.shtml?num=50763). > JIT - отрава безопасности UNIX, которую специально внедряют, и подгоняют под ее использование стандарты. Ахинея. > Тео зря пошел на компромисс с пропогандистами JIT разрешив ранее выделенные, для изменения, страницы памяти переводить в режим исполнения. Пользователи JIT розменивают свою безопасность на мнимую производительность. Надо производительность - пересобери все с оптимизацией под свой процессор. Тео, в итоге, выбрал верное решение. Хотя какое-то время в OpenBSD было только W^X part one и не было pledge - да. Но от этого решение PAX team правильным не стало. Наиболее вероятный результат включения по умолчанию W^X part two для всех принудительно - отключение оного кустарными способами или смена ОС на ту, где такого нет. И это логично - программа сначала должна решать какую-то проблему, а потом уже быть безопасной. Программа, которая не решает никакой проблемы, но безопасна - бесполезна. Как и ОС, в которой ни ff ни chrome не запустить. > Безопасность ОС, особенно фундаментальная: DAC, MAC, Integrity, ... должна быть гарантирована! Гарантировать ее можно только на уровне аппаратном или ядра ОС. Ты, как разработчик или пользователь ПО можешь герентировать отсутствие W|X при помощи pledge. Убивать приложение при нарушении W^X будет именно ядро (хотя по дефолту оно кажется не убивает, а просто возвращает -1 malloc'ом). > Если оставить дыры и переложить ответственность за безопасность на прикладной софт гарантии безопасности теряются. Их (гарантий) нет и в PAX. Можно отключить защиту как глобально, так и per app. > А программисты прикладного софта не будут следить за безопасностью у них совсем другие интересы. Во-первых, при наличии удобного, ранее отсутствовавшего инструмента - почему нет? Во-вторых, ты можешь попатчить нужное сам, как это пока опенбсдшники и делают для ff, например. В третьих, если сами разработчики хорошо положат болт на безопасность своего ПО, никакое pledge или pax тебе не поможет.
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	79. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 18-Фев-20, 14:50
	del
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (83), 19-Фев-20, 17:54
	> Реальность, увы, иная. JIT используется много где, и понятно зачем. Желаю все оптимизировать во время компиляции под свой проц, а во время исполнения иметь гарантию неизменности кода. > К слову, не каждая реализация JIT должна требовать W|X Исполнение ранее измеряемого кода - неприемлемо. Как и изменение прав x -> w -> x > программа сначала должна решать какую-то проблему, а потом уже быть безопасной. Вот это аргумент! Или прога проектируется удовлетворять элементарным требованиям безопасности, или она не будет безопасна никогда. И мне такая прога не нужна. > Как и ОС, в которой ни ff ни chrome не запустить. Это не безопасные бровзеры, хотя поняв что их люди выкинули из-за JIT все дружно добавили опции 'configure --no-jit' > Ты, как разработчик или пользователь ПО можешь герентировать отсутствие W|X при помощи pledge. Убивать приложение при нарушении W^X будет именно ядро Мое ядро все что только попросит память в режимеиwx прибивает сразу. > Их (гарантий) нет и в PAX. Можно отключить защиту как глобально, так и per app. У тебя нет, а у меня есть, возможность глобально отключить PAX требует перезагрузки, но я эту опцию в настройках ядра не включил. По приложениям можно менять или заглавие ELF или xattr, но для этого надо root. А у меня / смонтирован ro и ядро недаст его перемонтировать rw, потому что мое ядро следит чтобы диски тоже в режиме rw,exec не монтировались. А кроме того есть IMA которая заблокирует изменения ELF и есть EVM которая заблокирует изменения IMA и xattr. У меня есть 100% гарантия. > Во-первых, при наличии удобного, ранее отсутствовавшего инструмента - почему нет? Во-вторых, ты можешь попатчить нужное сам, как это пока опенбсдшники и делают для ff, например. Давным давно я на это потратил пару лет, патчи слал разрабам, обяснял как надо писать код, многие исправились. > В третьих, если сами разработчики хорошо положат болт на безопасность своего ПО, никакое pledge или pax тебе не поможет. Ложим болт на их поделки. KDE со своими скриптами с JIT, ... во многих ынтерпрайз дистрах дефолтный DE?
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	87. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 20-Фев-20, 07:48
	>> Реальность, увы, иная. JIT используется много где, и понятно зачем. > Желаю все оптимизировать во время компиляции под свой проц, а во время исполнения иметь гарантию неизменности кода. Это желания и только. Реальность есть реальность. Некоторые подвижки есть, но и только. >> К слову, не каждая реализация JIT должна требовать W|X > Исполнение ранее измеряемого кода - неприемлемо. Как и изменение прав x -> w -> x Где так написано? А то программисты не знают и по другому программы пишут. И, цука, иногда нужные. Да, сделано из г-на, но какую-то нужную проблему решает. >> программа сначала должна решать какую-то проблему, а потом уже быть безопасной. > Вот это аргумент! Или прога проектируется удовлетворять элементарным требованиям безопасности, или она не будет безопасна никогда. И мне такая прога не нужна. Как вы каменты то на опеннете оставляете, если у вас ff и chrome не работают, стесняюсь спросить? >> Как и ОС, в которой ни ff ни chrome не запустить. > Это не безопасные бровзеры, хотя поняв что их люди выкинули из-за JIT все дружно добавили опции 'configure --no-jit' Окей, как вы каменты на опеннете  оставляли до того, как вышла версия хрома с nojit? >> Ты, как разработчик или пользователь ПО можешь герентировать отсутствие W|X при помощи pledge. Убивать приложение при нарушении W^X будет именно ядро > Мое ядро все что только попросит память в режимеиwx прибивает сразу. Выглядит так, как будто бы ты этим гордишься, хотя на самом деле, не стоило бы. В общем-то, сломать переключалку в mprotect не очень большая наука, студенты должны справиться. Понятно, что проще всего объявить неугодное бескомпромиссно непримелемым и чуть что раздавать kill -9. Это самое очевидное и топорное решение. Но смысл оно имеет только при условии, что есть доступная альтернатива тому ПО, которое не запустится. А это не так -> для включения по-умолчанию в ОС общего назначения это неприемлемо. >> Их (гарантий) нет и в PAX. Можно отключить защиту как глобально, так и per app. > У тебя нет, а у меня есть, возможность глобально отключить PAX требует перезагрузки, но я эту опцию в настройках ядра не включил. Бессмысленная софистика. Принципиальная возможность - есть. Это абсолютно всё, что нужно знать. А что там кто-то для себя наколхозил - не интересно. > По приложениям можно менять или заглавие ELF или xattr Не все хотят при каждом обновлении прописывать все флаги ручками, обычно это автоматизируется. Есть даже костыледемон paxd для этих целей. Т.е. можно ещё поколдовать со скриптами автоматизации или конфигами paxd. А не в лоб. > А у меня / смонтирован ro и ядро недаст его перемонтировать rw, потому что мое ядро следит чтобы диски тоже в режиме rw,exec не монтировались. А кроме того есть IMA которая заблокирует изменения ELF и есть EVM которая заблокирует изменения IMA и xattr. У меня есть 100% гарантия. Плохо, что ты думаешь, что у тебя 100% гарантия. Может это и так (я не знаю), но недоверие - это хорошо. >> Во-первых, при наличии удобного, ранее отсутствовавшего инструмента - почему нет? > Во-вторых, ты можешь попатчить нужное сам, как это пока опенбсдшники и делают для ff, например. Опенбсдшники не патчили ff на предмет неиспользования jit. Ну, я про такое не слышал. Pledge туда добавили, да, и unveil.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (101), 22-Фев-20, 10:45
	> > > Реальность, увы, иная. JIT используется много где, и понятно зачем. > > Желаю все оптимизировать во время компиляции под свой проц, а во время исполнения иметь гарантию неизменности кода. > Это желания и только. Реальность есть реальность У меня source based дистрибутив вопрошающий мои желания в реальность! > > > К слову, не каждая реализация JIT должна требовать W|X > > Исполнение ранее измеряемого кода - неприемлемо. Как и изменение прав x -> w -> x > Где так написано? А то программисты не знают и по другому программы пишут. И, цука, иногда нужные. Да, сделано из г-на, но какую-то нужную проблему решает. И по этому их программы люди не используют. Передай этим "программистам", что если использую JIT, то код должен ветвится на две ветки: без JIT и с JIT. Выбор используемой ветки должен проводится на этапе выполнения configure: параметрами --with-jit или --disable-jit. Все нормальные программисты уже так сделали, даже в Google со своим хромом. CONFIG_PAX_MPROTECT=y Enabling this option will prevent programs from - changing the executable status of memory pages that were not originally created as executable, - making read-only executable pages writable again, - creating executable pages from anonymous memory, - making read-only-after-relocations (RELRO) data pages writable again. https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri... https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri... https://grsecurity.net/PaX-presentation.pdf https://grsecurity.net/PaX-presentation.ppt http://mainisusuallyafunction.blogspot.com/2012/11/attacking... https://github.com/01org/jit-spray-poc-for-ksp http://www.matasano.com/research/Attacking_Clientside_JIT_Co... > Окей, как вы каменты на опеннете  оставляли до того, как вышла версия хрома с nojit? На целевой системе нет firefox и chrome. Кроме них есть куча бровзеров которые по умолчанию ответственно относятся к безопасности и приватности пользователей. Firefox JIT нужен только для поддержки расширений. Можно расширения устанавливать пакетным менеджером в систему и отключить их поддержку firefox. Это правильный и безопасный путь. Почему его не используют разработчики дистрибутивов? > > > Их (гарантий) нет и в PAX. Можно отключить защиту как глобально, так и per app. > > У тебя нет, а у меня есть, возможность глобально отключить PAX требует перезагрузки, но я эту опцию в настройках ядра не включил. > Бессмысленная софистика. Принципиальная возможность - есть. Это абсолютно всё, что нужно знать. > А что там кто-то для себя наколхозил - не интересно. В целевой системе, при правильной настройке (x86_64+NX процессору верим ;) ), PaX отключить принципиально, теоретически и практически невозможно: PAX=y PAX_SOFTMODE is not set PAX_EI_PAX is not set PAX_PT_PAX_FLAGS is not set PAX_XATTR_PAX_FLAGS is not set PAX_HAVE_ACL_FLAGS=y PAX_NOEXEC=y PAX_PAGEEXEC=y PAX_SEGMEXEC is not set PAX_EMUTRAMP is not set PAX_EMUSIGRT is not set PAX_MPROTECT=y PAX_MPROTECT_COMPAT is not set PAX_ELFRELOCS is not set PAX_ETEXECRELOCS is not set PAX_EMUPLT is not set PAX_DLRESOLVE is not set PAX_KERNEXEC=y PAX_ASLR=y PAX_RANDKSTACK=y PAX_RANDUSTACK=y PAX_RANDMMAP=y PAX_MEMORY_SANITIZE=y PAX_MEMORY_STACKLEAK=y PAX_MEMORY_STRUCTLEAK=y PAX_MEMORY_UDEREF is not set PAX_REFCOUNT=y PAX_CONSTIFY_PLUGIN=y PAX_USERCOPY=y PAX_SIZE_OVERFLOW=y PAX_LATENT_ENTROPY=y PAX_RAP=y > > По приложениям можно менять или заглавие ELF или xattr > Не все хотят при каждом обновлении прописывать все флаги ручками, обычно это автоматизируется. Есть даже костыледемон paxd для этих целей. Т.е. можно ещё поколдовать со скриптами автоматизации или конфигами paxd. А не в лоб. В моем дистрибутиве пакетный менеджер умеет, для кривого софта, выставлять нужные PAX флаги! Костыледемон paxd похерит Integrity. А при ro / и вовсе бесполезен. Лучше просто не использовать софт с JIT вовсе. > > А у меня / смонтирован ro и ядро недаст его перемонтировать rw, потому что мое ядро следит чтобы диски тоже в режиме rw,exec не монтировались. А кроме того есть IMA которая заблокирует изменения ELF и есть EVM которая заблокирует изменения IMA и xattr. У меня есть 100% гарантия. > Плохо, что ты думаешь, что у тебя 100% гарантия. Может это и так (я не знаю), но недоверие - это хорошо. Плохо ты думаешь, гарантия зависит от того кто гарантирует (настраивал). Данный алгоритм, при правильной настройке, даст 100℅ гарантию не низменности, по файловых, настроек PAX в целевой системе. > Опенбсдшники не патчили ff на предмет неиспользования jit. Ну, я про такое не слышал. Pledge туда добавили, да, и unveil. А надо было популярные расширения добавить в пакеты и отключить возможность загрузки расширений в ff! Тео, вместо этого, добавил ненужную дыру.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 23-Фев-20, 06:31
	> И по этому их программы люди не используют. Нет, это не так. Было бы хорошо, если бы это было так, но это не так и игнорировать это нельзя. > На целевой системе нет firefox и chrome. Кроме них есть куча бровзеров которые по умолчанию ответственно относятся к безопасности и приватности пользователей. Ясно-понятно. > Firefox JIT нужен только для поддержки расширений. Можно расширения устанавливать пакетным менеджером в систему и отключить их поддержку firefox. Это правильный и безопасный путь. Почему его не используют разработчики дистрибутивов? Потому что никто не хочет лепить свои костыли вместо стандартных возможностей ff во имя не пойми чего? > В моем дистрибутиве пакетный менеджер умеет, для кривого софта, выставлять нужные PAX флаги! Круто! Я тоже могу наколхозить кучу всего интересного (или не очень) и забавного. Кому какое дело до этого? Это очевидно нишевое решение. И не буду даже спрашивать откуда вы берёте pax-патчи, с тех пор как их закрыли вместе с grsecurity/. > Тео, вместо этого, добавил ненужную дыру. Я попробую ещё, но, пожалуй, последний раз в этой теме. Так вот. Какая проблема решается W^X pt 2, он же  PAX MPROTECT? Если даже у нас уже реализован и используется W^X pt 1, мы всё равно можем внедрить код, сделать ret2libc->ret2mprotect = сделать память исполянемой, выполнить код. Защита преодолена, W^X нарушен. PAX MPROTECT прибивает процесс, который вызывает mprotect, добавляющий PROT_EXEC, таким образом, решающий проблему (и ломающий некоторые "честные" приложения). В случае OpenBSD, реализован только W^X pt 1, prot_exec может быть только отозван через pledge, что требует модификации кода программы. Помимо этого, в любом случае возникнут сложности на этапе ret2libc, так как используется ASLR и при каждой новой загрузке ОС используется заново слинкованная libc с расположенными в случайном порядке объектами. Т.е. произвести атаку, конечно, всё-таки возможно, но это едва ли получится с первой попытки, да и в целом, будет несколько затруднено. OpenBSD хочет соблюдать стандарты, а не извращённо толковать иx (из "If an implementation cannot support the combination of access types specified by prot, the call to mprotect() shall fail." люди из pax делают вывод, что имеют право ломать mprotect, в дествительности написать имплементацию которая поддерживает кобминацию w и x вполне можно, так что...). Поэтому аналог PAX MPROTECT не может быть включен по умолчанию. Однако, так как хоть какие-то меры противодествия имеются, а ROP в более широком смысле, нежели описанный выше пример, всё равно может позволить обойти W^X pt 2, принятые по-умолчанию меры считаются примемлемыми. А при использовании pledge можно и поставить точку в вопросе с prot_exec, и подобная логика может быть добавлена в программы достаточно легко. Проще говоря, назвать это дырой сложно, эксплуатировать что-то в реальной жизни будет сложнее, чем  в теории. > PaX отключить принципиально, теоретически и практически невозможно С трудом представляю, как ты пользуешься такой системой, а главное - зачем. См. выше, почему я считаю, что ты страдаешь за почти что иллюзию защиты.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (114), 26-Фев-20, 17:09
	> > Firefox JIT нужен только для поддержки расширений. Можно расширения устанавливать пакетным менеджером в систему и отключить их поддержку firefox. Это правильный и безопасный путь. Почему его не используют разработчики дистрибутивов? Потому что никто не хочет лепить свои костыли вместо стандартных возможностей ff во имя не пойми чего? > Если даже у нас уже реализован и используется W^X pt 1, мы всё равно можем внедрить код, сделать ret2libc->ret2mprotect = сделать память исполянемой, выполнить код. Защита преодолена, W^X нарушен. PAX_ASLR=y PAX_RANDKSTACK=y PAX_RANDUSTACK=y PAX_RANDMMAP=y Замучаешся преодолевать, есть другие системы которые следят за брутефосом и принимают более радикальные проактивные меры. >PAX MPROTECT прибивает процесс, который вызывает mprotect, добавляющий PROT_EXEC, таким образом, решающий проблему (и ломающий некоторые "честные" приложения). В моем дистре очень легко можно сказать честным приложениям собирался без JIT и с оптимизацией под мой проц во время компиляции. Так что все программы будут работать с защитой PAX и без поломок. > ROP в более широком смысле, нежели описанный выше пример, всё равно может позволить обойти W^X pt 2, принятые по-умолчанию меры считаются примемлемыми. CONFIG_PAX_RAP=y делает твой, очень дорогой ROP, практически невозможным. > > PaX отключить принципиально, теоретически и практически невозможно > С трудом представляю, как ты пользуешься такой системой, а главное - зачем Это нормальная система, которая соответствует требованием DAC. Вот старый пример: https://mirror.yandex.ru/mirrors/ftp.linux.kiev.ua/Linux/CD/.../
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 26-Фев-20, 23:29
	>> Если даже у нас уже реализован и используется W^X pt 1, мы всё равно можем внедрить код, сделать ret2libc->ret2mprotect = сделать память исполянемой, выполнить код. Защита преодолена, W^X нарушен. > PAX_ASLR=y > PAX_RANDKSTACK=y > PAX_RANDUSTACK=y > PAX_RANDMMAP=y > Замучаешся преодолевать, есть другие системы которые следят за брутефосом и принимают более > радикальные проактивные меры. Пример, который я описывал был не про обход W^X pt 2 (pax mprotect), а про обход W^X pt 1. Разница в том, что чтобы обойти W^X pt 2 нужен прям честный ROP, который совсем сложен (но да, возможен), в случае с обходом W^X pt 1 достаточно "найти" mprotect и сделать заинъекченый код исполняемым. Это значительно проще. Не знаю, к чему это ты, возможно, ты просто продолбался с цитированием и из-за этого я тебя не так понял. >> ROP в более широком смысле, нежели описанный выше пример, всё равно может позволить обойти W^X pt 2, принятые по-умолчанию меры считаются примемлемыми. > CONFIG_PAX_RAP=y > делает твой, очень дорогой ROP, практически невозможным. Я знаю про PAX_RAP. Ничего не утверждал про его наличие/отсутствие. Утверждал про то, что меры против ROP в OpenBSD затрудняют и сценарий эксплуатации W^X pt 1, поэтому мириться с отсутствием принудительного pax mprotect по-умолчанию приемлемо.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (119), 27-Фев-20, 16:01
	> случае с обходом W^X pt 1 достаточно "найти" mprotect и сделать заинъекченый код исполняемым. Рандомизацтя адресного пространства сильно затрудняет поиск нужного кода. Ты не сможешь перевести заинекченыц код в режим исполнения, pax mprotect этого не даст. > OpenBSD затрудняют и сценарий эксплуатации W^X pt 1, поэтому мириться с отсутствием принудительного pax mprotect по-умолчанию приемлемо. Проблема с защитой памяти много кому на больные мозоли наступает: У Linux мутная история:  https://www.opennet.ru/openforum/vsluhforumID3/119728.html#31 У опенка Тео перехотел сделать нормально: https://www.opennet.ru/openforum/vsluhforumID3/119792.html#6 Использую PAX давно, у меня дистр основанный на исходниках, надо в одном месте указать что ты JIT не желаешь водить и потом соберутся без него. Тех страшных проблем ко орыми вы здесь пугаете продвигая дыру в безопасности не наблюдал. Защита памяти, гарантии неизменности исполняемого кода - безценны по сравнению с мнимой производительностью Jit.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 27-Фев-20, 16:11
	>> случае с обходом W^X pt 1 достаточно "найти" mprotect и сделать заинъекченый код исполняемым. > Рандомизацтя адресного пространства сильно затрудняет поиск нужного кода. Я про это, да. > Ты не сможешь перевести заинекченыц код в режим исполнения, pax mprotect этого не даст. Я не про это. > Использую PAX давно, у меня дистр основанный на исходниках, надо в одном месте указать что ты JIT не желаешь водить и потом соберутся без него. Тех страшных проблем ко орыми вы здесь пугаете продвигая дыру в безопасности не наблюдал. Защита памяти, гарантии неизменности исполняемого кода - безценны по сравнению с мнимой производительностью Jit. Божечки, да причём тут это? Когда-то у меня был арч с grsec-ядром, и в те моменты, когда я не игрался с ним ради самообразования, у меня тоже всё работало, вероятно, где-то я что-то делал для этого - уже не помню. Кому-то нужна производительность, кому-то - строгая безопасность, кому-то соответствие стандартам. Речь не про принципиальную возможность заставить что-то работать, а про стандартную поставку и годность для ОС общего назначения. > У опенка Тео перехотел сделать нормально Ну а по мне - как раз в опёнке нормально.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (121), 28-Фев-20, 15:44
	Мое мнение, контроль за памятью должен быть только у ядра. Изменение исполняемых областей памяти - огромная дыра в безопасности. Тео проделал дырочку оставляя возможность приложениям с JIT изменять исполняемые области памяти. И это будет использовано вирусами. Кому надо производительность тот компилит все под свой проц. Советую всем отказатся от JIT, ядер ОС, "стандартов" и "инструкций" которые допускают изменение исполняемых областей памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 28-Фев-20, 15:49
	> Мое мнение, контроль за памятью должен быть только у ядра. > Советую всем отказатся от JIT, ядер ОС, "стандартов" и "инструкций" которые допускают изменение исполняемых областей памяти. Ради бога. Почему я считаю, что такой максималистский подход малоприменим для всеобщего использования по факту - я написал.
	Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

	123. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (123), 29-Фев-20, 09:07
	Надеюсь, что всем уже стало понятно необходимость, ядром OS или аппаратно процессором, строго контролировать неизменность исполняемых областей памяти и областей данных помеченных только для чтения. Контроль за памятью нельзя делегировать на уровень приложений. Любое такое делегирование это дыра которую будут использовать вирусы. Были, есть и будут OS общего назначения и прикладные программы которые строго соблюдают правила контроля за оперативный памятью. Опенка с этого списка пока вычеркиваем.
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

	124. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 01-Мрт-20, 05:07
	> Контроль за памятью нельзя делегировать на уровень приложений. Любое такое делегирование это дыра которую будут использовать вирусы. Я прочитал сейчас что-то, по меньшей мере, очень странное. И в случае pledge, и в случае PaX за гарантии отвечает ядро. В случае pledge, гарантии заказываются из кода программы, в случае PaX - черех paxctl/конфиг ядра. > Были, есть и будут OS общего назначения и прикладные программы которые строго соблюдают правила контроля за оперативный памятью. Только никакого успеха они не имеют (чего нельзя сказать про нишевые решения). > Опенка с этого списка пока вычеркиваем. ... ==== Я, в принципе, отчасти понимаю твой максимализм - было бы хорошо, если бы все думали про безопасность и не писали код, который требует нарушения W^X. Но всё так, как есть. Нельзя сказать, что ситуация совсем не меняется, но даже там, где стало можно, например, выключать JIT, требующий нарушения W^X, это всё равно не используется как вариант по-умолчанию и закономерно обладает меньшей производительностью.
	Ответить | Правка | К родителю #123 | Наверх | Cообщить модератору

	126. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (126), 01-Мрт-20, 15:26
	> И в случае pledge, и в случае PaX за гарантии отвечает ядро. Нет, в OpenBSD ядро не дает никаких гарантий, оставляя возможность приложениям изменять исполняемый код. Это дыра которую будут использовать вири. > В случае pledge, гарантии заказываются из кода программы, Это смешно. Гарантии неизменности исполняемого кода должно давать ядро или аппаратно проц. > в случае PaX - через paxctl/конфиг ядра. Ядро с PaX дает гарантии неизменности исполняемого кода и гарантии невозможности отключения такого поведения для всех программ. В тоже время есть возможность выбора: 1. Дополнительно добавить в ядро возможность исключения для некоторых программ помеченных через заголовок ELF или расширенные атрибуты файловой системы xattr (PeMRs). Pp - постраничная защита памяти. Ee - эмуляция трамполлайнов. Очень маленькие участки памяти которые можно переводить в режим WX Mm - защита памяти. В частности гарантия W^X. Выше упоминал все гарантии mprotect при использовании PaX ядра. Rr - рандомизация адресного пространства. Ss - посегментна защита памяти, если постраничная не поддерживается процессором (NX инструкция) или мы не доверяем защите памяти реализованной процессором. По умолчанию ядро с PaX дает максимальную защиту. 2. Дополнительно добавить в ядро возможность загружатся в режиме когда PaX ядро не блокирует, а только ведет журнал событий нарушающих нормальное использование памяти. Grsecurity ядро блокирует изменение рабочего ядра через sysctl и следовательно дает гарантии невозможности включать/выключать PaX softmode в случае его поддержки ядром. > > Были, есть и будут OS общего назначения и прикладные программы которые строго соблюдают правила контроля за оперативный памятью. > Только никакого успеха они не имеют (чего нельзя сказать про нишевые решения). Среди тех которые ты должен знать упомяну Apple как фирму чьи OS очень строго защищают память. Также MS Windows имеет защиту оперативной памяти, но менее строгую по сравнению с Apple. MS видать как и Тео с OpenBSD попросили пойти на компромисс и просверлить дырочки, для "повышения производительности". > Нельзя сказать, что ситуация совсем не меняется, но даже там, где стало можно, например, выключать JIT, требующий нарушения W^X, это всё равно не используется как вариант по-умолчанию Самое главное, разработчики поняли, что код с JIT есть небезопасен, непортабелен и просто на некоторых аппаратных (powerpc,mips,..) и программных (Linux+PaX, Apple, ...) не работает. Для этих програмно-аппаратных архитектур есть возможность отключать код JIT еще на этапе конфигурации исходников перед сборкой и он используется по умолчанию всегда. > и закономерно обладает меньшей производительностью. Это очень спорный вопрос. Вас обманывают воруя безопасность и обещая мнимую производительность! Изменения режима исполняемого кода на изменяемый и потом обратно это очень ресурсоемко и врят ли окупится. Оптимизация программы в момент компиляции под целевой процессор дает максимум производительности и скорости исполнения. В добавок можно получить гарантию неизменности исполняемого кода- безопасность.
	Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

	129. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 02-Мрт-20, 00:44
	>> И в случае pledge, и в случае PaX за гарантии отвечает ядро. > Нет, в OpenBSD ядро не дает никаких гарантий, оставляя возможность приложениям изменять исполняемый код. Это дыра которую будут использовать вири. >> В случае pledge, гарантии заказываются из кода программы, > Это смешно. Гарантии неизменности исполняемого кода должно давать ядро или аппаратно проц. Прости, но ты пишешь ахинею. Pledge - это системный вызов, как следствие, вся работа по обеспечению гарантий производится в ядре. С каждым новоым вызовом pledge, выданных разрешений может быть _только_ меньше. Ну да, может быть баг в реализации, ну так он и в PaX может быть. >> > Были, есть и будут OS общего назначения и прикладные программы которые строго соблюдают правила контроля за оперативный памятью. >> Только никакого успеха они не имеют (чего нельзя сказать про нишевые решения). > Среди тех которые ты должен знать упомяну Apple как фирму чьи OS очень строго защищают память. Если мне не изменяет память, то только в мобильном исполнении. И это закрытая экосистема, где список доступных приложений (и их возможности), в теории, полностью контролируется Apple. > Самое главное, разработчики поняли, что код с JIT есть небезопасен Потенциально небезопасен. И многое зависит от реализации. >> и закономерно обладает меньшей производительностью. > Это очень спорный вопрос. Вас обманывают воруя безопасность и обещая мнимую производительность! > Изменения режима исполняемого кода на изменяемый и потом обратно это очень ресурсоемко и врят ли окупится. Меня никто не обманывает. Про "небезопасность" отсутствия PaX MPROTECT (W^X pt 2) я уже писал - повторяться избыточно. По поводу ресурсоёмкости и т.п. - это зависит от реализации и требуемых возможностей. В целом, байткод надо транслировать в машинный код примерно 1 раз, далее можно просто выполнять скомпилированное. Ну да, иногда ради бОльшего "динамизма" такой подход может быть и неприемлем. На производительность, даже не мнимую лично мне скорее пофигу, особенно, если речь о незаметных "на глаз" процентах, особенно если за счёт безопасности, дело не в этом. Дело в том, что всему миру абсолютно наплевать на мои личные хотелки, у разных людей и компаний разные задачи и разные требования. И, к несчастью, реальность такова, что иногда альтернативы решениям с jit нет, а производительности хочется. А писать за свои деньги свою "правильную" альтернативу не хочется. Или денег нет. > Оптимизация программы в момент компиляции под целевой процессор дает максимум производительности и скорости исполнения. В добавок можно получить гарантию неизменности исполняемого кода- безопасность. Вашими бы устами да мёд пить.
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	131. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (131), 02-Мрт-20, 15:51
	> Pledge - это системный вызов, как следствие, вся работа по обеспечению гарантий производится в ядре. Плохо то, что есть в ядре OpenBSD возможность дать программ право изменять исполняемый код. И в OpenBSD нет опции в конфиге ядра отключить такое поведение. Следовательно гарантий неизменности исполняемого кода в OpenBSD нет. > Про "небезопасность" отсутствия PaX MPROTECT (W^X pt 2) я уже писал - повторяться избыточно. Повторение - мать учения. Именно благодаря PaX MPROTECT получаем гарантию неизменности исполняемого кода: Enabling this option will prevent programs from - changing the executable status of memory pages that were    not originally created as executable, - making read-only executable pages writable again, - creating executable pages from anonymous memory, - making read-only-after-relocations (RELRO) data pages writable again. https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...)
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

	132. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 02-Мрт-20, 16:10
	>> Pledge - это системный вызов, как следствие, вся работа по обеспечению гарантий производится в ядре. > Плохо то, что есть в ядре OpenBSD возможность дать программ право изменять исполняемый код. И в OpenBSD нет опции в конфиге ядра отключить такое поведение. Следовательно гарантий неизменности исполняемого кода в OpenBSD нет. Нет, это не плохо, это адекватно требованиям, выдвигаемым к ОС общего назначения. Проблема, на наличии которой ты настаиваешь имеет место, но её важность преувеличена. Поэтому, OpenBSD не даёт общесистемных гарантий, но позволяет гарантировать отсутствие prot_exec для отдельно взятой программы. На уровне логики работы самой программы. > Повторение - мать учения. А мне уже слегка надоело повторять одно и то же разными словами.
	Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

	133. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (133), 03-Мрт-20, 15:55
	> Поэтому, OpenBSD не даёт общесистемных гарантий, но позволяет гарантировать отсутствие prot_exec для отдельно взятой программы. На уровне логики работы самой программы. Нет сегодня возможности проверить логику работы всех программ. А безопасность иметь хочется. Единственный путь это гарантии неизменности исполняемого кода ядром OS или аппаратно процессором. > А мне уже слегка надоело повторять одно и то же разными словами. И мне.
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	134. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 03-Мрт-20, 16:05
	>> А мне уже слегка надоело повторять одно и то же разными словами. > И мне. Ну, я к тому, что можно и заканчивать. Кажется, друг друга мы поняли, друг с другом не согласны. Подозреваю, что мы оба сможем с этим жить. От того, что мы будем повторять друг другу одно и то же, кажется, пользы ни одному из нас не будет. На всякий: не принимай, пожалуйста, это за проявление неуважения к тебе.
	Ответить | Правка | К родителю #133 | Наверх | Cообщить модератору

	136. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (135), 04-Мрт-20, 16:38
	> можно и заканчивать Вы не сказали самый главный аргумент против использования W^X. А его надо понимать и помнить всем! Ситуация когда безопасность имеет приоритет ниже чем сервис!!! Примеры: система жизнеобеспечения больного в больнице, авиодиспетчеры, управление опасным производством, ядерный реактор, ... В этих случаях ядра жестко убивающие за нарушения выделения памяти использовать нельзя. Для этого используется режим "PaX softmode" когда все нарушения только журналируются, а процесс продолжает работать без любых ущемлений ядром. Реализация PaX в GNU/Linux очень правильная и предусматривает все режимы работы для OS общего назначения.
	Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

	137. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 04-Мрт-20, 16:41
	> Примеры: система жизнеобеспечения больного в больнице, авиодиспетчеры, управление опасным производством, ядерный реактор, ... ИМХО, это всё совсем не про ОС общего назначения. И даже не только лишь по требованиям, связанным с безопасностью.
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	138. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (135), 04-Мрт-20, 16:48
	> ИМХО, это всё совсем не про ОС общего назначения. Про OS общего назначения это: Реализация PaX в GNU/Linux очень правильная и предусматривает все режимы работы для OS общего назначения. А это: Примеры: система жизнеобеспечения больного в больнице, авиодиспетчеры, управление опасным производством, ядерный реактор, ... О том что не надо жесткий W^X пихать всюда без разбору. Есть места где безопасность совсем не главное и поддержка работающего сервиса имеет высший приоритет.
	Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

	139. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 04-Мрт-20, 17:20
	> Про OS общего назначения это: Я понял :) На эту тему все мысли, которые у меня были я уже написал, больше не хочу повторять одно и то же. > Есть места где безопасность совсем не главное и поддержка работающего сервиса имеет высший приоритет. Тогда просто не понятно, причём тут это. Там, насколько я могу понимать (практики администрирования подобного у меня нет), сильно своя атмосфера и там, помимо безопасности, ещё важна, как минимум риалтаймовость, да и резервировать, как я понимаю, там нужно примерно всё, если не хочется фатальных неожиданностей. И там-то, кстати, лично я строгий PaX могу представить - ПО там специализированное и пишется специально под эти задачи, специальными людьми. Ничто не мешает (теоретически) сразу написать ПО с учётом модели памяти в PaX и смысл в этом есть. Как там на самом деле всё настроено и работает, повторюсь, не знаю, ввиду отсутствия практики.
	Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

	140. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (140), 04-Мрт-20, 17:41
	> Ничто не мешает (теоретически) сразу написать ПО с учётом модели памяти в PaX и смысл в этом есть. Классика жанра: В спец ПО для райнимации больного допустили ошибку переполнения буфера или даже ядро OS имеет ошибку переполнения буфера. Вирус использует эту уязвимость переполнения буфера и ядро с W^X убивает процесс поддержки жизнедеятельности человека. Человек погибает, а компьютер остается не зараженным. В случаях когда работа сервиса имеет приоритет над безопасностью, жесткий контроль за памятью использовать нельзя. Просто журналируются все события некорректного поведения процесса, без каких либо санкций к нему. Это надо обязательно понимать и помнить.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	141. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Дон Ягон (ok), 04-Мрт-20, 17:58
	>> Ничто не мешает (теоретически) сразу написать ПО с учётом модели памяти в PaX и смысл в этом есть. > Классика жанра: > В спец ПО для райнимации больного допустили ошибку переполнения буфера или даже ядро OS имеет ошибку переполнения буфера. Вирус использует эту уязвимость переполнения буфера и ядро с W^X убивает процесс поддержки жизнедеятельности человека. Человек погибает, а компьютер остается не зараженным. Логика рассуждения мне понятна, спасибо. Мне не понятно, почему бы не резервировать эти процессы на изолированных контурах, например. Процесс может упасть из-за более тривиальной баги, не связанной с безопасностью - что тогда? Или, например, можно не использовать динамических алокаций вообще, если условия задачи позволяют. А PaX не обязательно убивает процесс, тот же PaX MPROTECT, про который тут шла речь, приводит к тому, что mprotect возвращает EPERM (с этим меня тут недалеко поправили) - это можно обрабатывать в коде программы. > В случаях когда работа сервиса имеет приоритет над безопасностью, жесткий контроль за памятью использовать нельзя. Просто журналируются все события некорректного поведения процесса, без каких либо санкций к нему. > Это надо обязательно понимать и помнить. В моём понимании, это не напрямую связанные вещи. Если конструкция в целом умеет переживать смерть отдельного процесса без остановки сервиса, то не вижу проблем даже и в прибивании за нарушение гарантий памяти. Если не умеет, то мы нарвёмся на проблемы и без проблем с безопасностью. Требование-то, на самом деле, к непрерывности предоставления сервиса, а не к модели памяти. От этого, имхо, и нужно рассуждать.
	Ответить | Правка | К родителю #140 | Наверх | Cообщить модератору

	144. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (144), 05-Мрт-20, 16:31
	> Мне не понятно, почему бы не резервировать эти процессы на изолированных контурах, например. А кто даст гарантию что не упадет процесс отвечающий за переключения или вообще само ядро, для которого тоже W^X применяется? Смотри на ситуацию вирусной атаки - все процессы в памяти имеют уязвимость переполнения буфера и при вирусной атаке ядпо с W^X их всех прибет. W^X очень простая, дешовая и эффективная техника безопасности. Она идеальна для рабочей станции секретарши, смартфона, планшета, ноута итп. В системах для которых кретически важна безперебойная работа используют другие, более дорогие, техники безопасности. А PAX включают только в режиме softmode для журналирования. > Процесс может упасть из-за более тривиальной баги, не связанной с безопасностью - что тогда? Тогда виноват не админ с PaX а программист... > mprotect возвращает EPERM (с этим меня тут недалеко поправили) - это можно обрабатывать в коде программы. Это делать можно, например clamav так и делал. Но это неправильно. Лучше програмистам давать возможность сборщикам пакетов выбор JIT ветки кода в момент конфигурации перед компиляцией. > Если конструкция в целом умеет переживать смерть отдельного процесса без остановки сервиса, то не вижу проблем даже и в прибивании за нарушение гарантий памяти. Если не умеет, то мы нарвёмся на проблемы и без проблем с безопасностью. > Требование-то, на самом деле, к непрерывности предоставления сервиса, а не к модели памяти. От этого, имхо, и нужно рассуждать. Еще разок, если есть ошибка переполнения буфера то PaX с grsecurity может не только убивать один процесс. Может убить все процессы пользователя и запретить ему вход в систему. Может вообще само ядро убить! Мы не знаем какую область памяти перезапишим за пределами буфера. Общее правило: проактивные системы защиты, которые убивают процессы, нельзя использовать в системах критических для жизни людей, экологии, производства ИТП...
	Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

	145. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+1 +/–
	Сообщение от Дон Ягон (ok), 05-Мрт-20, 17:06
	>> Мне не понятно, почему бы не резервировать эти процессы на изолированных контурах, например. > А кто даст гарантию что не упадет процесс отвечающий за переключения или вообще само ядро, для которого тоже W^X применяется? Всё зависит от того, как именно всё реализовано. Мы этих моментов не уточнили - я не понимаю, как тебе ответить: мы можем придумывать примеры и контрпримеры почти бесконечно. Например, переключатель может быть вообще исполнен в железе. > В системах для которых кретически важна безперебойная работа используют другие, более дорогие, техники безопасности. А PAX включают только в режиме softmode для журналирования. Я не знаю, что именно там используется, но представить там PaX я вполне могу. > Смотри на ситуацию вирусной атаки Смотрю: пришёл хакир-вася, поломал мой мега-софт и выключил жизнеобеспечение пациента/систему АЗ АЭС. Потому что может. В логе осталась запись. Успех. (за скобками оставляем вопрос о том, откуда на нашем мега-важном производстве взялся удалённый доступ к критичным сервисам из недоверенной сети) >> Процесс может упасть из-за более тривиальной баги, не связанной с безопасностью - что тогда? > Тогда виноват не админ с PaX а программист... За падение даже куда менее критичных сервисов админ, работающий на вменяемую компанию, обычно получает конкретный втык. Смерть пациента или проблемы с АЭС - это, с ненулевой вероятностью, подсудное дело. И перевод стрелок тут не прокатит. И тем более не понятно, почему в падении из-за бага (т.е. без внешнего злонамеренного воздействия) виноват программист, а в падении из-за уязвимости - администратор. Код в обоих случаях написан условным программистом. Система в обоих случаях обслуживается условным администратором. > Еще разок, если есть ошибка переполнения буфера то PaX с grsecurity может не только убивать один процесс. Может убить все процессы пользователя и запретить ему вход в систему. Может вообще само ядро убить! Мы не знаем какую область памяти перезапишим за пределами буфера. Што? > Общее правило: проактивные системы защиты, которые убивают процессы, нельзя использовать в системах критических для жизни людей, экологии, производства ИТП... Нет, не так: в системах, критических для жизни людей, экологии и т.п. нельзя, чтобы критичный процесс был незарезервирован и мог упасть "насовсем". Средства достижения этой цели могут варьироваться в зависимости от задач и возможностей.
	Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

	148. "Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"	+/–
	Сообщение от Аноним (148), 07-Мрт-20, 14:28
	> Всё зависит от того, как именно всё реализовано. Мы этих моментов не уточнили - я не понимаю, как тебе ответить: мы можем придумывать примеры и контрпримеры почти бесконечно. Например, переключатель может быть вообще исполнен в железе. > Я не знаю, что именно там используется, но представить там PaX я вполне могу. > > Еще разок, если есть ошибка переполнения буфера то PaX с grsecurity может не только убивать один процесс. Может убить все процессы пользователя и запретить ему вход в систему. Может вообще само ядро убить! Мы не знаем какую область памяти перезапишим за пределами буфера. > Што? Есть общая теория проактивной защиты. Область применения: гарантии безопасности некретических для жизни человека, экологии, ... ИТ систем. Доступность сервисов в этой теории неважна, важны гарантии безопасности и недопущения вреда самой ИТ системе. Грубо говоря в этой теории выделяют 3 класса активной реакции системы на взлом: 1. Убить один процесс который нарушил определенные правила. 2. Убить все процессы некого пользователя и запретить создания новых процессов этому пользователю, который сильно нарушает правила. 3. Ядро OS убивает себя. В самой критической ситуации для предотвращения развития атаки ядро OS убивает само себя. Пример реализации: CONFIG_GRKERNSEC_BRUTE=y CONFIG_GRKERNSEC_KERN_LOCKOUT=y https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri... "If you say Y here, when a PaX alert is triggered due to suspicious activity in the kernel (from KERNEXEC/UDEREF/USERCOPY) or an OOPS occurs due to bad memory accesses, instead of just terminating the offending process (and potentially allowing a subsequent exploit from the same user), we will take one of two actions: If the user was root, we will panic the system If the user was non-root, we will log the attempt, terminate all processes owned by the user, then prevent them from creating any new processes until the system is restarted This deters repeated kernel exploitation/bruteforcing attempts and is useful for later forensics." Для админа это очень важно понимать!!! Вот пример: по соседству https://www.opennet.ru/openforum/vsluhforumID3/119792.html#146 он думает что Linux capabilities и DAC это одно и тоже. На практике будет тоже что с умершим в больнице пациентом: в случае запрета доступа DAC прога получает просто Access denied от ядря и может его обработать, а в случае нарушения capabilities проактивное ядро OS этот процесс убет. > > > Процесс может упасть из-за более тривиальной баги, не связанной с безопасностью - что тогда? > > Тогда виноват не админ с PaX а программист... > За падение даже куда менее критичных сервисов админ, работающий на вменяемую компанию, обычно получает конкретный втык. > ... И перевод стрелок тут не прокатит. За баг в программе отвечает програмист, тестер, а не админ. Админ может только поймать баг и написать по этому поводу рапорт. Да, резервирование, мониторинг и подем упавших сервисов, минимизация/исключение времени простоя - дело админа. > не понятно, почему в падении из-за бага (т.е. без внешнего злонамеренного воздействия) виноват программист, а в падении из-за уязвимости - администратор. Если падение из-за бага программы виновны однозначно только разработчики программы. Если падение вызвано активной реакцией ядра OS на попытку эксплуатации уязвимости, то уже могут быть виновны не только програмисты, написавшие уязвимый код. В этом случае есть действие админа который установил проактивную защиту ядра OS. И если проактивная защита была установлена в системе, для которой предоставление сервиса более важно чем ее безопасность, то это уже вина админа. Если код уязвим и идет вирусная атака, то в случае дешовой проактивной защиты, сервис будет недоступен даже с резервированием и защитой от сбоев. В этом случае для гарантии доступности сервиса приходится применять более дорогие средства защиты и обязанность админа их применить.
	Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

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

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