forum.opennet.ru - "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." (151)

"Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."

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

"Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+1 +/–
Сообщение от opennews (?), 29-Янв-20, 09:57
В развиваемом проектом OpenBSD почтовом сервере OpenSMTPD выявлена критическая уязвимость (CVE-2020-7247), позволяющая удалённо выполнить shell-команды на сервере с правами пользователя root. Уязвимость выявлена в ходе повторного аудита, проведённого компанией Qualys Security (прошлый аудит OpenSMTPD проводился в 2015 году, а новая уязвимость присутствует с мая 2018 года). Проблема устранена в выпуске OpenSMTPD 6.6.2. Всем пользователям рекомендуется срочно установить обновление (для OpenBSD исправление можно установить через syspatch)... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52267
Ответить \| Правка \| Cообщить модератору

Оглавление

это не уязвимость, повторяю, НЕ УЯЗВИМОСТЬ в OpenBSD уязвимостей нет, а все серв, Spoofing (?), 09:57 , 29-Янв-20, (1) –7

Найс аутотренинг, Аноним (5), 10:08 , 29-Янв-20, (5) +11

Это не аутотренинг, это стёб над позицией разработчиков опёнка , pda (?), 13:43 , 29-Янв-20, (30) +5

Демонстрирующий, главным образом, непонимание этой самой позиции , Дон Ягон (ok), 13:50 , 29-Янв-20, (31) +2

Так разъясните Они любят заострять внимание на Only two remote holes in the de, pda (?), 03:08 , 31-Янв-20, (131)

Only two remote holes in the default install, in a heck of a long time - это , Дон Ягон (ok), 14:53 , 31-Янв-20, (145)

Потому что выглядит как попытка ввести в заблуждение Люди ожидают от default i, pda (?), 00:42 , 03-Фев-20, (156)

Для кого Для тех, кто не умеет читать Для тех кто не в курсе про наличие темати, Дон Ягон (ok), 12:39 , 03-Фев-20, (157)

Разработчики OpenSMTPD говорят, что есть Но тебе, конечно, виднее Qualys has f, Дон Ягон (ok), 12:21 , 29-Янв-20, (20) +4

Спасибо ребятам из Qualys, которые на деле показали, что OpenBSD мало чем отлича, XL (?), 13:14 , 29-Янв-20, (24) –6

Конечно, мало чем Всего лишь реакцией за считанные дни и часы вместо замалчиван, Аноним (26), 13:27 , 29-Янв-20, (26) +4
Ага, и не в первый раз уже Как ни найдут дыру в OpenBSD, так сразу на деле пок, Дон Ягон (ok), 13:30 , 29-Янв-20, (27) +9

Ты зачем сразу с козырей то зашел , ssh (ok), 13:38 , 29-Янв-20, (28) +2
То есть преимущество OpenBSD над другими системами это настройки по умолчанию Т, Zulu (?), 16:24 , 29-Янв-20, (50) –6

Это один из способов снижения вреда от уязвимостей Естественно, всех проблем не, Дон Ягон (ok), 17:12 , 29-Янв-20, (59) +1

Я стараюсь намекнуть на то, что безопасность надо сравнивать при сопоставимых фу, Zulu (?), 18:09 , 29-Янв-20, (69)

Смотря в каком контексте рассматривать Если речь об использовании OpenSMTPD как , Дон Ягон (ok), 18:24 , 29-Янв-20, (74)

Зачем тогда в принципе устанавливать программу, которая в дефолтных настройках , sstj3n (?), 20:37 , 29-Янв-20, (89) +1

вздыхает Ты не знаешь, зачем нужен локальный почтовик в юниксах UPD И да, блин, Дон Ягон (ok), 21:05 , 29-Янв-20, (91) +2

Речь не о том, зачем он там нужен, а о том, насколько он необходим для функциони, sstj3n (?), 10:31 , 30-Янв-20, (112)

В стандартной поставке он нужен рутовые нотификации , далее ты можешь настроить, Дон Ягон (ok), 13:34 , 30-Янв-20, (123)

Как же туго-то Суть примеров если то, что ты называешь адекватными настройка, sstj3n (?), 09:43 , 31-Янв-20, (142)

Ты или слушаешь в пол уха или не хочешь понимать меня, похоже Core functionality, Дон Ягон (ok), 15:50 , 31-Янв-20, (146)

В смысле письма от всяких демонов на root host Как мне показалось, формулировка, Дон Ягон (ok), 03:00 , 01-Фев-20, (154)

Зачем вообще локальному почтовику слушать smtp Насколько я помню в debian exim , Анонимус2 (?), 11:21 , 30-Янв-20, (113)
И зачем, если локально хватает MTA типа DMA man dma, Аноним (122), 13:24 , 30-Янв-20, (122) +1

DMA - очень хороший вариант, да и вообще стрекоза мне нравится В OpenBSD вмес, Дон Ягон (ok), 13:37 , 30-Янв-20, (124) +1

Я обманул, инсталлятор спрашивает о том, запускать по дефолту или нет , Дон Ягон (ok), 03:19 , 01-Фев-20, (155)

Мы и не продаём слона , Аноним (66), 18:00 , 29-Янв-20, (66)

Т е General Motors, JPL не в счет , OpenEcho (?), 16:55 , 29-Янв-20, (53) +1

Можно каких-то пруфов Не то, чтобы я сомневаюсь или не верю, просто люблю, когд, Дон Ягон (ok), 17:22 , 29-Янв-20, (61)

Информация инсайдерская, поэтому сорри, пруфов не будет, хотите верьте, хотите н, OpenEcho (?), 19:30 , 29-Янв-20, (78) +1

Ничего в моей жизни не изменится от того, поверю я или нет Также ничего не изме, Дон Ягон (ok), 19:37 , 29-Янв-20, (81)

Полностью согласен, sorry, просто обидно за опенку стало, сорвалось Надеюсь ли, OpenEcho (?), 19:45 , 29-Янв-20, (82)

Разумеется Это вебмакаки опять тру ветеранам сишникам из BSD баги в код залили , Аноним (80), 19:34 , 29-Янв-20, (80) –1

Мсье сейчас, разумеется, расскажет, как от ЛОГИЧЕСКИХ ошибок в АЛГОРИТМЕ страхуе, Michael Shigorin (ok), 12:53 , 30-Янв-20, (116) +2

Простите, Михаил, но тут не какие-то абстрактные логические ошибки Конкретно эт, Аноним (80), 15:37 , 30-Янв-20, (130) –2

Это какой-то очень специфичный вариант юниксвэя - так странно sh звать прямо хар, Аноним (-), 06:59 , 31-Янв-20, (133)

https www opennet ru openforum vsluhforumID3 119631 html 147, Дон Ягон (ok), 17:50 , 31-Янв-20, (150)
Это юниксвей тот самый, изначальный, лазоревый, который worse is better Простот, Аноним (80), 18:50 , 31-Янв-20, (153)

15 8211 поняли очевидный сарказм-23 8211 не поняли, Аноним (83), 19:58 , 29-Янв-20, (83) +1
Э, вот пардон, сервис под маркой OpenSMTPD изначально маркетировавшийся как с, Аноним (-), 06:57 , 31-Янв-20, (132)

Qmail When a mail message arrives, qmail-local runs sh -c command in your home, Дон Ягон (ok), 17:21 , 31-Янв-20, (147)

define BUG FEATURE, мде , Аноним (-), 07:50 , 31-Янв-20, (138)

Неуловимого Джо таки поймали И при этом, к его большому огорчению, поймали не с, A.Stahl (ok), 09:58 , 29-Янв-20, (2) –11

https mobile twitter com OpenSMTPD status 1222288467046076417А это он так пыта, антикудах (?), 11:47 , 29-Янв-20, (19) +8

На странице Goals их сайта первая же строка Be as secure as possible , Аноним (4), 10:02 , 29-Янв-20, (4)

Что-то execle bin sh , bin sh , -c , mda_command, не выглядит в этом к, Аноним (-), 07:07 , 31-Янв-20, (134)

https www opennet ru openforum vsluhforumID3 119631 html 147, Дон Ягон (ok), 17:51 , 31-Янв-20, (151)

Вообще я бы за такое выгонял из профессии навсегда, но в секьюрном бсд видимо лу, Анонимус2 (?), 10:16 , 29-Янв-20, (6) –2

Будьте так добры, накидайте ссылочек, как необходимо делать по вашему мнению , Аноним (11), 10:47 , 29-Янв-20, (11) +3

Оне выгонять учились, а не тому как надо делать , Нононим (?), 10:54 , 29-Янв-20, (13) +4
Смотри postfix, Аноним (22), 12:40 , 29-Янв-20, (22) –3

Тот же postfix тоже позволяет запускать команду mda шеллом https github com vd, Дон Ягон (ok), 13:20 , 29-Янв-20, (25) +1

Не совсем То что он недостаточно хорошо проверяет -- это проблема Но то, что о, Ordu (ok), 14:52 , 29-Янв-20, (41) +5

Для начала, спасибо за развёрнутое сообщение с текстом по существу вопроса Если , Дон Ягон (ok), 15:13 , 29-Янв-20, (44) +1

Во-первых, там не нужна валидация Нельзя сказать, чтобы совсем не нужна, но сра, Ordu (ok), 17:43 , 29-Янв-20, (62)

Описанная проблема понятна, её разработчики OpenSMTPD пытаются решать списком до, Дон Ягон (ok), 20:04 , 29-Янв-20, (86)

Да, но и тем не менее логическая ошибка в коде экранизации привела к возможности, Ordu (ok), 00:27 , 30-Янв-20, (102)

Сори за долгий ответ, не хотелось отвечать совсем не подумав Я такого способа не, Дон Ягон (ok), 14:38 , 30-Янв-20, (129)

Ну да, в случае libsh условного , мы бы вызывали саму программу Но тогда бы да, Дон Ягон (ok), 20:54 , 29-Янв-20, (90)

Спс, Аноним (11), 13:55 , 29-Янв-20, (32)
В postfix было так https www exploit-db com exploits 34896Уязвимость в bash C, Аноним (109), 01:14 , 30-Янв-20, (109)

Не делать вызов sh программно вообще никогда, не видел пока ни одной программы с, Анонимус2 (?), 11:35 , 30-Янв-20, (114)

Во-во А если какие-то параметры отдать надо - то наверное все-таки не в sh -c, , Аноним (-), 07:11 , 31-Янв-20, (135)

Просто нужно запретить создание произвольных процессов Вместо этого при вызове , Аноним (7), 10:30 , 29-Янв-20, (7) +1

SELinux это умеет Или другое решение , Аноним (83), 20:02 , 29-Янв-20, (84)

Нет, не умеет Это capability-based security См не взлетевший cloudABI , Аноним (7), 00:31 , 30-Янв-20, (103)
SELinux в OpenBSD , phaoost (ok), 11:39 , 30-Янв-20, (115)

У них, кстати, pledge есть Он что, не умеет лимитировать параметры сисколов Вп, Аноним (-), 07:14 , 31-Янв-20, (136)

на селе можно, но для 99 цЫкурити-админов сильно сложно ибо редхад методички, исчо_адын_гентушнег (?), 16:22 , 04-Фев-20, (159)

Ага, все-таки можно настраивать сервер через SMTP А то все SSH, да SSH , Аноним (15), 10:56 , 29-Янв-20, (15) +10

Ну блин всегда так делал, а тут понабежали Повторяю это НЕ БАГ, это фича , neAnonim (?), 11:11 , 29-Янв-20, (16) –4

Именно АНБ просили сделать возможнность , им сделали А тут пришли какие-то ан, Аноним (37), 14:42 , 29-Янв-20, (37)

ЫХыххыхы , Аноним (17), 11:15 , 29-Янв-20, (17) +2

Неуловимый Джо отбегался по прериям , Аноним (18), 11:44 , 29-Янв-20, (18) –6

И ни меча, ни лат, и лицом в салат до утра - вот и все дела , Аноним (87), 20:16 , 29-Янв-20, (87)

Двоякие ощущения С одной стороны хорошо, что нашли, с другой - похожее уже было, Дон Ягон (ok), 12:27 , 29-Янв-20, (21) +3
Самая бестолковая из всех bsd и этот хайп про безопасность ОС для фанатиков , Аноним (-), 13:09 , 29-Янв-20, (23) –4

Есть ещё NetBSD, которая без хайпа , Аноним (37), 14:43 , 29-Янв-20, (38) –1

и без каких-либо заметных достоинств вообще , Аноним (40), 14:51 , 29-Янв-20, (40) –2

Это, конечно же, не так NetBSD вполне себе достойная ОС , Дон Ягон (ok), 14:56 , 29-Янв-20, (42) +1

Как минимум там есть Чеусов - , Michael Shigorin (ok), 12:57 , 30-Янв-20, (117)

Мне это мало о чём говорит Погуглил, нашёл про nih пакетный менеджер , вспомни, Дон Ягон (ok), 13:45 , 30-Янв-20, (125)

NetBSD и по безопасности внезапно, да , и по сетевой подсистеме и по многим д, 11 (?), 16:16 , 29-Янв-20, (46)

При всех моих симпатиях к NetBSD как и к прочим BSD-системам , в комментарии на, Дон Ягон (ok), 16:55 , 29-Янв-20, (54) +4

Опять словоблудие Ещё себе пару плюсиков поставь Секта она и есть секта , Аноним (-), 21:12 , 29-Янв-20, (93) –2

Зато ты предельно конкретен, ага Сколько надо, столько и поставлю, у тебя спрошу, Дон Ягон (ok), 21:25 , 29-Янв-20, (96)

От openssh ты конечно уже отказался , Аноним (55), 17:04 , 29-Янв-20, (55)

Отродясь не пользовался , Аноним (-), 21:11 , 29-Янв-20, (92)

дропбер путти локалхост онли одмин твое все , Аноним (98), 21:33 , 29-Янв-20, (98) +3

Тогда скорее Далее, далее, далее, ОК , Michael Shigorin (ok), 12:58 , 30-Янв-20, (118)

Она работает на VAX И на тостерах , Аноним (83), 20:03 , 29-Янв-20, (85)
HammerFS Единственные из BSDшников кто смог хотя-бы попытаться сделать приличну, Аноним (-), 09:51 , 31-Янв-20, (143)

HAMMER разрабатывается в DragonflyBSD, Мэттом Диллоном и компанией В NetBSD UFS , Дон Ягон (ok), 17:24 , 31-Янв-20, (148)

У NetBSD нет слогана и она оплачивает аудит http blog netbsd org tnf entry ne, Аноним (-), 01:58 , 30-Янв-20, (110)

https packages debian org bullseye opensmtpdhttps centos pkgs org 7 epel-x86, Аноним84701 (ok), 13:43 , 29-Янв-20, (29) +4

Этих шутов из OpenBSD имеет смысл содержать только ради openssh Что, собственно, Аноним (37), 14:49 , 29-Янв-20, (39) –6

Перепиши openssh на своём любимом яваскрипте и тебе не придётся больше содержать, Хороним (?), 14:57 , 29-Янв-20, (43) +3

А как все на exim гнали когда полгода назад уязвимость у него выявили У всех та, suffix (ok), 14:15 , 29-Янв-20, (33) –1

Всё-таки есть разница между наличием ошибок в принципе и положенным на безопасно, Дон Ягон (ok), 14:25 , 29-Янв-20, (34)

sh -c с параметрами сформированными из юзерских данных так и хочется назвать бол, Аноним (-), 07:17 , 31-Янв-20, (137)

Процитирую сам себя Qmail When a mail message arrives, qmail-local runs sh -c c, Дон Ягон (ok), 17:32 , 31-Янв-20, (149)

Так вы посравнивайте, что и в каких количествах находили у exim в тот же период , Аноним (26), 14:32 , 29-Янв-20, (36) +1

То что , Аноним (55), 17:07 , 29-Янв-20, (56)

То сидите дальше на своей пороховой бочке, только не удивляйтесь, что менее скло, Michael Shigorin (ok), 12:59 , 30-Янв-20, (119)

Не пойму, что здесь многие уцепились, за BSD или за людей с недостаточным или н, Аноним (11), 16:03 , 29-Янв-20, (45)
Заметил забавную тендецию, что в теме где встречается фэйлы про опенку очень зна, VeryWideOpenBSD (?), 16:18 , 29-Янв-20, (47) –2

Советую последить за Доном Ягоном, если он в новости, то обычно минусы встречают, Аноним (-), 16:23 , 29-Янв-20, (49) –2

Советую проследить за анонимами Если они в новости, то минусы встречаются везде, Аноним (-), 16:35 , 29-Янв-20, (52) +1
Естественно я ставлю минусы тем, кто пишет херню с моей точки зрения в мере по, Дон Ягон (ok), 17:18 , 29-Янв-20, (60) +3

Так-то пока херню тут пишешь только ты Причём огромные простыни потока сознания, lorovec (?), 21:26 , 29-Янв-20, (97) –2

Ну раз ты так сказал Даже если так, то не по той причине, что там нашли о, Бо, Дон Ягон (ok), 21:49 , 29-Янв-20, (100) +1
Это я, ленивый Перерезус лень логиниться , пока ещё агрюсь И ловлю кучу минусо, Аноним (26), 01:09 , 30-Янв-20, (104) +1

Пора перебарывать лень привет А на User294 не обижайся, его я покусал, когда , Michael Shigorin (ok), 13:03 , 30-Янв-20, (120)

Меня одно время тоже задолбали BSDшники вопящие в всех ветках про линух И вот т, Аноним (-), 08:33 , 31-Янв-20, (140) –1

Спасибо на добром слове, коли не шутите , Дон Ягон (ok), 13:59 , 30-Янв-20, (127)
Перерезус, просто для сведений 1 Я технически не могу ставить минусы JS тут, Аноним (-), 08:31 , 31-Янв-20, (139)

129318 129318 129318 21й век, а openBSD разрабы еще в 20м , pin (??), 16:22 , 29-Янв-20, (48) –1

Ага, в 21 веке shell же отменили, на новый год президент как раз выступал с этим, Аноним (55), 17:10 , 29-Янв-20, (58)

Ну да, писать на C и дергать из него shell Месье знает толк , pin (??), 18:48 , 29-Янв-20, (75)

Действительно, когда уже execve сделают deprecated , Аноним (26), 01:10 , 30-Янв-20, (105)

Execve с параметрами из юзерского ввода вообще стремноватая затея, а когда там к, Аноним (-), 08:35 , 31-Янв-20, (141)

https www opennet ru openforum vsluhforumID3 119631 html 147, Дон Ягон (ok), 17:52 , 31-Янв-20, (152)

Почитал тему К чему эти бессмысленные простыни текста от юзеров опёнка Какие-т, Iron_ (?), 16:29 , 29-Янв-20, (51) –2

А вы, простите, кто, что бы оценки раздавать качеству кода , Аноним (55), 17:09 , 29-Янв-20, (57) +1
А в чём смысл этих срывов покровов про безопасность OpenBSD почти в каждой теме , Дон Ягон (ok), 17:46 , 29-Янв-20, (64)
А сколько уязвимостей мсье нашёл в чужом коде, чтобы так авторитетно говорить, м, Аноним (26), 01:11 , 30-Янв-20, (106) +1

Эй фряшники как победить trueos aks freebsd 13checking whether gmake sets MAK, Аноним (63), 17:44 , 29-Янв-20, (63)

Что там aka -то И почему не в более подходящей, соседней новости о MPV там ес, анонн (ok), 18:04 , 29-Янв-20, (67)

Что за дичь, кто вайном из репы пользуется Там такое-то шерето в коде по дефолт, Аноним (76), 19:00 , 29-Янв-20, (76)

И шерето магически исчезнет, если собрать самому из портов , анонн (ok), 19:26 , 29-Янв-20, (77)

Нужно немножко поправить юзы , тогда исчезнет Большая часть потенциально уязви, Аноним (76), 21:19 , 29-Янв-20, (94)

Configuring for wine-devel-5 0 r6,1configure loading site script usr por, Аноним (63), 17:48 , 29-Янв-20, (65)

У вас компилятор бракованый, видимо пиратская версия, Аноним (71), 18:10 , 29-Янв-20, (71) +2
См config log, но лучше сразу ставьте минт , Michael Shigorin (ok), 13:04 , 30-Янв-20, (121) +1

тут про bsd, права кругом дефолтные и версию wine хочу новее , Аноним (63), 18:08 , 29-Янв-20, (68)

Как пропатчить KDE2 тогда уж спрашивайте , Аноним (26), 01:13 , 30-Янв-20, (107) +1

это сделать , Аноним (63), 18:10 , 29-Янв-20, (70)

посмотреть в вывод mount code mount tmpfs on tmp tmpfs, local, noexec, nos, анонн (ok), 19:31 , 29-Янв-20, (79)

с расстройства не сделал ответом log , Аноним (63), 21:36 , 29-Янв-20, (99)

fstab Device Mountpoint FStype Options Dum, Аноним (63), 18:14 , 29-Янв-20, (72)
Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..., Аноним (63), 18:15 , 29-Янв-20, (73)

Не ваше Вы не умеете в домашнюю работу 8212 вы идёте лесом , Аноним (26), 01:14 , 30-Янв-20, (108) +1

Все хором проигнорировали фразу в соответствии с требованиями RFC 5322 Отдельн, DAV (?), 20:24 , 29-Янв-20, (88)
пиратская всё такиCopyright C 2019 Free Software Foundation, Inc This is free , Аноним (63), 21:19 , 29-Янв-20, (95)

Чей-то тут не то code uname -rsFreeBSD 12 1-STABLE locate libc_nonshared usr , анонн (ok), 22:02 , 29-Янв-20, (101)
Подозреваю, что вы намудрили с опциями сборки gcc9 как бы намекает Возможно, о, Дон Ягон (ok), 13:55 , 30-Янв-20, (126)

https download freebsd org ftp snapshots amd64 13 0-CURRENT отсюда взял базу, , Аноним (111), 06:57 , 30-Янв-20, (111)
Доломал и фряху поставил, но как собрать wine5 с поддержкой в том числе и 32бит , Аноним (144), 13:23 , 31-Янв-20, (144)
Разработчик OpenSMTPD опубликовал разбор ситуации с уязвимостью и некоторые сооб, Дон Ягон (ok), 12:40 , 03-Фев-20, (158)

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

1. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –7 +/–

Сообщение от Spoofing (?), 29-Янв-20, 09:57

это не уязвимость, повторяю, НЕ УЯЗВИМОСТЬ.
в OpenBSD уязвимостей нет, а все сервисы что вы запускаете сами -- вы запускаете сами, повторяю, ЗАПУСКАЕТЕ САМИ.

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

5. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +11 +/–

Сообщение от Аноним (5), 29-Янв-20, 10:08

Найс аутотренинг

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

30. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +5 +/–

Сообщение от pda (?), 29-Янв-20, 13:43

Это не аутотренинг, это стёб над позицией разработчиков опёнка.

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

31. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +2 +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 13:50

> это стёб над позицией разработчиков опёнка
Демонстрирующий, главным образом, непонимание этой самой позиции.

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

131. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от pda (?), 31-Янв-20, 03:08

Так разъясните. Они любят заострять внимание на "Only two remote holes in the default install, in a heck of a long time!". А что у них включено по умолчанию? ntpd и sshd? Очешуенный сервер. Так и я могу. Напишу сейчас "hello world" и в нём за 100500 лет не найдут ни одной удалённой уязвимости. Только какой в этом толк?
Или я чего-то не понимаю?

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

145. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 31-Янв-20, 14:53

> Так разъясните. Они любят заострять внимание на "Only two remote holes in the default install, in a heck of a long time!". А что у них включено по умолчанию? ntpd и sshd? Очешуенный сервер.
> Так и я могу. Напишу сейчас "hello world" и в нём за 100500 лет не найдут ни одной удалённой уязвимости. Только какой в этом толк?
"Only two remote holes in the default install, in a heck of a long time!" - это слоган проекта, да.
Толк в безопасном default install в том, что это минимальный признак безопасности ОС. Подчёркиваю: не максимальный, а минимальный. Если ОС дырява изкоробки, уже не факт, что важно, что её можно настроить безопасно - наплевательский подход уже продемонстрирован. И дыра может быть использована до того, как ты её пофиксишь правильными настройками. Да, большие дяди собирают (зачастую) свой дистрибутив ОС и кастомизируют настройки под себя, и для них это не актуально. Но этими людьми мир не ограничивается.
Сейчас с этим получше, а раньше многие дистрибутивы linux (и не только) запускали по дефолту всякое, что потом успешно эксплуатировалась, ибо было дыряво или настроено "гениями".
Искренне не понимаю, почему слоган вызывает такое количество волнений. Там прямым текстом написано про default install - не понимаю, как можно обмануться и подумать, что наличие каких либо других дыр разработчики игнорируют. Можно открыть http://www.openbsd.org/errata66.html (чиселку в конце поменять в зависимости от версии) и убедиться, что это не так.
Дисклеймер: я в себе уверен, но всё-таки я высказываю личное мнение, а не офф. позицию разработчиков OpenBSD.

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

156. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от pda (?), 03-Фев-20, 00:42

> Искренне не понимаю, почему слоган вызывает такое количество волнений.
Потому что выглядит как попытка ввести в заблуждение. Люди ожидают от "default install" то, что устанавливается/доступно в поставке от разработчиков. Они гордятся собой - молодцы. Любому пользователю опёнка от этого ни горячо ни холодно. Любая система, повторюсь, ставится для чего-то. Для практической эксплуатации.
Так что для пользователей честный слогон не "всего две уязвимости за дцать лет", а "у нас бывают дырки, как и у всех".

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

157. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 03-Фев-20, 12:39

>> Искренне не понимаю, почему слоган вызывает такое количество волнений.
> Потому что выглядит как попытка ввести в заблуждение.
Для кого? Для тех, кто не умеет читать?
Для тех кто не в курсе про наличие тематических рассылок и приведённой мною в прошлом сообщении ссылки?
Тогда не жалко, что они вводятся в заблуждение, ничего личного.
> Люди ожидают от "default install" то, что устанавливается/доступно в поставке от разработчиков.
Не распарсил. В любом случае, подозреваю, что разные люди ждут разного от default install.
> Любому пользователю опёнка от этого ни горячо ни холодно.
Я предлагаю не высказываться за любого пользователя опёнка.
Мне, например, сильно нравится, что после установки ОС мне нужно включать нужное, а не выключать ненужное и что думать нужно, главным образом, об безопасной настройке стороннего ПО, а не о безопасности и стороннего ПО и ОС.
> Любая система, повторюсь, ставится для чего-то. Для практической эксплуатации.
И что? Оценить "дырявость" всех возможных конфигураций не представляется возможным, это очевидно.
OpenSSH, позволяющий рутовый логин с паролем - это уже почти что приглашение логиниться всем и каждому. Ничто не мешает пользователю это включить (или вообще поднять telnet, без шифрования) - это всё тоже что ли будет говорить о небезопасности ОС?
Слоган ничего не обещает про нестандартные конфигурации, и это логично и последовательно - разработчики ОС предоставляют надёжную (насколько возможно) базу, все что настроил пользователь - зона его ответственности.
> Так что для пользователей честный слогон не "всего две уязвимости за дцать лет", а "у нас бывают дырки, как и у всех".
Это как раз абсолютно бессмысленный слоган, если не сказать "по-настоящему идиотский".
Любой, кто всерьёз сомневался в том, что в OpenBSD бывают уязвимости (как у всех, ага), по большому счёту, не должен париться ни из-за слогана, ни из-за OpenBSD вообще.
ОЧЕВИДНО, что во всём, хоть немного сложном, что сделал человек есть ошибки, дыры и прочие радости жизни. Ну серьёзно, я не верю, что человек, которому небезразлична безопасность ОС, прочитал слоган и "обманулся", а не пошёл и не написал в гугле (или где-то ещё) "openbsd cve" и не открыл первую ссылку.
Никого не волнует, что, например, “Of course it runs NetBSD”, если буквоедствовать и придираться, является ложью (ну правда, какой-нибудь эльбрус в нативном режиме; наверняка есть и менее хардкорные примеры), зато, почему-то, всех волнует что "было только две дыры в стандартной поставке и т.д." != "не было дыр никогда и нигде". Хотя написано всё прямым текстом, в отличие от.
Чудеса, да и только.

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

20. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +4 +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 12:21

> это не уязвимость
> в OpenBSD уязвимостей нет
Разработчики OpenSMTPD говорят, что есть. Но тебе, конечно, виднее.
"Qualys has found a critical vulnerability"
( https://www.mail-archive.com/misc@opensmtpd.org/msg0485... )

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

24. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –6 +/–

Сообщение от XL (?), 29-Янв-20, 13:14

Спасибо ребятам из Qualys, которые на деле показали, что OpenBSD мало чем отличается от других ОС в плане багов и уязвимостей. Искать какой-то мифической супер-пупер безопасности тут бессмысленно. Просто на эту ОС редко кто обращает внимание и мало кто ей пользуется - отсюда и мифы все. Типичные неуловимые Джо. Хотя лично я не удивлён. В наш век маркетинга, рекламы всё это довольно типично.

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

26. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +4 +/–

Сообщение от Аноним (26), 29-Янв-20, 13:27

Конечно, мало чем. Всего лишь реакцией за считанные дни и часы вместо замалчивания в течение месяцев.

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

27. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +9 +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 13:30

> Спасибо ребятам из Qualys, которые на деле показали, что OpenBSD мало чем отличается от других ОС в плане багов и уязвимостей.
Ага, и не в первый раз уже. Как ни найдут дыру в OpenBSD, так сразу "на деле показали".
Я тебе сейчас ещё на деле покажу, постарайся только со стула не упасть: https://www.cvedetails.com/vulnerability-list/vendor_id-97/O...
Не благодари.
> Искать какой-то мифической супер-пупер безопасности тут бессмысленно.
"Мифическую супер-пупер безопасность" ищут только недалёкие дебилы. Защищаются от кого-то/чего-то, а дыры или прочие ошибки есть примерно во всём, что сделал человек.
> В наш век маркетинга, рекламы всё это довольно типично.
В наш век маркетинга и рекламы типично кукарекать не разобравшись в вопросе.
"Безопасность по-умолчанию" - один из принципов производства OpenBSD - это история не про то, что в OpenBSD нет ошибок, а про то, что ошибки есть _ВЕЗДЕ_ и безопасные (читай: параноидально-минималистичные) настройки по-умолчанию - это способ по максимуму предотвратить эксплуатацию дыр, которые в системе по любому есть, просто про них ещё могут не знать.
Например, благодаря тому, что OpenSMTPD по-умолчанию слушает только локалхост, мы имеем local root, а не remote root.
А товарищам из Qualys действительно спасибо, они делом, а не словом помогают делать OpenBSD лучше и безопаснее.

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

28. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +2 +/–

Сообщение от ssh (ok), 29-Янв-20, 13:38

> Я тебе сейчас ещё на деле покажу, постарайся только со стула не упасть: https://www.cvedetails.com/vulnerability-list/vendor_id-97/O...
Ты зачем сразу с козырей то зашел! :)

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

50. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –6 +/–

Сообщение от Zulu (?), 29-Янв-20, 16:24

> Например, благодаря тому, что OpenSMTPD по-умолчанию слушает только локалхост, мы имеем local root, а не remote root.
То есть преимущество OpenBSD над другими системами это настройки по умолчанию? Т.е. OpenBSD это система для тех, кто не в состоянии настроить сервисы так, как ему нужно? Так вы этого слона не продадите.

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

59. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 17:12

> То есть преимущество OpenBSD над другими системами это настройки по умолчанию?
Это один из способов снижения вреда от уязвимостей. Естественно, всех проблем не решающий.
> Т.е. OpenBSD это система для тех, кто не в состоянии настроить сервисы так, как ему нужно?
Не знаю, как на это ответить. Тем более, что это явный троллинг.
Попробуйте обосновать, зачем бы OpenSMTPD по-умолчанию слушать что-то отличное от localhost, когда не получится, возможно, станет понятно, о чём я.

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

69. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Zulu (?), 29-Янв-20, 18:09

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

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

74. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 18:24

>> Попробуйте обосновать, зачем бы OpenSMTPD по-умолчанию слушать что-то отличное от localhost, когда не получится, возможно, станет понятно, о чём я.
> Я стараюсь намекнуть на то, что безопасность надо сравнивать при сопоставимых функциях, без этого получается сравнение теплого с мягким, поэтому фраза "Например, благодаря тому, что OpenSMTPD по-умолчанию слушает только локалхост, мы имеем local root, а не remote root" бессмысленна.
Смотря в каком контексте рассматривать.
Если речь об использовании OpenSMTPD как полноценного почтового сервера, то да, знанием о дефолте можно пренебречь, т.к. всё равно придётся заставить его слушать что-то отличное от localhost.
Если речь об OpenSMTPD как о стандартном локальном smtpd в базовой системе OpenBSD, то это имеет смысл, так как на значительном числе конфигураций у нас будет только local root, что не так фатально опасно, как RCE.

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

89. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от sstj3n (?), 29-Янв-20, 20:37

Зачем тогда в принципе устанавливать программу, которая  в дефолтных настройках бесполезна в 99 случаях из ста? Сравнивать надо именно конфигурации, полезные большинству. Так-то и sshd можно на локалхост повесить в дистре и объявить его "самым безопасТъным". Ну да, безопасно, а толку-то с него?

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

91. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +2 +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 21:05

> Зачем тогда в принципе устанавливать программу, которая  в дефолтных настройках бесполезна в 99 случаях из ста? Сравнивать надо именно конфигурации, полезные большинству. Так-то и sshd можно на локалхост повесить в дистре и объявить его "самым безопасТъным". Ну да, безопасно, а толку-то с него?
*вздыхает*
Ты не знаешь, зачем нужен локальный почтовик в юниксах?
UPD: И да, блин, sshd по-умолчанию вообще выключен. И это тоже абсолютно верный подход по снижению вреда от возможных дыр в sshd. Безусловно, не спасающий тех, кто пользуется sshd. Подсказка: на десктопе, например, многим он не нужен. В том числе тем, кто не полезет разбираться.

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

112. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от sstj3n (?), 30-Янв-20, 10:31

Речь не о том, зачем он там нужен, а о том, насколько он необходим для функционирования системы. Иначе мы докатимся так до какого-нибудь alpine Linux и скажем, что там по умолчанию вообще нет ни хрена => сие есть самая безопасТная система! Прожить, скажем, без отправки сообщений в локальный ящик пользователя из крона какого-нибудь вполне себе можно.
Пример с sshd приведен в контексте массового  использования системы в качестве сервера чего-либо. Понятно, что openbsd пока в этот контекст не вписывается ( да и надо ли ? ). С другой стороны, почему бы тогда не позиционировать опёнка в нише домашних настольных ПК?

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

123. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 30-Янв-20, 13:34

> Речь не о том, зачем он там нужен, а о том, насколько он необходим для функционирования системы.
В стандартной поставке он нужен (рутовые нотификации), далее ты можешь настроить себе всё как хочешь.
> Иначе мы докатимся так до какого-нибудь alpine Linux и скажем, что там по умолчанию вообще нет ни хрена => сие есть самая безопасТная система!
Обрати внимание - никто не считает, что тот факт, что по-умолчанию smtpd слушает только localhost делает ОС "самой безопасной ОС". Ты опровергаешь собственные домыслы.
> Пример с sshd приведен в контексте массового  использования системы в качестве сервера чего-либо.
И к чему он? Речь про адекватность настроек по-умолчанию. А рассматривать всерьёз сервера без ssh или чего-то аналогичного (я хз чего) - просто идиотизм.
> Понятно, что openbsd пока в этот контекст не вписывается
Ты хочешь сказать, что серверов под OpenBSD не бывает?)
> С другой стороны, почему бы тогда не позиционировать опёнка в нише домашних настольных ПК?
OpenBSD система общего назначения.

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

142. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от sstj3n (?), 31-Янв-20, 09:43

Как же туго-то...
Суть примеров: если то, что ты называешь "адекватными настройками", существенно урезает возможность использования core functionality софта, то называть это "адекватными настройками" как-то странновато, и уж тем более говорить о том, что это есть mitigation для проблемы. Переводя пример с sshd в плоскость opensmtpd: нахрена мне  _по_умолчанию_ в системе сервис, предназначенный в том числе для релеинга писем за пределы локалхоста, но которым я не могу воспользоваться без повышения уровня опасности уязвимости ? Класть нотификации в локальный mbox можно более простыми способами, без россказней об "адекватности настроек", а софт просто снести нафиг за ненадобностью, ибо самая безопасный сервис в системе по умолчанию - это потушенный сервис, либо его отсутствие.
Посыл: считать существенное урезание функционала софта через "адекватные настройки" в поставке по умолчанию преимуществом есть некорректность и не более чем маркетинговый ход, поэтому упоминать это как некое преимущество есть глупость

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

146. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 31-Янв-20, 15:50

> Суть примеров: если то, что ты называешь "адекватными настройками", существенно урезает возможность использования core functionality софта, то называть это "адекватными настройками" как-то странновато, и уж тем более говорить о том, что это есть mitigation для проблемы.
Ты или слушаешь в пол уха или не хочешь понимать меня, похоже.
Core functionality урезается не в принципе, а только в поставке по-умолчанию.
Если мы говорим о продукте OpenSMTPD, то да, это практически никак не влияет на его безопасность, потому что первое, что в нём включат - "слушать не только localhost".
Если мы говорим о продукте OpenBSD, то ограниченность OpenSMTPD локалхостом влияет на безопасность продукта. Не все используют OpenBSD исключительно как почтовый сервер, а local root, гораздо лучше, чем remote root. Хотя тоже плохо, да.
> Переводя пример с sshd в плоскость opensmtpd: нахрена мне  _по_умолчанию_ в системе сервис, предназначенный в том числе для релеинга писем за пределы локалхоста, но которым я не могу воспользоваться без повышения уровня опасности уязвимости ?
А что, есть способ поднять на машине сервис, слушаюший/пишущий в сеть, не подняв уровень опасности для сервера? Очевидно, что сервер, слушающий сеть менее безопасен, чем сервер, который этого не делает. Очевидно, что если тебе нужен полноценный почтовый сервер, тебе придётся устанавливать ПО, которое умеет в smtp не только на локалхосте.
> Класть нотификации в локальный mbox можно более простыми способами, без россказней об "адекватности настроек", а софт просто снести нафиг за ненадобностью, ибо самая безопасный сервис в системе по умолчанию - это потушенный сервис, либо его отсутствие.
Ну то есть ты предлагаешь вместо одного потенциально уязвимого сервиса сделать два (или более) потенциально уязвимых сервиса, я всё правильно понял?
Ещё раз: если функциональность нужна, она всё равно будет включена, тем или иным способом. И в её реализации может быть уязвимость.
> Посыл: считать существенное урезание функционала софта через "адекватные настройки" в поставке по умолчанию преимуществом есть некорректность и не более чем маркетинговый ход, поэтому упоминать это как некое преимущество есть глупость
Точно? То есть, если бы OpenSMTPD, например, по-умолчанию позволял бы без какой либо проверки любому внешнему пользователю отправить письмо с любого адреса - ты бы высказывался в таком же духе?
Минималистичные настройки по-умолчанию - это не серебрянная пуля, как и все прочие митигации. Безопасность - это комплексный процесс и каждая отдельно взятая мера - это кусок пазла. Глупо ждать, что настройки по-умолчанию решат все проблемы или отменят найденную уязвимость (типа той, про которую пост). Ещё более глупо - делать из этого вывод, что настройки в стиле "воруй-убивай, можно всё" по-умолчанию могут привести к чему-то хорошему.

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

154. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 01-Фев-20, 03:00

> рутовые нотификации
В смысле письма от всяких демонов на root@$host.
Как мне показалось, формулировка неудачная и требует уточнения.
Как правило рутовая почта - это алиас.

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

113. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Анонимус2 (?), 30-Янв-20, 11:21

Зачем вообще локальному почтовику слушать smtp? Насколько я помню в debian exim вообще не слушает ничего по умолчанию, sendmail(1) работает - и достаточно.

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

122. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Аноним (122), 30-Янв-20, 13:24

> *вздыхает*
> Ты не знаешь, зачем нужен локальный почтовик в юниксах?
И зачем, если локально хватает MTA типа DMA?
man dma
> dma – DragonFly Mail Agent
>  dma is a small Mail Transport Agent (MTA), designed for home and office use.
>  It accepts mails from locally installed Mail User Agents (MUA) and
>  delivers the mails either locally or to a remote destination.

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

124. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Дон Ягон (ok), 30-Янв-20, 13:37

>> *вздыхает*
>> Ты не знаешь, зачем нужен локальный почтовик в юниксах?
> И зачем, если локально хватает MTA типа DMA?
> man dma
DMA - очень хороший вариант, да (и вообще стрекоза мне нравится). В OpenBSD вместо него OpenSMTPD, слушающий только localhost, т.е. урезанный до +/- аналогичного простого функционала.

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

155. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 01-Фев-20, 03:19

> sshd по-умолчанию вообще выключен
Я обманул, инсталлятор спрашивает о том, запускать по дефолту или нет.

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

66. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (66), 29-Янв-20, 18:00

Мы и не продаём "слона".

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

53. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от OpenEcho (?), 29-Янв-20, 16:55

>Просто на эту ОС редко кто обращает внимание и мало кто ей пользуется - отсюда и мифы все.
Т.е. General Motors, JPL не в счет ?

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

61. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 17:22

> Т.е. General Motors, JPL не в счет ?
Можно каких-то пруфов? Не то, чтобы я сомневаюсь или не верю, просто люблю, когда пруфы есть, а сходу ничего не нагуглилось.

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

78. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от OpenEcho (?), 29-Янв-20, 19:30

Информация инсайдерская, поэтому сорри, пруфов не будет, хотите верьте, хотите нет, хотя если интересно, попробуйте
https://enlyft.com/tech/products/openbsd

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

81. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 19:37

> Информация инсайдерская, поэтому сорри, пруфов не будет, хотите верьте, хотите нет
Ничего в моей жизни не изменится от того, поверю я или нет. Также ничего не изменится от того, является ли эта информация правдой или ложью.
Интересен как раз опыт и/или практический пример успешного использования.
А так - да я может быть и верю, а толку то?
ИМХО, нет смысла приводить подобные примеры без каких-либо пруфов. Даже если это правда.

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

82. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от OpenEcho (?), 29-Янв-20, 19:45

>ИМХО, нет смысла приводить подобные примеры без каких-либо пруфов. Даже если это правда.
Полностью согласен, sorry, просто обидно за опенку стало, сорвалось...
Надеюсь линк сверху "немного" подтвердит мои слова...

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

80. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –1 +/–

Сообщение от Аноним (80), 29-Янв-20, 19:34

Разумеется. Это вебмакаки опять тру ветеранам сишникам из BSD баги в код залили. Шелл, юникс и си не при чем.

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

116. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +2 +/–

Сообщение от Michael Shigorin (ok), 30-Янв-20, 12:53

Мсье сейчас, разумеется, расскажет, как от ЛОГИЧЕСКИХ ошибок в АЛГОРИТМЕ страхует какой-нить silverbulletLanguage.  Ну или балабол, как водится.

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

130. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –2 +/–

Сообщение от Аноним (80), 30-Янв-20, 15:37

Простите, Михаил, но тут не какие-то абстрактные логические ошибки. Конкретно этот дефект следует из самой сути философии юникс, тут сошлись три столпа: шелл, си и то, что с целью упрощения код можно писать на о....сь. Этот баг КРАЙНЕ юниксвеен.

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

133. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (-), 31-Янв-20, 06:59

Это какой-то очень специфичный вариант юниксвэя - так странно sh звать прямо хардкодом стремной конструкции в коде сишной проги.
Если в опенке где-то и есть security in mind - то явно не в таком фрагменте кода как зацитирован. Вызывать шелл с юзерскими данными затея заведомо ссыкотная.

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

150. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 31-Янв-20, 17:50

https://www.opennet.ru/openforum/vsluhforumID3/119631.html#147

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

153. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (80), 31-Янв-20, 18:50

Это юниксвей тот самый, изначальный, лазоревый, который worse is better. Простота лучше правильности.

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

83. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Аноним (83), 29-Янв-20, 19:58

+15 – поняли очевидный сарказм
-23 – не поняли

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

132. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (-), 31-Янв-20, 06:57

Э, вот пардон, сервис под "маркой" OpenSMTPD изначально маркетировавшийся как "секурный", код типа

'execle("/bin/sh", "/bin/sh", "-c", mda_command,...'

Как-то вообще совсем не украшает. Это вот это вот - дизайнилось для секурити? Вот прям с командой шеллу формируемой из данных отгруженных пользователей? И, кстати, нафиг эта штука под рутом работает? Объясните наивному - что в его функциональности требует рут?! А то я глупый линуксоид и не догоняю зачем такой программе рут вперся.

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

147. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 31-Янв-20, 17:21

> Э, вот пардон, сервис под "маркой" OpenSMTPD изначально маркетировавшийся как "секурный",
> код типа
>

>  'execle("/bin/sh", "/bin/sh", "-c", mda_command,...'
>

> Как-то вообще совсем не украшает. Это вот это вот - дизайнилось для
> секурити? Вот прям с командой шеллу формируемой из данных отгруженных пользователей?
> И, кстати, нафиг эта штука под рутом работает? Объясните наивному -
> что в его функциональности требует рут?! А то я глупый линуксоид
> и не догоняю зачем такой программе рут вперся.
Qmail:
"When a mail message arrives, qmail-local runs sh -c command in your  home  directory."
( http://manpages.ubuntu.com/manpages/xenial/man8/qmail-comman... )
"args[0] = "/bin/sh"; args[1] = "-c"; args[2] = prog; args[3] = 0;"
( https://github.com/c-rack/qmail/blob/master/qmail-local.c#L263 )
Postfix:
https://github.com/vdukhovni/postfix/blob/master/postfix/src...
https://github.com/vdukhovni/postfix/blob/master/postfix/src...
И postfix, и qmail проектировались с акцентом на безопасность.
Проблема не непосредственно в том, что вызывается sh -c. Мне лично кажется, что хотя бы для рута есть смысл огородить это, но глубоко я в код не погружался и не побожусь, что для такого поведения нет оснований.

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

138. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (-), 31-Янв-20, 07:50

#define BUG FEATURE, мде? :)

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

2. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –11 +/–

Сообщение от A.Stahl (ok), 29-Янв-20, 09:58

Неуловимого Джо таки поймали. И при этом, к его большому огорчению, поймали не случайно, а ловили целенаправленно. Так что ему уже не отвертеться и ему будет очень больно.

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

19. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +8 +/–

Сообщение от антикудах (?), 29-Янв-20, 11:47

https://mobile.twitter.com/OpenSMTPD/status/1222288467046076417
А это он так пытается отвертеться, да? Задолбали ыксперты.

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

4. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (4), 29-Янв-20, 10:02

На странице Goals их сайта первая же строка: "Be as secure as possible."

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

134. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (-), 31-Янв-20, 07:07

Что-то 'execle("/bin/sh", "/bin/sh", "-c", mda_command,...' не выглядит в этом ключе, уж сорри.

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

151. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 31-Янв-20, 17:51

> Что-то 'execle("/bin/sh", "/bin/sh", "-c", mda_command,...' не выглядит в этом ключе, уж сорри.
https://www.opennet.ru/openforum/vsluhforumID3/119631.html#147

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

6. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –2 +/–

Сообщение от Анонимус2 (?), 29-Янв-20, 10:16

>sh -c ""
Вообще я бы за такое выгонял из профессии навсегда, но в секьюрном бсд видимо лучше знают как писать безопасно

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

11. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +3 +/–

Сообщение от Аноним (11), 29-Янв-20, 10:47

Будьте так добры, накидайте ссылочек, как необходимо делать по вашему мнению.

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

13. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +4 +/–

Сообщение от Нононим (?), 29-Янв-20, 10:54

Оне выгонять учились, а не тому как надо делать.

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

22. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –3 +/–

Сообщение от Аноним (22), 29-Янв-20, 12:40

Смотри postfix

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

25. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 13:20

> Смотри postfix
Тот же postfix тоже позволяет запускать команду mda шеллом.
https://github.com/vdukhovni/postfix/blob/master/postfix/src...
https://github.com/vdukhovni/postfix/blob/master/postfix/src...
Да, старается этого избегать, по возможности. Но сам факт - некоторую функциональность логичнее реализовывать именно так, а не писать свой недо-sh.
Проблема не в том, что процесс OpenSMTPD запускает какие-то субкоманды шелом, а в том, что недостаточно хорошо проверяет входные данные.

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

41. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +5 +/–

Сообщение от Ordu (ok), 29-Янв-20, 14:52

> Проблема не в том, что процесс OpenSMTPD запускает какие-то субкоманды шелом, а в том, что недостаточно хорошо проверяет входные данные.
Не совсем. То что он недостаточно хорошо проверяет -- это проблема. Но то, что он запускает субкоманды шеллом -- это тоже проблема. Если ты написал функцию pipe_to_mda(...) то эта функция должна запускать mda и только. Если при специально подобранных аргументах она может запустить не только mda, а ещё и "rm -rf /*", то это проблема. Может быть лишь потенциальная, но проблема.
Безбажного кода не бывает -- все это знают, но мало кто понимает. То, что безбажного кода не бывает означает, что если твоя pipe_to_mda может при специально подобранных аргументах вызвать "rm -rf /*", то тебе не удастся доказать, что твоя программа не запустит "rm -rf /*" ни при каком вводе.
Тут на деле встаёт вопрос ко всему проект OpenBSD: они не могут не знать, что exec на sh -- это штука, без которой сложно обойтись в unix. И они не могут не знать, что эта штука -- постоянный источник дыр в unix'овом софте. Если присмотреться, то корень проблемы в том, что при передаче аргументов через exec эти аргументы приходится кодировать в шелловские строки и чтобы sh потом декодировал их по своим заморочным правилам. То есть, образно говоря, надо собрать строку-скрипт и выполнить на неё eval. execle чуть лучше в этом смысле, чем system, но как показывает даже эта новость -- ненамного. И есть ведь напрашивающийся способ борьбы с этой проблемой: нужно взять и реализовать некое подмножество sh в виде C'шной библиотеки. Чтобы можно было бы написать, например:
sh_c("mail.local", "-f", from, to)
и быть уверенным, что это приведёт к тому, что будет создан процесс mail.local с argv вида {"mail.local", "-f", from, to}.
Можно и с пайпами как-нибудь разрулиться, даже несмотря на убожество C, например:
shellcommand_t base_cmd = sh_cmd("mail.local", "-f", from, to);
shellcommand_t pipe_cmd = sh_pipe_from(command_input, base_cmd);
sh_spawn(pipe_cmd);
Да, из-за отсутствия параметризации типов в C, тут возможно придётся создавать типы чьи размеры будут неизвестны на этапе компиляции, и из-за этого придётся дёргать malloc почём зря, да ещё и оптимизации пойдут лесом, но, во-первых, может если подумать можно сделать всё не настолько плохо, во-вторых, какая разница: надо очень постараться, чтобы это получилось медленнее, чем старт шелла.
Да, тут возможны проблемы с обработкой ошибок -- библиотека внутри будет дёргать много сисколлов, каждый из них может возвращать коды ошибок, и как-то надо эти ошибки прокидывать в код, дёргающий API библиотеки. Там опять же придётся повозиться и отсутствие параметризованных типов нисколько не упрощает эту возню. Но если всё совсем плохо, можно все сисколлы вызывать непосредственно из sh_spawn, и возвращать оттуда структурку описывающую результат, и к ней грядку методов для разгребания этого результата.
Да, такая библиотечка не решит всех проблем. Например, если mail.local при специально подобранных from и to будет вызывать "rm -rf /*", то тут ничего не сделаешь на уровне библиотеки.
Но фишка-то в том, что проблемы экранирования специсимволов шелла прекратят существовать. Потому что экранирование будет не нужно. Одна библиотека устраняет целый класс ошибок, довольно распространённых причём. Почему OpenBSD до сих пор не написала такую библиотеку и не перевела весь свой код на её использование, вместо всех этих system да execle -- мне не ясно. Подозреваю, что это юниксвей головного мозга.

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

44. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 15:13

Для начала, спасибо за развёрнутое сообщение с текстом по существу вопроса.
> Если ты написал функцию pipe_to_mda(...) то эта функция должна запускать mda и только.
Если всё слишком хардкодить, получится прокрустово ложе. Даже postfix, в котором, насколько я вижу, сделано сильно больше, чтобы не запускать sh, даже он в некоторых случаях запускает его.
> Если при специально подобранных аргументах она может запустить не только mda, а ещё и "rm -rf /*", то это проблема. Может быть лишь потенциальная, но проблема.
Безусловно.
> И они не могут не знать, что эта штука -- постоянный источник дыр в unix'овом софте.
Знают. И даже пытаются валидировать входные данные, чтобы предотвратить это. Из-за ошибки в оной валидации проблема и возникла.
> нужно взять и реализовать некое подмножество sh в виде C'шной библиотеки
Я не понимаю, чем валидация данных в отдельной библиотеке лучше, чем в коде самого OpenSMTPD. Как допустить, так и недопустить ошибку можно в обоих случаях. Универсализация?
Скорее всего, программы не являющиеся SMTP-демоном будут хотеть другие данные на вход и набор допустимых символов будет отличаться (и как бы не всецело).
> Но фишка-то в том, что проблемы экранирования специсимволов шелла прекратят существовать.
>  Почему OpenBSD до сих пор не написала такую библиотеку и не перевела весь свой код на её использование
Насколько я могу понимать, никто не написал универсальную библиотеку, решающую проблемы экранирования спецсимволов на все случаи жизни. В любом случае, мне (лично мне) это не кажется очень простой задачей.

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

62. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Ordu (ok), 29-Янв-20, 17:43

> Я не понимаю, чем валидация данных в отдельной библиотеке лучше, чем в коде самого OpenSMTPD.
Во-первых, там не нужна валидация. Нельзя сказать, чтобы совсем не нужна, но сравни:
execle("/usr/libexec/mail.local", "mail.local", "-f", from, to);
и
execle("/bin/sh", "sh", "-c", "/usr/libexec/mail.local", "-f", from, to)
Разница между этими вариантами в том, что во втором последние четыре аргумента читаются шеллом из его argv и _интерпретируются_, прежде чем передаются в mail.local. Это будто мы взяли и чисто по фану на каждый аргумент вызвали некий аналог eval, под названием shell expansion (который с радостью выполнит команду, если её записать в виде $(rm -rf /*) или `rm -rf /*`). Чтобы этого избежать во втором варианте, мы включаем экранирование, чтобы после shell expansion'а, mail.local получил бы именно то, что исходно лежало в переменных from и to, а не что-то иное. Или иными словами: мы знаем, что на from и to будет вызвана функция expand и в mail.local будут переданы аргументы expand(from) и expand(to), но нам надо передать from и to, поэтому мы создаём функцию unexpand, такую что \forall x expand(unexpand(x)) == x, и после этого мы передаём в mail.local значения expand(unexpand(from)) и expand(unexpand(to)).
В первом варианте мы непросредственно прокидываем содержимое from и to в mail.local через егойный argv, нам не нужен unexpand, потому что нет никакого expand. Но мы лишаемся шелловского job control'а, что становится особенно болезненным, если нам надо через пайпы что-то прокидывать в вызываемую команду, или через пайпы же вычитывать вывод вызываемой команды.

Но, как бы там не было, в обоих случае вызываемая программа должна валидировать вход. Как она это делает -- мы не знаем, и это нас не касается. Может быть программа складывает значения в sql базу данных, и поэтому значения from и to надо экранировать по sql-правилам экранирования. Может быть она создаёт файл с именем from, и поэтому ей надо что-то сделать с from, преобразовать в строку которая может быть именем файла. Но это уже проблемы вызываемой программы. (точнее в идеале именно она должна этим заниматься, иногда это невозможно или слишком сложно, но не в том случае, о котором новость).
То есть, валидация нужна, но это не должно быть заботой вызывающего кода. Вызывающий код должен обрабатывать ошибки, а не валидировать вход.

Во-вторых, даже если бы валидация от шелла и нужна была бы, то она была бы нужна в библиотеке, которой пользуются многие. В этой библиотеке были бы баги, но одни на всех. Устранение бага в библиотеке устраняет баги у всех. Ресурсы вложенные в аудит кода, в тестирование кода разными методами будут возвращаться всем проектам. Если мы представим на секундочку модель разработки софта, в которой многие проекты вызывают шелл, и каждый проект вкладывает какое-то количество ресурсов в то, чтобы обезбажить этот вызов шелла, и сравним её с моделью, в которой есть единая библиотека, чей API гарантирует отсутствие багов, баги могут скрываться лишь в реализации, и в обезбаживание этой реализации вкладывается суммарное количество ресурсов, которое в первой модели вкладывалось в обезбаживание частных реализаций, то какой вариант будет безбажнее?
Да, тут есть свои подводные камни: баг, найденный в библиотеке, сделает уязвимыми многие программы. Но system и exec("sh", ...) -- это весьма распространённые штуки в *nix, то есть существует множество людей заинтересованных в том, чтобы делать это максимально надёжно и безопасно, а значит можно вбухать реально много ресурсов в то, чтобы продумать API и вылизать реализацию. Плюс не обязательно внедрять эту библиотеку сразу везде и в продакшн. Можно форкнуть заинтересованные проекты и тащить пару лет форки, крича на всех углах о том, какие у нас безопасные форки, провоцируя других на то, чтобы они доказывали бы нам, насколько глубоко мы ошибаемся. Некоторые доказательства будут сопровождаться эксплоитами, что будет очень полезно нам. Через несколько несовместимых переписываний API мы доберёмся до v1.0, и тогда... Но для этого нужно, чтобы за проектом стояла организация типа OpenBSD, которая давала бы маркетинга и оплачивала бы хотя бы одного квалифицированного программиста на полную занятость.
> Насколько я могу понимать, никто не написал универсальную библиотеку, решающую проблемы экранирования спецсимволов на все случаи жизни.
Я говорю не об универсальной библиотеке, экранирующая спецсимволы, я говорю о /bin/sh в виде подгружаемой библиотеки. В некотором смысле, семантически это sh, но с другим синтаксисом. Этот синтаксис более многословный и неудобный для использования в командной строке, и вообще без компиляции с ним не поработаешь. Зато он оптимизирован на избегание _распространённых_ проблем вызванных ошибками экранирования.

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

86. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 20:04

> Разница между этими вариантами в том, что во втором последние четыре аргумента читаются шеллом из его argv и _интерпретируются_, прежде чем передаются в mail.local. Это будто мы взяли и чисто по фану на каждый аргумент вызвали некий аналог eval, под названием shell expansion (который с радостью выполнит команду, если её записать в виде $(rm -rf /*) или `rm -rf /*`).
Описанная проблема понятна, её разработчики OpenSMTPD пытаются решать списком допустимых символов и эскейпингом. Т.е. вызвать тот же rm таким способом, как ты описал, в конкретном случае не получилось бы.
> Но, как бы там не было, в обоих случае вызываемая программа должна валидировать вход.
> То есть, валидация нужна, но это не должно быть заботой вызывающего кода. Вызывающий код должен обрабатывать ошибки, а не валидировать вход.
Но ведь в данном случае, вызываемая программа и есть /bin/sh. И проблема не в том, что мы передали что-то не то в /usr/libexec/mail.local, а в том, что мы завершили shell-команду символом ";" и выполнили (ошибочно) кусок того, что после ";" с правами локального юзера, которому предназначалось письмо.
> Я говорю не об универсальной библиотеке, экранирующая спецсимволы, я говорю о /bin/sh в виде подгружаемой библиотеки. В некотором смысле, семантически это sh, но с другим синтаксисом. Этот синтаксис более многословный и неудобный для использования в командной строке, и вообще без компиляции с ним не поработаешь. Зато он оптимизирован на избегание _распространённых_ проблем вызванных ошибками экранирования.
Я несколько неверно высказался, что проблема в неверной валидации входных данных. Ну то есть это так, но "[функция] smtp_mailaddr() имеет логическую ошибку, из-за которой в случае передачи пустого домена в email, функция возвращает успешный код проверки, даже если часть адреса до "@" содержит недопустимые символы" - это не то, что можно было бы пофиксить условной libsh.
Я вообще не уверен, что есть серебрянная пуля, защищающая от подобного рода ошибок.
Условная libsh, в зависимости от того, как она будет сделана, может быть и будет решать какие-то типовые проблемы, в то же время, ИМХО, в бОльшей части случаев практичнее просто ответственно подходить к валидации входных данных, а не использовать комплексные решения (unix-way головного мозга, да).

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

102. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Ordu (ok), 30-Янв-20, 00:27

>> Разница между этими вариантами в том, что во втором последние четыре аргумента читаются шеллом из его argv и _интерпретируются_, прежде чем передаются в mail.local. Это будто мы взяли и чисто по фану на каждый аргумент вызвали некий аналог eval, под названием shell expansion (который с радостью выполнит команду, если её записать в виде $(rm -rf /*) или `rm -rf /*`).
> Описанная проблема понятна, её разработчики OpenSMTPD пытаются решать списком допустимых
> символов и эскейпингом. Т.е. вызвать тот же rm таким способом, как
> ты описал, в конкретном случае не получилось бы.
Да, но и тем не менее логическая ошибка в коде экранизации привела к возможности эксплуатации этой ошибки. Никакого запаса прочности. Сколько ещё ненайденных ошибок прячется в коде экранизации? Есть ли быстрый надёжный способ найти все code-path ведущие к этому execle и доказать, что во всех этих случаях экранизация выполняется верно? Где гарантия, что будущие правки кода не создадут кодопути к этому execle, которые нарушат допущения и засунут туда неэкранированные строки?
> Я несколько неверно высказался, что проблема в неверной валидации входных данных. Ну
> то есть это так, но "[функция] smtp_mailaddr() имеет логическую ошибку, из-за
> которой в случае передачи пустого домена в email, функция возвращает успешный
> код проверки, даже если часть адреса до "@" содержит недопустимые символы"
> - это не то, что можно было бы пофиксить условной libsh.
Так уж и не мог бы пофиксить? В случае с условной libsh этот инвалидный почтовый адрес ушёл бы бэкэнду, тот бы либо переслал дальше, либо сообщил о несуществующем адресе. Я не к тому, что ошибку с синтаксически кривым адресом будет более правильным обрабатывать в mda_agent, чем в MTA -- хз, на самом деле: бекенду всё равно нужно проверить валидность, почему бы не свалить эту проверку на него и не париться о ней? -- но, как минимум, при таком раскладе класс опасности ошибки был бы существенно ниже.
> Я вообще не уверен, что есть серебрянная пуля, защищающая от подобного рода
> ошибок.
> Условная libsh, в зависимости от того, как она будет сделана, может быть
> и будет решать какие-то типовые проблемы, в то же время, ИМХО,
> в бОльшей части случаев практичнее просто ответственно подходить к валидации входных
> данных, а не использовать комплексные решения (unix-way головного мозга, да).
Бороться с каждой ошибкой в отдельности -- это хорошо, но выделять классы ошибок и использовать AoE спеллы против них -- это гораздо эффективнее. Да, AoE -- не серебряная пуля, но они высвобождают ресуры под то, чтобы бороться с ошибками, которые нам ещё не удалось прибить AoE оружием. Бывают AoE "спеллы", которые требуют, например, кучу дополнительной памяти, или ещё как-то повышают требования к железу, или вообще сильно не бесплатны. Но здесь "плата" за AoE -- это виртуально однократно вложенные усилия в разработку libsh. Никаких накладных расходов в runtime, более того потенциально могут быть возможности срезать эти накладные расходы в рантайме.

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

129. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 30-Янв-20, 14:38

Сори за долгий ответ, не хотелось отвечать совсем не подумав.
> Есть ли быстрый надёжный способ найти все code-path ведущие к этому execle и доказать, что во всех этих случаях экранизация выполняется верно?
Я такого способа не знаю.
> Где гарантия, что будущие правки кода не создадут кодопути к этому execle, которые нарушат допущения и засунут туда неэкранированные строки?
Гарантий нет.
> Так уж и не мог бы пофиксить? В случае с условной libsh этот инвалидный почтовый адрес ушёл бы бэкэнду, тот бы либо переслал дальше, либо сообщил о несуществующем адресе. Я не к тому, что ошибку с синтаксически кривым адресом будет более правильным обрабатывать в mda_agent, чем в MTA -- хз, на самом деле: бекенду всё равно нужно проверить валидность, почему бы не свалить эту проверку на него и не париться о ней? -- но, как минимум, при таком раскладе класс опасности ошибки был бы существенно ниже.
Всё верно. Но и корректная логика валидации в текущем снизила бы класс опасности ошибки?
> Бороться с каждой ошибкой в отдельности -- это хорошо, но выделять классы ошибок и использовать AoE спеллы против них -- это гораздо эффективнее. Да, AoE -- не серебряная пуля, но они высвобождают ресуры под то, чтобы бороться с ошибками, которые нам ещё не удалось прибить AoE оружием.
> Но здесь "плата" за AoE -- это виртуально однократно вложенные усилия в разработку libsh.
В теории я согласен с тобой. На практике я не уверен, что платой будут однократно вложенные усилия - могу допустить, что чинить ошибки придётся очень долго или бесконечно. Это если речь про условную универсальную libsh.
Но на самом деле, я сегодня с утра задумался о том, почему я вообще завёл про это речь.
Кажется, более адекватно было бы рассматривать не условный libsh, а возможность использовать какой-то dsl или даже условный python.
Но и тут приходится (имхо) выбирать между двумя крайностями:
* Готовый язык (типа python), вероятно, as-is будет слишком мощный и его придётся огораживать, примерно также, как сейчас огораживается shell.
* DSL, который, в теории, можно написать строго под свои задачи, и который может и не содержать лишнего. Если отказаться от универсализации, то могу согласиться, что это может быть и более хорошим вариант, чем текущий.
Универсальный вариант у меня по-прежнему вызывает сомнения, в том плане, что разработка подобного мне кажется долгим и сложным мероприятием, без гарантий достижения желаемых целей.
Может я неправ, да.

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

90. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 20:54

>> Но, как бы там не было, в обоих случае вызываемая программа должна валидировать вход.
>> То есть, валидация нужна, но это не должно быть заботой вызывающего кода. Вызывающий код должен обрабатывать ошибки, а не валидировать вход.
> Но ведь в данном случае, вызываемая программа и есть /bin/sh. И проблема не в том, что мы передали что-то не то в /usr/libexec/mail.local, а в том, что мы завершили shell-команду символом ";" и выполнили (ошибочно) кусок того, что после ";" с правами локального юзера, которому предназначалось письмо.
Ну да, в случае libsh (условного), мы бы вызывали саму программу. Но тогда бы да, были бы проблемы по меньшей мере с пайпами. И не было бы проблем с эскейпингом и т.п.
> Если мы представим на секундочку модель разработки софта, в которой многие проекты вызывают шелл, и каждый проект вкладывает какое-то количество ресурсов в то, чтобы обезбажить этот вызов шелла, и сравним её с моделью, в которой есть единая библиотека, чей API гарантирует отсутствие багов, баги могут скрываться лишь в реализации, и в обезбаживание этой реализации вкладывается суммарное количество ресурсов, которое в первой модели вкладывалось в обезбаживание частных реализаций, то какой вариант будет безбажнее?
Вот честно - не знаю. Решить общую задачу, как правило, сложнее, чем частную. Потому что придётся рассматривать значительно бОльшее количество возможных кейсов (я КО, да).

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

32. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (11), 29-Янв-20, 13:55

Спс

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

109. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (109), 30-Янв-20, 01:14

> Будьте так добры, накидайте ссылочек, как необходимо делать по вашему мнению.
> Смотри postfix
В postfix было так: https://www.exploit-db.com/exploits/34896
Уязвимость в bash CVE-2014-6271. А подход в postfix такой же.
Смотрите тогда уж qmail.

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

114. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Анонимус2 (?), 30-Янв-20, 11:35

Не делать вызов sh программно вообще никогда, не видел пока ни одной программы сложнее hello world где бы это не привело к уязвимостям. В данном случае - вызывать mail.local напрямую, без обёртки в виде шелла.
Если уж администратору сильно захотелось запустить шелл - ему нужно дать возможность вместо mail.local запустить произвольный файл, пусть пишет его на чем угодно - хоть шелл, хоть си, хоть джаваскрипт.

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

135. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (-), 31-Янв-20, 07:11

Во-во. А если какие-то параметры отдать надо - то наверное все-таки не в sh -c, такая конструкция заведомо заявка на залет. Шелл больно уж много всего специально трактует так что кормить его из недоверяемых данных - чего, рута по DHCP все уже забыли, мыло было?

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

7. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Аноним (7), 29-Янв-20, 10:30

Просто нужно запретить создание произвольных процессов. Вместо этого при вызове приложения ему нужно передавать список разрешённых бинарников с их аргументами командной строки. Бинарники вызывать из программы по псевдониму, при этом передача аргументов командной строки запрещена. Весь говнокод отломается, туда ему и дорога. Придётся переписывать все программы на нормальную архитектуру: как разделяемые библиотеки с внешним API.

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

84. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (83), 29-Янв-20, 20:02

SELinux это умеет? Или другое решение?

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

103. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (7), 30-Янв-20, 00:31

Нет, не умеет. Это capability-based security. См. не взлетевший cloudABI.

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

115. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от phaoost (ok), 30-Янв-20, 11:39

SELinux в OpenBSD???

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

136. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (-), 31-Янв-20, 07:14

У них, кстати, pledge есть. Он что, не умеет лимитировать параметры сисколов? Впрочем если юзерь может в sh -c как рут, толку с этого будет довольно маргинально, любой кулхацкер за 10 минут с -c изобразит что-нибудь годное даже так.

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

159. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от исчо_адын_гентушнег (?), 04-Фев-20, 16:22

>SELinux это умеет? Или другое решение?
на селе можно, но для 99%  цЫкурити-админов сильно сложно ( ибо редхад методички в редхад включают только таргет полиси). А так да, отловить exec* сель может, аргументы тоже.
На настоящей RBASC -  как 2 пальца об асфальт, но они все платные

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

15. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +10 +/–

Сообщение от Аноним (15), 29-Янв-20, 10:56

Ага, все-таки можно настраивать сервер через SMTP!
А то все SSH, да SSH...

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

16. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –4 +/–

Сообщение от neAnonim (?), 29-Янв-20, 11:11

Ну блин всегда так делал, а тут понабежали. Повторяю это НЕ БАГ, это фича.

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

37. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (37), 29-Янв-20, 14:42

Именно! АНБ просили "сделать возможнность", им сделали. А тут пришли какие-то анализаторы и нашли сделанное. Ну вот как после этого доверять всяким аудитам? А как же "национальная безопасность"? Она же важнее.

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

17. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +2 +/–

Сообщение от Аноним (17), 29-Янв-20, 11:15

ЫХыххыхы :)

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

18. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –6 +/–

Сообщение от Аноним (18), 29-Янв-20, 11:44

Неуловимый Джо отбегался по прериям...

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

87. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (87), 29-Янв-20, 20:16

И ни меча, ни лат, и лицом в салат до утра - вот и все дела...

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

21. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +3 +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 12:27

Двоякие ощущения. С одной стороны хорошо, что нашли, с другой - похожее уже было, когда ж закончится? И тоже, кстати, Qualys нашли - https://www.opennet.ru/opennews/art.shtml?num=43090
(К разговору о том, что "за openbsd взялись всерьёз". Ага, взялись, ещё в 2015 году).

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

23. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –4 +/–

Сообщение от Аноним (-), 29-Янв-20, 13:09

Самая бестолковая из всех *bsd и этот хайп про безопасность... ОС для фанатиков - вот только эффект Плацебо тут не работает.

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

38. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –1 +/–

Сообщение от Аноним (37), 29-Янв-20, 14:43

Есть ещё NetBSD, которая без хайпа...

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

40. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –2 +/–

Сообщение от Аноним (40), 29-Янв-20, 14:51

> Есть ещё NetBSD, которая без хайпа...
... и без каких-либо заметных достоинств вообще.

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

42. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 14:56

> и без каких-либо заметных достоинств вообще.
Это, конечно же, не так. NetBSD вполне себе достойная ОС.

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

117. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Michael Shigorin (ok), 30-Янв-20, 12:57

Как минимум там есть Чеусов ;-)

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

125. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 30-Янв-20, 13:45

> Как минимум там есть Чеусов ;-)
Мне это мало о чём говорит. Погуглил, нашёл про nih (пакетный менеджер), вспомнил, что когда-то читал про это и ещё что-то. Но и только.
Но, в любом случае, NetBSD  - это хорошо ;)

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

46. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от 11 (?), 29-Янв-20, 16:16

> ... и без каких-либо заметных достоинств вообще.
NetBSD и по безопасности (внезапно, да!?), и по сетевой подсистеме и по многим другим вещам наголову выше деревянной и упоротой OpenBSD. Просто там народ взрослый, опытный, спокойный и скромный. А компашка + Тео - толпа каких-то неврастеников с ЧСВ (не просто же так Тео выперли и команды NetBSD). NetBSD особо не рекламируют себя, тихо, мирно работают в своё удовольствие. То же самое касательно качества кода - поддержка вагона платформ обязывает писать унифицированный, хорошо продуманный код. НетБСД пишет профессура для души, а опенбсд/фрибсд пишут гики вроде Тео или какой-нибудь яндекс.

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

54. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +4 +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 16:55

При всех моих симпатиях к NetBSD (как и к прочим BSD-системам), в комментарии написана чушь.
Начиная от противопоставления NetBSD OpenBSD, заканчивая попытками обосновать высказанное.
> NetBSD и по безопасности (внезапно, да!?), и по сетевой подсистеме и по многим другим вещам наголову выше деревянной и упоротой OpenBSD
А как ты сравниваешь, например, безопасность? По количеству CVE? По количеству интегрированных средств снижения вреда от эксплуатации уязвимостей? По количеству оных, включённых по-умолчанию?
По количеству исследований? Сравниваешь ли всё это с аудиториями проектов?
Честно, я не знаю, что безопаснее, NetBSD или OpenBSD (или какая-то ещё ОС). Факторов, которые нужно учитывать очень много, это тебе не попугаями в бенчмарках меряться.
Но, безусловно, NetBSD уделяет значительное внимание безопасности.
> Просто там народ взрослый, опытный, спокойный и скромный. А компашка + Тео - толпа каких-то неврастеников с ЧСВ (не просто же так Тео выперли и команды NetBSD).
Стесняюсь спросить, а как же ты тогда оцениваешь перенос некоторого кода из OpenBSD в NetBSD? И нет, я даже не про OpenSSH. А, например, про bioctl и pf (уже переписаны). Про tmux. Про systrace, который хоть и был запилен (емнип) Провосом из NetBSD, пилился обеими командами.
Все BSD-системы обмениваются кодом (особенно, когда речь о драйверах) и NetBSD с OpenBSD - не исключения.
Тео "выперли" из NetBSD по административным причинам и отнюдь не все это одобряли. И многие с ним ушли. И "взрослый и опытный народ" и "толпа неврастеников" прекрасно взаимодействуют на пользу друг другу. И вообще не в курсе, что должны враждовать.
> NetBSD особо не рекламируют себя, тихо, мирно работают в своё удовольствие.
Ну да, а баннеры OpenBSD на каждом сайте уже просто прохода не дают. Ну да, а разработчики NetBSD просят, нет, просто умоляют удалять любые упоминания о них в СМИ. И twitter не ведут.
> поддержка вагона платформ обязывает писать унифицированный, хорошо продуманный код
Или держать в коде костыли/поддержку легаси/сложнодиагностируемые баги, говори уж до конца.
Поддержка 100500 платформ не должна быть самоцелью. OpenBSD, например, тоже поддерживает более 10 архитектур в надежде ловить странные ошибки (иначе наличие поддержки того же PA-RISC сложно обосновать - кому он не для тестов может быть нужен?), но когда ресурсов на поддержку чего-либо нет - дропают. Например, недавнее - https://undeadly.org/cgi?action=article;sid=20191003043450. Не то, чтобы это сильно позитивно, но SGI-то уже точно труп...
> НетБСД пишет профессура для души, а опенбсд/фрибсд пишут гики вроде Тео или какой-нибудь яндекс.
Большой дебилизм заниматься подобного рода противопоставлением. И NetBSD и OpenBSD хорошие ОС. Со своими плюсами и минусами.

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

93. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –2 +/–

Сообщение от Аноним (-), 29-Янв-20, 21:12

Опять словоблудие... Ещё себе пару плюсиков поставь... Секта она и есть секта...

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

96. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 21:25

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

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

55. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (55), 29-Янв-20, 17:04

От openssh ты конечно уже отказался?

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

92. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (-), 29-Янв-20, 21:11

> От openssh ты конечно уже отказался?
Отродясь не пользовался.

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

98. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +3 +/–

Сообщение от Аноним (98), 29-Янв-20, 21:33

>> От openssh ты конечно уже отказался?
> Отродясь не пользовался.
дропбер + путти + локалхост онли одмин = твое все?

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

118. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Michael Shigorin (ok), 30-Янв-20, 12:58

Тогда скорее "Далее, далее, далее, ОК"? :]

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

85. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (83), 29-Янв-20, 20:03

Она работает на VAX! И на тостерах!

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

143. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (-), 31-Янв-20, 09:51

> ... и без каких-либо заметных достоинств вообще.
HammerFS? Единственные из BSDшников кто смог хотя-бы попытаться сделать приличную современную файловую систему...

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

148. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 31-Янв-20, 17:24

> HammerFS
HAMMER разрабатывается в DragonflyBSD, Мэттом Диллоном и компанией.
В NetBSD UFS+WAPBL и порт zfs (хз, насколько готовый к проду в сравнении с FreeBSD/ZoL - не тестировал).

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

110. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (-), 30-Янв-20, 01:58

> NetBSD, которая без хайпа...
У NetBSD нет слогана и она оплачивает аудит (http://blog.netbsd.org/tnf/entry/network_security_audit).
У OpenBSD есть слоган и ей проводят аудит бесплатно.
Ну и кто тут лох?

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

29. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +4 +/–

Сообщение от Аноним84701 (ok), 29-Янв-20, 13:43

> в OpenBSD уязвимостей нет
> что OpenBSD мало чем отличается от других ОС
> но в секьюрном бсд
>  ОС для фанатиков - вот только эффект Плацебо
https://packages.debian.org/bullseye/opensmtpd
https://centos.pkgs.org/7/epel-x86_64/opensmtpd-6.0.3p1-5.el...
Хм, я так понимаю, что данная новость создавалась с целью сделать перепись местных "из принципа  прочитал только заголовок и первый абзац, но ценное мнение отпишу"? 🙄
Ну или принципиально не пользующихся тем же OpenSSH.

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

39. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –6 +/–

Сообщение от Аноним (37), 29-Янв-20, 14:49

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

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

43. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +3 +/–

Сообщение от Хороним (?), 29-Янв-20, 14:57

Перепиши openssh на своём любимом яваскрипте и тебе не придётся больше содержать "этих шутов".
Денег сэкономиииишь!

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

33. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –1 +/–

Сообщение от suffix (ok), 29-Янв-20, 14:15

А как все на exim гнали когда полгода назад уязвимость у него выявили !
У всех такое бывает - а пользоваться надо чем удобнее !

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

34. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 14:25

> А как все на exim гнали когда полгода назад уязвимость у него выявили !
Всё-таки есть разница между наличием ошибок в принципе и положенным на безопасность болтом.
Насчёт конкретно OpenSMTPD не могу предметно высказаться - когда мне приходилось настраивать почтовые серваки его ещё просто не было. Но тот же postfix - хороший вариант вместо exim, если его возможностей хватает. Remote root там, емнип, не находили.

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

137. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (-), 31-Янв-20, 07:17

sh -c с параметрами сформированными из юзерских данных так и хочется назвать болтом забитым на безопасность, или курением на бочке с порохом. Сам не понимаю почему.

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

149. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 31-Янв-20, 17:32

> sh -c с параметрами сформированными из юзерских данных так и хочется назвать болтом забитым на безопасность, или курением на бочке с порохом.
Процитирую сам себя:
Qmail:
"When a mail message arrives, qmail-local runs sh -c command in your  home  directory."
( http://manpages.ubuntu.com/manpages/xenial/man8/qmail-comman... )
"args[0] = "/bin/sh"; args[1] = "-c"; args[2] = prog; args[3] = 0;"
( https://github.com/c-rack/qmail/blob/master/qmail-local.c#L263 )
Postfix:
https://github.com/vdukhovni/postfix/blob/master/postfix/src...
https://github.com/vdukhovni/postfix/blob/master/postfix/src...
И postfix, и qmail проектировались с акцентом на безопасность.
> Сам не понимаю почему.
Потому что твоё желание ложное. Проблема не непосредственно в том, что вызывается sh -c. Популярные безопасные почтовые серверы postfix и qmail делают то же самое, и подобных проблем в них не было найдено.
Вызывать из кода стороннюю программу с произвольными аргументами и не создать проблем с безопасностью в любом случае сложно, с sh или без.

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

36. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Аноним (26), 29-Янв-20, 14:32

Так вы посравнивайте, что и в каких количествах находили у exim в тот же период его существования. А если уж в нём и нынче находят эпические уязвимости, то...

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

56. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (55), 29-Янв-20, 17:07

То что?

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

119. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Michael Shigorin (ok), 30-Янв-20, 12:59

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

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

45. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (11), 29-Янв-20, 16:03

Не пойму, что здесь многие уцепились, за BSD или за людей с недостаточным (или наоборот с излишне достаточным ;) опытом в вопросах безопасности. Вон товарисчь Бернштейн, взял да подошел к вопросу безопасности с другой стороны. Результат, как видно на лицо! И не цепляйтесь сразу к словам, результат именно в безопасности.

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

47. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –2 +/–

Сообщение от VeryWideOpenBSD (?), 29-Янв-20, 16:18

Заметил забавную тендецию, что в теме где встречается фэйлы про опенку очень знатно накручиваются минусики, лул. В 2020-м году что-то там накручивать.
Согласен с товарищами выше, что Опенбсд это как неловимые джо. Обращают на них внимание - вагон багов, не обращают - ку-ка-ре-ку мост секурьюр ин зе ворлд, эт лист трайн то би зэ мост секурьюр ин зе ворлд ку-ка-ре-ку. Мне то лично всё равно, по барабану на опенку, но поведение сектантов умиляет. Чем бы дитя не тешилось.

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

49. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –2 +/–

Сообщение от Аноним (-), 29-Янв-20, 16:23

Советую последить за Доном Ягоном, если он в новости, то обычно минусы встречаются даже в низу ленты комментариев. Хотя обычно на опеннете такое весьма редко. Обычно плюсуют/минусуют в топе ленты.
> сектантов
Сектанты есть сектанты. Они везде такие. Будь то пользователи OpenBSD или марксисты, либералы, социал-дарвинисты и прочие представители секс-меньшинств тп. Это уже чисто религиозный аспект. Логику тут искать бесполезно.

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

52. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Аноним (-), 29-Янв-20, 16:35

> Советую последить за Доном Ягоном, если он в новости, то обычно минусы
> встречаются даже в низу ленты комментариев. Хотя обычно на опеннете такое
> весьма редко. Обычно плюсуют/минусуют в топе ленты.
Советую проследить за анонимами! Если они в новости, то минусы встречаются везде!
Причем, с бессмысленной и беспощадной накруткой, как недавно:
https://www.opennet.ru/openforum/vsluhforumID3/119501.html#41 (упомянули о том, что Distrowatch вообще-то на фре и получили коммент "вы все врети и вообще это не нужный сайт" и -22 )

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

60. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +3 +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 17:18

> Советую последить за Доном Ягоном, если он в новости, то обычно минусы встречаются даже в низу ленты комментариев.
Естественно я ставлю минусы тем, кто пишет херню (с моей точки зрения; в мере понимания вопроса стараюсь свою позицию обосновывать или хотя бы понятно высказывать).
Не принимай мои минусы (не знаю, правда, как отличить их от чужих) близко к сердцу, я всего лишь анонимный опеннетчик.

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

97. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –2 +/–

Сообщение от lorovec (?), 29-Янв-20, 21:26

> Естественно я ставлю минусы тем, кто пишет херню
Так-то пока херню тут пишешь только ты. Причём огромные простыни потока сознания. Агрясь на любые комменты, даже вполне безобидные.
> стараюсь свою позицию
Ну типа речь не о тебе вообще. Причём тут ты? Речь о том, что опёнок довольно среднестатистическая ос с точки зрения безопасности. Фанатики этот факт принять к сведению всё никак не могут.
> Не принимай мои минусы (не знаю, правда, как отличить их от чужих) близко к сердцу
Вообще всё это. Плюсы, упорные минусы другим. Даже дети такой херней не будут маяться. Чисто религиозная история. Хочешь плюсиков? Ну держи плюсик.

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

100. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 21:49

>> Естественно я ставлю минусы тем, кто пишет херню
> Так-то пока херню тут пишешь только ты. Причём огромные простыни потока сознания. Агрясь на любые комменты, даже вполне безобидные.
Ну раз ты так сказал...
>> стараюсь свою позицию
> Ну типа речь не о тебе вообще. Причём тут ты? Речь о том, что опёнок довольно среднестатистическая ос с точки зрения безопасности. Фанатики этот факт принять к сведению всё никак не могут.
Даже если так, то не по той причине, что там нашли (о, Боже, Боже) дыру.
Дыры есть везде. То, что разработчики ужесточают настройки по-умолчанию и пытаются внедрять проактивные способы защиты от эксплуатации уязвимостей свидетельствует о том, что они понимают, что писать код без ошибок они не умеют, хотя и стараются.
Выводы позволю сделать прочитавшему сие самостоятельно.
>> Не принимай мои минусы (не знаю, правда, как отличить их от чужих) близко к сердцу
> Вообще всё это. Плюсы, упорные минусы другим. Даже дети такой херней не будут маяться. Чисто религиозная история. Хочешь плюсиков? Ну держи плюсик.
Даже не знаю, что на это ответить. Пожалуй, скажу "спасибо".
Спасибо!

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

104. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Аноним (26), 30-Янв-20, 01:09

Это я, ленивый Перерезус (лень логиниться), пока ещё агрюсь. И ловлю кучу минусов от User294 и ему подобных гениев, которым в принципе неправильно всё, чем они сами не пользуются. А вот у Дона Ягона лично я как раз учусь выдержке. И вам советую.

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

120. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Michael Shigorin (ok), 30-Янв-20, 13:03

Пора перебарывать лень; привет :)
А на User294 не обижайся, его я покусал, когда меня инфраоранжевоглазики типа never@ задолбали вот вообще совсем, а из вменяемых разве что netch@ и Кабаев попались.  Думаю, пример конструктивных людей говорит сам за себя (и в каждом сообществе важна именно их доля).

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

140. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –1 +/–

Сообщение от Аноним (-), 31-Янв-20, 08:33

Меня одно время тоже задолбали BSDшники вопящие в всех ветках про линух. И вот тут им на самом деле надо жаловаться на самих себя прежде всего - потому что изначально агрессия перла от этих господ. Особенно от фряшников. Начиная с эпохи раннего становления пингвина - попадались весьма неадекватные артефакты.

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

127. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 30-Янв-20, 13:59

Спасибо на добром слове, коли не шутите.

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

139. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (-), 31-Янв-20, 08:31

> И ловлю кучу минусов от User294 и ему подобных гениев,
Перерезус, просто для сведений...
1) Я технически не могу ставить минусы: JS тут наглухо зарублен. Так что честное слово, это не я.
2) В последнее время если я что-то поливаю то стараюсь аргументировать. Или если это не получается - стараюсь воздерживаться от поливания, ибо антипаттерн.
3) Меня на опеннете не было этак с год, ибо отвисание на опеннете учит плохому и жрет время которое можно потратить сильно полезнее.
4) Я таки распознаю право других индивидов хоть йайцы к мостовой прибивать покуда это не создает крупных проблем другим.
А учиться выдержке лучше всего у Кроа-Хартмана. Если конкретно в контексте BSD - можно посмотреть как он невероятно политкорректно завернул кого-то из BSD, сказав что-то типа того что мол, у вас дескть, тоже неплохие системы, но мне кажется что по моему мнению мы как команда можем и еще лучше, дескать, поэтому мне так и сяк нравится линух. И наверное цивилизованные дискуссии взрослых людей должны быть ближе к какому-то такому формату, а не...

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

48. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –1 +/–

Сообщение от pin (??), 29-Янв-20, 16:22

> вызове агента доставки (MDA) при помощи команды 'execle("/bin/sh", "/bin/sh"
🤦🤦🤦 21й век, а openBSD разрабы еще в 20м.

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

58. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (55), 29-Янв-20, 17:10

Ага, в 21 веке shell же отменили, на новый год президент как раз выступал с этим заявлением.

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

75. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от pin (??), 29-Янв-20, 18:48

Ну да, писать на C и дергать из него shell. Месье знает толк.

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

105. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (26), 30-Янв-20, 01:10

Действительно, когда уже execve() сделают deprecated?

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

141. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (-), 31-Янв-20, 08:35

Execve с параметрами из юзерского ввода вообще стремноватая затея, а когда там к тому же sh -c - это примерно как гранатой в футбол играть, с аргументом "но мы же проверили, чека на месте". А оказалось - все-равно может сдетонировать.

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

152. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 31-Янв-20, 17:52

https://www.opennet.ru/openforum/vsluhforumID3/119631.html#147

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

51. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." –2 +/–

Сообщение от Iron_ (?), 29-Янв-20, 16:29

Почитал тему. К чему эти бессмысленные простыни текста от юзеров опёнка? Какие-то козыри, какие-то ссылки. Что за детский сад? С таким кодом разрабы OpenBSD знатно опозорились. Примитивизм ошибок + убогое качество кода.

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

57. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Аноним (55), 29-Янв-20, 17:09

А вы, простите, кто, что бы оценки раздавать качеству кода?

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

64. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 29-Янв-20, 17:46

> К чему эти бессмысленные простыни текста от юзеров опёнка?
А в чём смысл этих срывов покровов про безопасность OpenBSD почти в каждой теме про оную? А в темах про уязвимости оной - так точно в каждой. И ладно бы что-то по делу писали, так ведь поток откровенной тупни.
Остальное комментировать не буду, по остальным моим комментариям в этой теме и так уже должно быть всё понятно.

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

106. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Аноним (26), 30-Янв-20, 01:11

А сколько уязвимостей мсье нашёл в чужом коде, чтобы так авторитетно говорить, можно поинтересоваться? Просто интересно.

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

63. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (63), 29-Янв-20, 17:44

Эй фряшники как победить? trueos aks freebsd 13
checking whether gmake sets $(MAKE)... yes
checking for gcc... gcc9
checking whether the C compiler works... no
configure: error: in `/usr/ports/emulators/wine-devel/work/wine-5.0-rc6':
configure: error: C compiler cannot create executables

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

67. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от анонн (ok), 29-Янв-20, 18:04

> Эй фряшники как победить? trueos aks freebsd 13
Что там "aka"-то? И почему не в более подходящей, соседней новости о MPV (там есть подветка обсуждения аниме)
> checking whether gmake sets $(MAKE)... yes
> checking for gcc... gcc9
> checking whether the C compiler works... no
> configure: error: in `/usr/ports/emulators/wine-devel/work/wine-5.0-rc6':
> configure: error: C compiler cannot create executables
например, проверить на noexec-mount FS для WRKDIRPREFIX портов?
Потом - обосновать религиозные заморочки, не позволяющие установить вайн пакетом из репы?

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

76. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (76), 29-Янв-20, 19:00

Что за дичь, кто вайном из репы пользуется? Там такое-то шерето в коде по дефолту…

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

77. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от анонн (ok), 29-Янв-20, 19:26

> Что за дичь, кто вайном из репы пользуется? Там такое-то шерето в коде по дефолту…
И шерето магически исчезнет, если собрать самому из портов?

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

94. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (76), 29-Янв-20, 21:19

>> Что за дичь, кто вайном из репы пользуется? Там такое-то шерето в коде по дефолту…
> И шерето магически исчезнет, если собрать самому из портов?
Нужно немножко поправить "юзы", тогда исчезнет. Большая часть потенциально уязвимых фич никогда никакому софту не нужна. Совершенно.

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

65. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (63), 29-Янв-20, 17:48

===>  Configuring for wine-devel-5.0.r6,1
configure: loading site script /usr/ports/Templates/config.site
checking build system type... amd64-portbld-freebsd13.0
checking host system type... amd64-portbld-freebsd13.0
checking whether gmake sets $(MAKE)... yes
checking for gcc... gcc9
checking whether the C compiler works... no
configure: error: in `/usr/ports/emulators/wine-devel/work/wine-5.0-rc6':
configure: error: C compiler cannot create executables

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

71. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +2 +/–

Сообщение от Аноним (71), 29-Янв-20, 18:10

У вас компилятор бракованый, видимо пиратская версия

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

121. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Michael Shigorin (ok), 30-Янв-20, 13:04

См. config.log, но лучше сразу ставьте минт.

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

68. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (63), 29-Янв-20, 18:08

тут про bsd, права кругом дефолтные и версию wine хочу новее.

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

107. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Аноним (26), 30-Янв-20, 01:13

Как пропатчить KDE2 тогда уж спрашивайте.

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

70. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (63), 29-Янв-20, 18:10

>проверить на noexec-mount FS как
это сделать?

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

79. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от анонн (ok), 29-Янв-20, 19:31

>>проверить на noexec-mount FS как
> это сделать?
посмотреть в вывод mount?

mount
...
tmpfs on /tmp (tmpfs, local, noexec, nosuid)
tmpfs on /tmp-wrk (tmpfs, local, nosuid)
/dev/gpt/cache on /cache (ufs, local, noatime, soft-updates)

проверить права доступа к дефолтному сборочному диру WRKDIRPREFIX:

make -V WRKDIRPREFIX
/fooba

по умолчанию это /usr/ports
или прописать сборочный дир самому:
echo WRKDIRPREFIX=/tmp-my-wrkdir >> /etc/make.conf
так же, желательно писать ответ переходом по ссылке "ответить" для отображения того в виде дерева и уведомлений учавствующих об ответе.

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

99. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (63), 29-Янв-20, 21:36

с расстройства не сделал ответом. log (

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

72. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (63), 29-Янв-20, 18:14

fstab
# Device                Mountpoint              FStype          Options Dump Pass
/dev/label/swap0.eli    none            swap    sw      0       0
zfs (

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

73. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (63), 29-Янв-20, 18:15

>У вас компилятор бракованый, видимо пиратская версия понятно bsd не моё(( спасибо всем

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

108. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +1 +/–

Сообщение от Аноним (26), 30-Янв-20, 01:14

Не ваше. Вы не умеете в домашнюю работу — вы идёте лесом.

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

88. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от DAV (?), 29-Янв-20, 20:24

Все хором проигнорировали фразу "в соответствии с требованиями RFC 5322".
Отдельно стоящий я -- могу плевать на RFC при настройке почтовика, а вот мантейнер не может...
И про использование.
Видел в хедерах Сбера строку с OpenSmtpd.

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

95. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (63), 29-Янв-20, 21:19

пиратская всё таки
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:4655: $? = 0
configure:4644: gcc9 -v >&5
Using built-in specs.
COLLECT_GCC=gcc9
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/lto-wrapper
Target: x86_64-portbld-freebsd13.0
Configured with: /wrkdirs/usr/ports/lang/gcc9/work/gcc-9.2.0/configure --enable-multilib --with-build-config=bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc9 --libexecdir=/usr/local/libexec/gcc9 --program-suffix=9 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-in>
Thread model: posix
gcc version 9.2.0 (FreeBSD Ports Collection)
configure:4655: $? = 0
configure:4644: gcc9 -V >&5
gcc9: error: unrecognized command line option '-V'
gcc9: fatal error: no input files
compilation terminated.
configure:4655: $? = 1
configure:4644: gcc9 -qversion >&5
gcc9: error: unrecognized command line option '-qversion'; did you mean '--version'?
gcc9: fatal error: no input files
compilation terminated.
configure:4655: $? = 1
configure:4675: checking whether the C compiler works
configure:4697: gcc9 -O2 -pipe  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9 -isystem /usr/local/include -fno-strict-aliasing  -isystem /usr/local/include  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc9 -L/usr/local/lib/gcc9  conftest.c -L/usr/local/lib >&5
/usr/local/bin/ld: cannot find /usr/lib/libc_nonshared.a
/usr/local/bin/ld: cannot find /usr/lib/libssp_nonshared.a
collect2: error: ld returned 1 exit status
configure:4701: $? = 1
configure:4739: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "Wine"
| #define PACKAGE_TARNAME "wine"
| #define PACKAGE_VERSION "5.0-rc6"
| #define PACKAGE_STRING "Wine 5.0-rc6"
| #define PACKAGE_BUGREPORT "wine-devel@winehq.org"
| #define PACKAGE_URL "https://www.winehq.org"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:4744: error: in `/var/tmp/usr/ports/emulators/wine-devel/work/wine-5.0-rc6':
configure:4747: error: C compiler cannot create executables
See `config.log' for more details

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

101. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от анонн (ok), 29-Янв-20, 22:02

>/usr/local/bin/ld: cannot find /usr/lib/libc_nonshared.a
>/usr/local/bin/ld: cannot find /usr/lib/libssp_nonshared.a
>collect2: error: ld returned 1 exit status
>configure:4701: $? = 1
>configure:4739: result: no
> configure: failed program was:
Чей-то тут не то:

uname -rs
FreeBSD 12.1-STABLE
% locate libc_nonshared
/usr/lib/libc_nonshared.a
/usr/lib32/libc_nonshared.a
% locate libssp_nonshared
/usr/lib/libssp_nonshared.a
/usr/lib32/libssp_nonshared.a
/usr/local/lib/gcc/mingw32/4.8.1/libssp_nonshared.a
/usr/local/lib/gcc5/libssp_nonshared.a
/usr/local/lib/gcc7/libssp_nonshared.a
/usr/local/lib/gcc8/libssp_nonshared.a
/usr/local/lib/gcc9/libssp_nonshared.a
/usr/local/lib32/gcc8/libssp_nonshared.a
/usr/local/lib32/gcc9/libssp_nonshared.a

Обе либы, кстати, входят в "базу" https://download.freebsd.org/ftp/releases/amd64/12.1-RELEASE...
так что бросайте уже эту Vasyano-Zver-Edition, ну или не удивляйтесь глюкам при попытке использовать не только как запускалку браузера или файлохранилище.

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

126. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 30-Янв-20, 13:55

> /usr/local/bin/ld: cannot find /usr/lib/libc_nonshared.a
> /usr/local/bin/ld: cannot find /usr/lib/libssp_nonshared.a
Подозреваю, что вы намудрили с опциями сборки (gcc9 как бы намекает).
Возможно, от процитированного поможет редактирование /usr/lib/libc.so, но
1) Если точно не понятно, что вы делаете, лучше ничего не делайте, а не то доломаете всё.
2) Это не самое изящное и бескостыльное решение
3) Я довольно давно не играл в игрули с FreeBSD и, возможно, безбожно вру. Проверьте написанное мной, прежде чем что-то делать.

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

111. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (111), 30-Янв-20, 06:57

https://download.freebsd.org/ftp/snapshots/amd64/13.0-CURRENT/
отсюда взял базу, распаковал и скопировал /usr/lib, теперь все норм. Спасибо за идею!
Буду грызть ее зубами, потому что она хорошая ))))

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

144. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Аноним (144), 31-Янв-20, 13:23

Доломал и фряху поставил, но как собрать wine5 с поддержкой в том числе и 32бит для новых игр или хотябы новую версию пусть только и 32бит, а то там 4.0 i386-wine-devel?

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

158. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..." +/–

Сообщение от Дон Ягон (ok), 03-Фев-20, 12:40

Разработчик OpenSMTPD опубликовал разбор ситуации с уязвимостью и некоторые соображения по предотвращению подобного в будущем: https://poolp.org/posts/2020-01-30/opensmtpd-advisory-dissected/

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	–7 +/–
Сообщение от Spoofing (?), 29-Янв-20, 09:57
это не уязвимость, повторяю, НЕ УЯЗВИМОСТЬ. в OpenBSD уязвимостей нет, а все сервисы что вы запускаете сами -- вы запускаете сами, повторяю, ЗАПУСКАЕТЕ САМИ.
Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+11 +/–
	Сообщение от Аноним (5), 29-Янв-20, 10:08
	Найс аутотренинг
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+5 +/–
	Сообщение от pda (?), 29-Янв-20, 13:43
	Это не аутотренинг, это стёб над позицией разработчиков опёнка.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+2 +/–
	Сообщение от Дон Ягон (ok), 29-Янв-20, 13:50
	> это стёб над позицией разработчиков опёнка Демонстрирующий, главным образом, непонимание этой самой позиции.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	131. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от pda (?), 31-Янв-20, 03:08
	Так разъясните. Они любят заострять внимание на "Only two remote holes in the default install, in a heck of a long time!". А что у них включено по умолчанию? ntpd и sshd? Очешуенный сервер. Так и я могу. Напишу сейчас "hello world" и в нём за 100500 лет не найдут ни одной удалённой уязвимости. Только какой в этом толк? Или я чего-то не понимаю?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	145. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от Дон Ягон (ok), 31-Янв-20, 14:53
	> Так разъясните. Они любят заострять внимание на "Only two remote holes in the default install, in a heck of a long time!". А что у них включено по умолчанию? ntpd и sshd? Очешуенный сервер. > Так и я могу. Напишу сейчас "hello world" и в нём за 100500 лет не найдут ни одной удалённой уязвимости. Только какой в этом толк? "Only two remote holes in the default install, in a heck of a long time!" - это слоган проекта, да. Толк в безопасном default install в том, что это минимальный признак безопасности ОС. Подчёркиваю: не максимальный, а минимальный. Если ОС дырява изкоробки, уже не факт, что важно, что её можно настроить безопасно - наплевательский подход уже продемонстрирован. И дыра может быть использована до того, как ты её пофиксишь правильными настройками. Да, большие дяди собирают (зачастую) свой дистрибутив ОС и кастомизируют настройки под себя, и для них это не актуально. Но этими людьми мир не ограничивается. Сейчас с этим получше, а раньше многие дистрибутивы linux (и не только) запускали по дефолту всякое, что потом успешно эксплуатировалась, ибо было дыряво или настроено "гениями". Искренне не понимаю, почему слоган вызывает такое количество волнений. Там прямым текстом написано про default install - не понимаю, как можно обмануться и подумать, что наличие каких либо других дыр разработчики игнорируют. Можно открыть http://www.openbsd.org/errata66.html (чиселку в конце поменять в зависимости от версии) и убедиться, что это не так. Дисклеймер: я в себе уверен, но всё-таки я высказываю личное мнение, а не офф. позицию разработчиков OpenBSD.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	156. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от pda (?), 03-Фев-20, 00:42
	> Искренне не понимаю, почему слоган вызывает такое количество волнений. Потому что выглядит как попытка ввести в заблуждение. Люди ожидают от "default install" то, что устанавливается/доступно в поставке от разработчиков. Они гордятся собой - молодцы. Любому пользователю опёнка от этого ни горячо ни холодно. Любая система, повторюсь, ставится для чего-то. Для практической эксплуатации. Так что для пользователей честный слогон не "всего две уязвимости за дцать лет", а "у нас бывают дырки, как и у всех".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	157. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от Дон Ягон (ok), 03-Фев-20, 12:39
	>> Искренне не понимаю, почему слоган вызывает такое количество волнений. > Потому что выглядит как попытка ввести в заблуждение. Для кого? Для тех, кто не умеет читать? Для тех кто не в курсе про наличие тематических рассылок и приведённой мною в прошлом сообщении ссылки? Тогда не жалко, что они вводятся в заблуждение, ничего личного. > Люди ожидают от "default install" то, что устанавливается/доступно в поставке от разработчиков. Не распарсил. В любом случае, подозреваю, что разные люди ждут разного от default install. > Любому пользователю опёнка от этого ни горячо ни холодно. Я предлагаю не высказываться за любого пользователя опёнка. Мне, например, сильно нравится, что после установки ОС мне нужно включать нужное, а не выключать ненужное и что думать нужно, главным образом, об безопасной настройке стороннего ПО, а не о безопасности и стороннего ПО и ОС. > Любая система, повторюсь, ставится для чего-то. Для практической эксплуатации. И что? Оценить "дырявость" всех возможных конфигураций не представляется возможным, это очевидно. OpenSSH, позволяющий рутовый логин с паролем - это уже почти что приглашение логиниться всем и каждому. Ничто не мешает пользователю это включить (или вообще поднять telnet, без шифрования) - это всё тоже что ли будет говорить о небезопасности ОС? Слоган ничего не обещает про нестандартные конфигурации, и это логично и последовательно - разработчики ОС предоставляют надёжную (насколько возможно) базу, все что настроил пользователь - зона его ответственности. > Так что для пользователей честный слогон не "всего две уязвимости за дцать лет", а "у нас бывают дырки, как и у всех". Это как раз абсолютно бессмысленный слоган, если не сказать "по-настоящему идиотский". Любой, кто всерьёз сомневался в том, что в OpenBSD бывают уязвимости (как у всех, ага), по большому счёту, не должен париться ни из-за слогана, ни из-за OpenBSD вообще. ОЧЕВИДНО, что во всём, хоть немного сложном, что сделал человек есть ошибки, дыры и прочие радости жизни. Ну серьёзно, я не верю, что человек, которому небезразлична безопасность ОС, прочитал слоган и "обманулся", а не пошёл и не написал в гугле (или где-то ещё) "openbsd cve" и не открыл первую ссылку. Никого не волнует, что, например, “Of course it runs NetBSD”, если буквоедствовать и придираться, является ложью (ну правда, какой-нибудь эльбрус в нативном режиме; наверняка есть и менее хардкорные примеры), зато, почему-то, всех волнует что "было только две дыры в стандартной поставке и т.д." != "не было дыр никогда и нигде". Хотя написано всё прямым текстом, в отличие от. Чудеса, да и только.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+4 +/–
	Сообщение от Дон Ягон (ok), 29-Янв-20, 12:21
	> это не уязвимость > в OpenBSD уязвимостей нет Разработчики OpenSMTPD говорят, что есть. Но тебе, конечно, виднее. "Qualys has found a critical vulnerability" ( https://www.mail-archive.com/misc@opensmtpd.org/msg0485... )
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	24. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	–6 +/–
	Сообщение от XL (?), 29-Янв-20, 13:14
	Спасибо ребятам из Qualys, которые на деле показали, что OpenBSD мало чем отличается от других ОС в плане багов и уязвимостей. Искать какой-то мифической супер-пупер безопасности тут бессмысленно. Просто на эту ОС редко кто обращает внимание и мало кто ей пользуется - отсюда и мифы все. Типичные неуловимые Джо. Хотя лично я не удивлён. В наш век маркетинга, рекламы всё это довольно типично.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+4 +/–
	Сообщение от Аноним (26), 29-Янв-20, 13:27
	Конечно, мало чем. Всего лишь реакцией за считанные дни и часы вместо замалчивания в течение месяцев.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+9 +/–
	Сообщение от Дон Ягон (ok), 29-Янв-20, 13:30
	> Спасибо ребятам из Qualys, которые на деле показали, что OpenBSD мало чем отличается от других ОС в плане багов и уязвимостей. Ага, и не в первый раз уже. Как ни найдут дыру в OpenBSD, так сразу "на деле показали". Я тебе сейчас ещё на деле покажу, постарайся только со стула не упасть: https://www.cvedetails.com/vulnerability-list/vendor_id-97/O... Не благодари. > Искать какой-то мифической супер-пупер безопасности тут бессмысленно. "Мифическую супер-пупер безопасность" ищут только недалёкие дебилы. Защищаются от кого-то/чего-то, а дыры или прочие ошибки есть примерно во всём, что сделал человек. > В наш век маркетинга, рекламы всё это довольно типично. В наш век маркетинга и рекламы типично кукарекать не разобравшись в вопросе. "Безопасность по-умолчанию" - один из принципов производства OpenBSD - это история не про то, что в OpenBSD нет ошибок, а про то, что ошибки есть _ВЕЗДЕ_ и безопасные (читай: параноидально-минималистичные) настройки по-умолчанию - это способ по максимуму предотвратить эксплуатацию дыр, которые в системе по любому есть, просто про них ещё могут не знать. Например, благодаря тому, что OpenSMTPD по-умолчанию слушает только локалхост, мы имеем local root, а не remote root. А товарищам из Qualys действительно спасибо, они делом, а не словом помогают делать OpenBSD лучше и безопаснее.
	Ответить \| Правка \| К родителю #24 \| Наверх \| Cообщить модератору


	28. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+2 +/–
	Сообщение от ssh (ok), 29-Янв-20, 13:38
	> Я тебе сейчас ещё на деле покажу, постарайся только со стула не упасть: https://www.cvedetails.com/vulnerability-list/vendor_id-97/O... Ты зачем сразу с козырей то зашел! :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	–6 +/–
	Сообщение от Zulu (?), 29-Янв-20, 16:24
	> Например, благодаря тому, что OpenSMTPD по-умолчанию слушает только локалхост, мы имеем local root, а не remote root. То есть преимущество OpenBSD над другими системами это настройки по умолчанию? Т.е. OpenBSD это система для тех, кто не в состоянии настроить сервисы так, как ему нужно? Так вы этого слона не продадите.
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	59. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+1 +/–
	Сообщение от Дон Ягон (ok), 29-Янв-20, 17:12
	> То есть преимущество OpenBSD над другими системами это настройки по умолчанию? Это один из способов снижения вреда от уязвимостей. Естественно, всех проблем не решающий. > Т.е. OpenBSD это система для тех, кто не в состоянии настроить сервисы так, как ему нужно? Не знаю, как на это ответить. Тем более, что это явный троллинг. Попробуйте обосновать, зачем бы OpenSMTPD по-умолчанию слушать что-то отличное от localhost, когда не получится, возможно, станет понятно, о чём я.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от Zulu (?), 29-Янв-20, 18:09
	> Попробуйте обосновать, зачем бы OpenSMTPD по-умолчанию слушать что-то отличное от localhost, когда не получится, возможно, станет понятно, о чём я. Я стараюсь намекнуть на то, что безопасность надо сравнивать при сопоставимых функциях, без этого получается сравнение теплого с мягким, поэтому фраза "Например, благодаря тому, что OpenSMTPD по-умолчанию слушает только локалхост, мы имеем local root, а не remote root" бессмысленна.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от Дон Ягон (ok), 29-Янв-20, 18:24
	>> Попробуйте обосновать, зачем бы OpenSMTPD по-умолчанию слушать что-то отличное от localhost, когда не получится, возможно, станет понятно, о чём я. > Я стараюсь намекнуть на то, что безопасность надо сравнивать при сопоставимых функциях, без этого получается сравнение теплого с мягким, поэтому фраза "Например, благодаря тому, что OpenSMTPD по-умолчанию слушает только локалхост, мы имеем local root, а не remote root" бессмысленна. Смотря в каком контексте рассматривать. Если речь об использовании OpenSMTPD как полноценного почтового сервера, то да, знанием о дефолте можно пренебречь, т.к. всё равно придётся заставить его слушать что-то отличное от localhost. Если речь об OpenSMTPD как о стандартном локальном smtpd в базовой системе OpenBSD, то это имеет смысл, так как на значительном числе конфигураций у нас будет только local root, что не так фатально опасно, как RCE.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	89. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+1 +/–
	Сообщение от sstj3n (?), 29-Янв-20, 20:37
	Зачем тогда в принципе устанавливать программу, которая в дефолтных настройках бесполезна в 99 случаях из ста? Сравнивать надо именно конфигурации, полезные большинству. Так-то и sshd можно на локалхост повесить в дистре и объявить его "самым безопасТъным". Ну да, безопасно, а толку-то с него?
	Ответить \| Правка \| К родителю #59 \| Наверх \| Cообщить модератору


	91. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+2 +/–
	Сообщение от Дон Ягон (ok), 29-Янв-20, 21:05
	> Зачем тогда в принципе устанавливать программу, которая в дефолтных настройках бесполезна в 99 случаях из ста? Сравнивать надо именно конфигурации, полезные большинству. Так-то и sshd можно на локалхост повесить в дистре и объявить его "самым безопасТъным". Ну да, безопасно, а толку-то с него? вздыхает Ты не знаешь, зачем нужен локальный почтовик в юниксах? UPD: И да, блин, sshd по-умолчанию вообще выключен. И это тоже абсолютно верный подход по снижению вреда от возможных дыр в sshd. Безусловно, не спасающий тех, кто пользуется sshd. Подсказка: на десктопе, например, многим он не нужен. В том числе тем, кто не полезет разбираться.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	112. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от sstj3n (?), 30-Янв-20, 10:31
	Речь не о том, зачем он там нужен, а о том, насколько он необходим для функционирования системы. Иначе мы докатимся так до какого-нибудь alpine Linux и скажем, что там по умолчанию вообще нет ни хрена => сие есть самая безопасТная система! Прожить, скажем, без отправки сообщений в локальный ящик пользователя из крона какого-нибудь вполне себе можно. Пример с sshd приведен в контексте массового использования системы в качестве сервера чего-либо. Понятно, что openbsd пока в этот контекст не вписывается ( да и надо ли ? ). С другой стороны, почему бы тогда не позиционировать опёнка в нише домашних настольных ПК?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	123. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от Дон Ягон (ok), 30-Янв-20, 13:34
	> Речь не о том, зачем он там нужен, а о том, насколько он необходим для функционирования системы. В стандартной поставке он нужен (рутовые нотификации), далее ты можешь настроить себе всё как хочешь. > Иначе мы докатимся так до какого-нибудь alpine Linux и скажем, что там по умолчанию вообще нет ни хрена => сие есть самая безопасТная система! Обрати внимание - никто не считает, что тот факт, что по-умолчанию smtpd слушает только localhost делает ОС "самой безопасной ОС". Ты опровергаешь собственные домыслы. > Пример с sshd приведен в контексте массового использования системы в качестве сервера чего-либо. И к чему он? Речь про адекватность настроек по-умолчанию. А рассматривать всерьёз сервера без ssh или чего-то аналогичного (я хз чего) - просто идиотизм. > Понятно, что openbsd пока в этот контекст не вписывается Ты хочешь сказать, что серверов под OpenBSD не бывает?) > С другой стороны, почему бы тогда не позиционировать опёнка в нише домашних настольных ПК? OpenBSD система общего назначения.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	142. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от sstj3n (?), 31-Янв-20, 09:43
	Как же туго-то... Суть примеров: если то, что ты называешь "адекватными настройками", существенно урезает возможность использования core functionality софта, то называть это "адекватными настройками" как-то странновато, и уж тем более говорить о том, что это есть mitigation для проблемы. Переводя пример с sshd в плоскость opensmtpd: нахрена мне _по_умолчанию_ в системе сервис, предназначенный в том числе для релеинга писем за пределы локалхоста, но которым я не могу воспользоваться без повышения уровня опасности уязвимости ? Класть нотификации в локальный mbox можно более простыми способами, без россказней об "адекватности настроек", а софт просто снести нафиг за ненадобностью, ибо самая безопасный сервис в системе по умолчанию - это потушенный сервис, либо его отсутствие. Посыл: считать существенное урезание функционала софта через "адекватные настройки" в поставке по умолчанию преимуществом есть некорректность и не более чем маркетинговый ход, поэтому упоминать это как некое преимущество есть глупость
	Ответить \| Правка \| Наверх \| Cообщить модератору


	146. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от Дон Ягон (ok), 31-Янв-20, 15:50
	> Суть примеров: если то, что ты называешь "адекватными настройками", существенно урезает возможность использования core functionality софта, то называть это "адекватными настройками" как-то странновато, и уж тем более говорить о том, что это есть mitigation для проблемы. Ты или слушаешь в пол уха или не хочешь понимать меня, похоже. Core functionality урезается не в принципе, а только в поставке по-умолчанию. Если мы говорим о продукте OpenSMTPD, то да, это практически никак не влияет на его безопасность, потому что первое, что в нём включат - "слушать не только localhost". Если мы говорим о продукте OpenBSD, то ограниченность OpenSMTPD локалхостом влияет на безопасность продукта. Не все используют OpenBSD исключительно как почтовый сервер, а local root, гораздо лучше, чем remote root. Хотя тоже плохо, да. > Переводя пример с sshd в плоскость opensmtpd: нахрена мне _по_умолчанию_ в системе сервис, предназначенный в том числе для релеинга писем за пределы локалхоста, но которым я не могу воспользоваться без повышения уровня опасности уязвимости ? А что, есть способ поднять на машине сервис, слушаюший/пишущий в сеть, не подняв уровень опасности для сервера? Очевидно, что сервер, слушающий сеть менее безопасен, чем сервер, который этого не делает. Очевидно, что если тебе нужен полноценный почтовый сервер, тебе придётся устанавливать ПО, которое умеет в smtp не только на локалхосте. > Класть нотификации в локальный mbox можно более простыми способами, без россказней об "адекватности настроек", а софт просто снести нафиг за ненадобностью, ибо самая безопасный сервис в системе по умолчанию - это потушенный сервис, либо его отсутствие. Ну то есть ты предлагаешь вместо одного потенциально уязвимого сервиса сделать два (или более) потенциально уязвимых сервиса, я всё правильно понял? Ещё раз: если функциональность нужна, она всё равно будет включена, тем или иным способом. И в её реализации может быть уязвимость. > Посыл: считать существенное урезание функционала софта через "адекватные настройки" в поставке по умолчанию преимуществом есть некорректность и не более чем маркетинговый ход, поэтому упоминать это как некое преимущество есть глупость Точно? То есть, если бы OpenSMTPD, например, по-умолчанию позволял бы без какой либо проверки любому внешнему пользователю отправить письмо с любого адреса - ты бы высказывался в таком же духе? Минималистичные настройки по-умолчанию - это не серебрянная пуля, как и все прочие митигации. Безопасность - это комплексный процесс и каждая отдельно взятая мера - это кусок пазла. Глупо ждать, что настройки по-умолчанию решат все проблемы или отменят найденную уязвимость (типа той, про которую пост). Ещё более глупо - делать из этого вывод, что настройки в стиле "воруй-убивай, можно всё" по-умолчанию могут привести к чему-то хорошему.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	154. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от Дон Ягон (ok), 01-Фев-20, 03:00
	> рутовые нотификации В смысле письма от всяких демонов на root@$host. Как мне показалось, формулировка неудачная и требует уточнения. Как правило рутовая почта - это алиас.
	Ответить \| Правка \| К родителю #123 \| Наверх \| Cообщить модератору


	113. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от Анонимус2 (?), 30-Янв-20, 11:21
	Зачем вообще локальному почтовику слушать smtp? Насколько я помню в debian exim вообще не слушает ничего по умолчанию, sendmail(1) работает - и достаточно.
	Ответить \| Правка \| К родителю #91 \| Наверх \| Cообщить модератору


	122. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+1 +/–
	Сообщение от Аноним (122), 30-Янв-20, 13:24
	> вздыхает > Ты не знаешь, зачем нужен локальный почтовик в юниксах? И зачем, если локально хватает MTA типа DMA? man dma > dma – DragonFly Mail Agent > dma is a small Mail Transport Agent (MTA), designed for home and office use. > It accepts mails from locally installed Mail User Agents (MUA) and > delivers the mails either locally or to a remote destination.
	Ответить \| Правка \| К родителю #91 \| Наверх \| Cообщить модератору


	124. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+1 +/–
	Сообщение от Дон Ягон (ok), 30-Янв-20, 13:37
	>> вздыхает >> Ты не знаешь, зачем нужен локальный почтовик в юниксах? > И зачем, если локально хватает MTA типа DMA? > man dma DMA - очень хороший вариант, да (и вообще стрекоза мне нравится). В OpenBSD вместо него OpenSMTPD, слушающий только localhost, т.е. урезанный до +/- аналогичного простого функционала.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	155. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от Дон Ягон (ok), 01-Фев-20, 03:19
	> sshd по-умолчанию вообще выключен Я обманул, инсталлятор спрашивает о том, запускать по дефолту или нет.
	Ответить \| Правка \| К родителю #91 \| Наверх \| Cообщить модератору


	66. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+/–
	Сообщение от Аноним (66), 29-Янв-20, 18:00
	Мы и не продаём "слона".
	Ответить \| Правка \| К родителю #50 \| Наверх \| Cообщить модератору


	53. "Уязвимость в OpenSMTPD, позволяющая удалённо выполнить код с..."	+1 +/–
	Сообщение от OpenEcho (?), 29-Янв-20, 16:55
	>Просто на эту ОС редко кто обращает внимание и мало кто ей пользуется - отсюда и мифы все. Т.е. General Motors, JPL не в счет ?
	Ответить \| Правка \| К родителю #24 \| Наверх \| Cообщить модератору