В опубликованном (http://permalink.gmane.org/gmane.mail.opensmtpd.general/3009) на днях выпуске SMTP-сервера OpenSMTPD 5.7.2 (https://opensmtpd.org/), развиваемого под эгидой проекта OpenBSD и нацеленного на создание простой и безопасной замены Sendmail, представлены исправления, подготовленные по результатам проведённого компанией Qualys Security аудита безопасности кодовой базы, в ходе которого было выявлено несколько уязвимостей. В том числе обнаружены локальное переполнение буфера и удалённо эксплуатируемая use-after-free-уязвимость, которые потенциально могут привести к выполнению кода злоумышленника с правами пользователя smtpd вне chroot-окружения.Интересно, что разработчики OpenBSD отказались (http://comments.gmane.org/gmane.mail.opensmtpd.general/3011) поменять на сайте (http://www.openbsd.org/) заявление о наличии только двух удалённо эксплуатируемых уязвимостях в базовой поставке OpenBSD за всю историю существования проекта. Отказ мотивирован тем, что OpenSMTPD по умолчанию принимает соединения только от локальных пользователей системы и прикрепляется к сетевому интерфейсу loopback, что при настройках по умолчанию позволяет осуществить атаку только имея аккаунт в системе. В случае использования OpenSMTPD в качестве SMTP-сервера, принимающего запросы извне, атака может быть совершена любым сторонним злоумышленником.
После этого, автор сообщения (http://comments.gmane.org/gmane.mail.opensmtpd.general/3011) с просьбой поменять фразу об уязвимостях в OpenBSD, указал, что проведённый ранее аудит не охватил новые подсистемы OpenSMTPD, такие как модуль фильтрации контента, поэтому данная подсистема требует отдельного изучения. В качестве демонстрации, что проблемы OpenSMTPD не ограничиваются исправленными уязвимостями, он опубликовал (http://seclists.org/oss-sec/2015/q4/25) информацию о потенциально эксплуатируемой проблеме, не исправленной в OpenSMTPD 5.7.2. Проблема позволяет осуществить переполнение буфера через передачу слишком заголовка, размером больше 65535 байт.
URL: http://comments.gmane.org/gmane.mail.opensmtpd.general/3011
Новость: http://www.opennet.dev/opennews/art.shtml?num=43090
Анализатором кода прошлись?
Боюсь, что если по коду ядра и базовой системы OpenBSD пройтись анализатором, большинство их разработчиков придется принудительно переквалифицировать в дворники.
не бойся, пройдись.
не бугурть и пройдись сам, если фанбойство тебе мозги ещё не испортило
проходятся, не волнуйтесь
Казалось бы чего там искать - сервер слушает SMTP-порт, принимает текстовые команды ...Никаких инъекций ...
Скорее всего проблема чудес в решете TCP-сервера ...
> Казалось бы чего там искать - сервер слушает SMTP-порт, принимает текстовые команды
> ...
> Никаких инъекций ...
> Скорее всего проблема чудес в решете TCP-сервера ...)))))
ну во-первых как ты сам сказал сервер принимает команды - уже куча возможностей наклепать дыр с переполнением буфера и тд и тп.
а во-вторых сервак тело письма не просто транзитом гонит - он его еще как бы и обрабатывает ... читает и пишет ...вообще глупым людям мир всегда кажется проще ))
читаем внимательно ... с выражением ... "казалось бы"
Слышу! Слышу голос быдлокодера! Казалось бы, подумаешь - прямо из веб-формы данные подставляются в SQL-запрос... Казалось бы, подумаешь - какие-то "пинги" в OpenSSL проверяют доступность другой стороны... Казалось бы, подумаешь данные из заголовка веб-запроса передаются в CGI-скрипт как переменные окружения через bash... Казалось бы, подумаешь - перемножаем ширину картинки на высоту (получая целочисленное переполнение) и выделяем буфер под картинку...
Хороший, годный комментарий.
> читаем внимательно ... с выражением ... "казалось бы"тихо, спокойно, принимаем лекарства и по палатам.
А дело бывает не только в инъекциях. Вот пример того, как программа, написанная криворуким кодером, может спокойно отправить по сети то, что отправлять вообще никогда не планировалось
http://habrahabr.ru/company/abbyy/blog/127259/
> Казалось бы чего там искать - сервер слушает SMTP-порт, принимает текстовые команды ...Дурилко, уязвимостей в разбиралках текстовых протоколов всегда больше. Просто сишечка никак не помогает при выделении кусков памяти произвольного размера, которые заранее неизвестны.
Вообще-то как с этим бороться - известно уже лет сорок. Полный отказ от буферов фиксированного размера, обработка функциями, принимающими длину буфера, переаллокация при нужде... И библиотек, которые всё это делают - вагон, если руками лень.В сущности, очень забавляет, что у BSD-шников, кичащихся своей безопасностью, ошибки такие детские.
> В сущности, очень забавляет, что у BSD-шников, кичащихся своей безопасностью, ошибки такие детские.Да не, все закономерно. Это всегда так - чем больше показных понтов, тем меньше для них реальных оснований.
Аноним:
"Да не, все закономерно. Это всегда так - чем больше показных понтов, тем меньше для них реальных оснований."Аноним, приведите пожалуйста "реальные основания" обосновывающие ваше неуважительное сообщение?
Crazy Alex:
"В сущности, очень забавляет, что у BSD-шников, кичащихся своей безопасностью, ошибки такие детские."
Использовали ли вы индукцию?Crazy Alex:
"Вообще-то как с этим бороться - известно уже лет сорок. Полный отказ от буферов фиксированного размера"
28.07.2015
"Критическая уязвимость в Android, позволяющая получить контроль через отправку MMS...
Причиной уязвимости является выход за границы буфера в библиотеке обработки мультимедийных данных"
http://www.opennet.dev/opennews/art.shtml?num=42677Crazy Alex:
"И чего ради это проблема для людей на техническом форуме? наверняка патчи к прошивкам для большинства устройств появятся быстро"
http://www.opennet.dev/opennews/art.shtml?num=42677#21Crazy Alex, чтобы вы написали в ответе на это сообщение?
Да-да, берём насплошь двоичную картинку, перемножаем ширину картинки на высоту и выделяем буфер. Не важно, что там целочисленное переполнение при перемножении случилось. Ни сишечка, ни один другой язык не может полностью заменить мозг. На что вы там молетесь? На жабку? Открываем список уязвимостей в жаба-машине, которая, на минуточку, тоже написана на жабе и видим ту же самую картину. А теперь открываем список уязвимостей Exim и Postfix и видим, как можно писать аккуратно без использования защитных мер, и видим как можно продумать архитектуру так, что защитные меры не позволяют воспользоваться потенциальными ошибками. Это результат использования мозга.
> Открываем список уязвимостей в жаба-машине, которая, на минуточку, тоже написана на жабеВнезапно Oracle JVM написана на C++.
> А теперь открываем список уязвимостей Exim и Postfix и видим, как можно писать аккуратно без использования защитных мерПишу из 2019 года. У нас теперь этот список уязвимостей Exim постоянно перед глазами.
Ой, они буфер разбора заголовка размещают в стэке. В cтэке! Где следом за этим буфером идёт указатель возврата из функции.static void
filter_tx_io(struct io *io, int evt)
{
struct filter_session *s = io->arg;
size_t len, n;
char *data;
char buf[65535];
switch (evt) {
case IO_DATAIN:
data = iobuf_data(&s->ibuf);
len = iobuf_len(&s->ibuf);
memmove(buf, data, len);
buf[len] = 0;
Кхм, ну и код. С магическими константами, фиксированным буфером и отсутствием проверок. Стек - то ладно, дело такое, кучу портить - тоже не сахар.
> Кхм, ну и код. С магическими константами, фиксированным буфером и отсутствием проверок. Стек - то ладно, дело такое, кучу портить - тоже не сахар.Это 65535 магическая константа? И memmove нуждается в проверке?
> Отказ мотивирован тем, что OpenSMTPD по умолчанию принимает соединения только от
> локальных пользователей системы и прикрепляется к сетевому интерфейсу loopback, что при
> настройках по умолчанию позволяет осуществить атаку только имея аккаунт в системе.Считаю это гениальным решением. Все сервисы по умолчанию вешать только на петлю и вот у нас волшебным образом получается неуязвимая для внешних атак ОС, можно хвалится всего двумя remote дырками за все время. А про то, что пользы от такой ОС ненамного больше, чем от полностью выключенного компа, можно скромно промолчать.
Да, в общем-то это известно, что неломаемость ОпенБЗД это на самом деле неуловимость (того самого Джо).Если в "мегабезопасном" OpenBSD нет например МАС, а в "дырявых" Linux/FreeBSD есть, то очень сложно найти этому внятное объяснение, кроме версии выше.
> Если в "мегабезопасном" OpenBSD нет например МАС, а в "дырявых" Linux/FreeBSD есть,
> то очень сложно найти этому внятное объяснение, кроме версии выше.Простое объяснение есть: фимозность некоего Тео.
В этом смысле он похож на некоего Марка: главное, побольше пиара, а что там на самом деле - никому не важно.
angra:
> "Считаю это гениальным решением. Все сервисы по умолчанию вешать только на петлю и вот у нас волшебным образом получается неуязвимая для внешних атак ОС, можно хвалится всего двумя remote дырками за все время"Очень остроумный комментарий?
angra, у вас есть фактические возражения по количеству уязвимостей?
Непонятно зачем они в 2015 году пишут достаточно сложную прожку на СИ. Взяли бы сипипи! (пишу как жабист, понимающий, что жаба на данную задачу не подходит). Но на СИ писать - это просто клиника.
Клиника - это писать системные вещь на языке предназначенном для прикладного ПО.
Почтовик - это типа не системное ПО, а прикладное? Breaking news, однако.
smtpd и есть прикладное ПО, работает исключительно в userspace
> smtpd и есть прикладное ПО, работает исключительно в userspaceНуачо, давайте тогда уж и ядро на C++ писать. Прикладное ПО - это ПО, с которым работает только непосредственно пользователь.
C smtpd работает не только пользователь, с ним программы работают, в том числе на других компьютерах - по сети. Все сетевые серверы, все suid-программы или программы, использующие всякие разные capabilities или имеющие прямой доступ к устройствам или драйверам устройств считаются системными. Программы, скачивающие ПО и проверяющие цифровые подписи у этого ПО, тоже можно считать системными. Компиляторы, компоновщики, загрузчики - тоже системное ПО, т.к. им собирают всё вышеозначенное - не хорошо будет, если в неуязвимые программы компилятор добавит закладки.
> Нуачо, давайте тогда уж и ядро на C++ писать.Пробовали, каждый раз получалась какая-то хрень.
>> Нуачо, давайте тогда уж и ядро на C++ писать.
> Пробовали, каждый раз получалась какая-то хрень.Вы не понимаете иронии?
> Нуачо, давайте тогда уж и ядро на C++ писать.Ядро работает в userspace? Или ты просто не знаешь что это такое? Ну и чисто для сведения, ядра, написанные на С++, существуют и вполне успешны.
> Прикладное ПО -
> это ПО, с которым работает только непосредственно пользователь.Я правильно понимаю, что любая cli программа, например grep, это уже не прикладное ПО? Ведь с ней работают другие программы, а не только пользователь.
> C smtpd работает не только пользователь, с ним программы работают, в том
> числе на других компьютерах - по сети. Все сетевые серверы, все
> suid-программы или программы, использующие всякие разные capabilities или имеющие прямой
> доступ к устройствам или драйверам устройств считаются системными. Программы, скачивающие
> ПО и проверяющие цифровые подписи у этого ПО, тоже можно считать
> системными. Компиляторы, компоновщики, загрузчики - тоже системное ПО, т.к. им собирают
> всё вышеозначенное - не хорошо будет, если в неуязвимые программы компилятор
> добавит закладки.Да, богато у тебя в голове намешано. Однострочник на перле или рубине, слушающий порт, уже системное ПО, поставил программе suid бит и магически из прикладной сделал ее системной, wget/curl/browser/любая_другая_качалка и md5sum тоже системными заделались. Ну и странно, что ты архиваторы и текстовые редакторы в системные не записал, а вдруг они тоже закладки сделают(про то, как закладки в твоем мозгу связаны с делением на системное и прикладное ПО, даже знать не хочу).
>> Нуачо, давайте тогда уж и ядро на C++ писать.
> Ядро работает в userspace? Или ты просто не знаешь что это такое?
> Ну и чисто для сведения, ядра, написанные на С++, существуют и
> вполне успешны.Вы не понимаете иронии. Про ядра на C++ я наслышан и не сказал бы что они очень уж успешные. Работают, но популярными не стали. Ядро не работает в userspace - совершенно верно. Спич был ответом на фразу "Клиника - это писать системные вещь на языке предназначенном для прикладного ПО." Ну то есть высказавшийся намекает на то, что ядро написано на языке, предназначенном для прикладного ПО.
>> Прикладное ПО -
>> это ПО, с которым работает только непосредственно пользователь.
> Я правильно понимаю, что любая cli программа, например grep, это уже не
> прикладное ПО? Ведь с ней работают другие программы, а не только
> пользователь.Потенциально - да. Если с grep работают программы, подходящие под другие определения системных, то grep тоже становится частью системы. Уязвимость в grep в таком случае опасна, т.к. может повлечь более серьёзные последствия, нежели текст "Segmentation fault" у пользователя в консольке.
>> C smtpd работает не только пользователь, с ним программы работают, в том
>> числе на других компьютерах - по сети. Все сетевые серверы, все
>> suid-программы или программы, использующие всякие разные capabilities или имеющие прямой
>> доступ к устройствам или драйверам устройств считаются системными. Программы, скачивающие
>> ПО и проверяющие цифровые подписи у этого ПО, тоже можно считать
>> системными. Компиляторы, компоновщики, загрузчики - тоже системное ПО, т.к. им собирают
>> всё вышеозначенное - не хорошо будет, если в неуязвимые программы компилятор
>> добавит закладки.
> Да, богато у тебя в голове намешано. Однострочник на перле или рубине,
> слушающий порт, уже системное ПО,Да, потому как уязвимость в этом однострочнике помогает получить локальный доступ к системе. Эта уязвимость уже будет касаться не только того чела, который написал и запустил это чудо на компьютере, но и всех пользователей этого и других компьютеров. Спам, например, никто получать не желает.
> поставил программе suid бит и магически
> из прикладной сделал ее системной,Друг мой любезный, для чего же по твоему существует suid бит, кроме того, как получить привилегии администратора системы? Прикладным программам не нужно, например, менять пароль пользователя root в файле /etc/shadows. На минутку - любая программа с suid битом обладает таким правом. Это точно прикладная программа?
> wget/curl/browser/любая_другая_качалка и md5sum тоже
> системными заделались.Если используются для скачивания и установки пакетов в систему - да. Представь - пакет скачивается из репозитория, который защищён SSL-сертификатом. Программа, не корректно проверяющая сертификат (будь то wget или curl) позволяет подсунуть ей другой сайт с другими пакетами и PGP-ключами. Пакетный менеджер верит качалке и устанавливает поддельный PGP-ключ. md5sum при проверке поддельного пакета может сказать что всё ОК, даже если результат не совпал с контрольным. Вот уже не один пользователь под угрозой, а все пользователи всей системы. Или даже все пользователи большого количества систем, использующих скомпрометированный репозиторий.
> Ну и странно, что ты архиваторы и текстовые редакторы
> в системные не записал, а вдруг они тоже закладки сделают(про то,
> как закладки в твоем мозгу связаны с делением на системное и
> прикладное ПО, даже знать не хочу).Кстати, уязвимость в tar или в разжималке (gunzip/bunzip2/...) тоже может поспособствовать компрометации системы. Тоже в результате не один пользователь может пострадать, а большое количество.
> Клиника - это писать системные вещь на языке предназначенном для прикладного ПО.Что за новости? Расскажи-ка тогда, на каком таком языке пишутся системные вещи, если не на Си? Посмеяться хочу.
Rust через лет 5.
Не взлетит.
Не у всех глаза сияют: переход с асма на си тоже не гладко шел.
Не будет никакого перехода.
Вы еще предложите перейти с чистокровного Си на Обжектси...
который только для маков
> который только для маковКоторый уже всё, т.к. Swift...
> Rust через лет 5.Ну ты понимаешь, что ты меня повеселил?
На любом. В Линуксе принят Си только потому, что Торвальдс не любит (не осилил) С++. МС пишет на С/С++ со времён Windows 95 OSR2.Стоит напомнить, что язык Си был создан на базе языка Би, затем был создан язык Ди. И все они создавались компанией для внутренних нужд с целью упрощения программирования конкретных задач.
> МС пишет на С/С++ со времён Windows 95 OSR2.Это очень, очень, (очень) плохая рекомендация.
www2,Пара примеров,
"Представлена операционная система Redox, написанная на языке Rust"
http://www.opennet.dev/opennews/art.shtml?num=43105Оберон
https://ru.wikipedia.org/wiki/Оберон_(язык_программирования)Что уж-там смеёмся!
> Непонятно зачем они в 2015 году пишут достаточно сложную прожку на СИ.
> Взяли бы сипипи! (пишу как жабист, понимающий, что жаба на данную
> задачу не подходит). Но на СИ писать - это просто клиника.Ты, жабист, верно думаешь, что сипипи поддерживает уборку мусора, контроль выхода индекса за пределы массива и всякие ништяки типа работы со строками? Нет, братан, сипипи - это тот же си, только в профиль.
Си - небольшой, по нему уже есть обширная практика хождения по граблям. Опытный разработчик знает все грабли и пишет, обходя грабли. Опытным разработчиком на сипипи стать гораздо сложнее, т.к. язык сложнее, граблей больше - не по всем ещё прошлись, не все грабли в голове программиста умещаются.
Ты плюсы вообще видел?std::string
std::vector
auto iter = v.begin()
> Ты плюсы вообще видел?
> std::string
> std::vector
> auto iter = v.begin()Уборка мусора - это вот это вот?
Class * a = new Class;
...
delete a;Контроль выхода за пределы индекса массива - это вот это вот?
Class * a = new Class;
Class b = a[1];Какая кодировка - стандартная в C++? ASCII? UTF-8? В какой кодировке этот ваш std::string работает?
> Непонятно зачем они в 2015 году пишут достаточно сложную прожку на СИ.
> Взяли бы сипипи! (пишу как жабист, понимающий, что жаба на данную
> задачу не подходит). Но на СИ писать - это просто клиника.Классический Анонимус, чем в данном контексте С отличаетася от C++?
"Но на СИ писать - это просто клиника."
Повторите ли вы эти слова инженерам программы работавшим на марсоходом Curiosity?
https://en.wikipedia.org/wiki/Mars_Science_Laboratory
> Интересно, что разработчики OpenBSD отказались поменять на сайте заявление о наличии только двух удалённо эксплуатируемых уязвимостях в базовой поставке OpenBSD за всю историю существования проекта.Вообще-то это "классика":
http://www.coresecurity.com/content/open-bsd-advisorie
> 2007-02-20: First notification sent by Core.
> 2007-02-20: Acknowledgement of first notification received from the OpenBSD team.
> 2007-02-21: Core sends draft advisory and proof of concept code that demonstrates remote kernel panic.
> 2007-02-26: OpenBSD team develops a fix and commits it to the HEAD branch of source tree.
> 2007-02-26: OpenBSD team communicates that the issue is specific to OpenBSD. OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote denial of service attack , as opposed to bugs that lead to remote control of vulnerable systems to avoid oversimplifying ("pablumfication") the use of the term.
> 2007-02-28: OpenBSD team indicates that the bug results in corruption of mbuf chains and that only IPv6 code uses that mbuf code, there is no user data in the mbuf header fields that become corrupted and it would be surprising to be able to run arbitrary code using a bug so deep in the mbuf code. The bug simply leads to corruption of the mbuf chain....
> 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.
> 2007-03-05: OpenBSD team notified of PoC availability.
> 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.
> 2007-03-08: Core sends final draft advisory to OpenBSD requesting comments and official vendor fix/patch information.
> 2007-03-09: OpenBSD team changes notice on the project's website to "security fix" and indicates that Core's advisory should reflect the requirement of IPv6 connectivity for a successful attack from outside of the local network.Короче, такой цирк там уже давно.
Но, судя по комментариям, подход вполне действенный.
Этот "цирк" называется маркетингом.Достаточно написать где-нибудь, что "мы считаем сбоями только случаи, по которым доказанные финансовые потери одного клиента составили не менее 1 млн.$" и можно писать, что у тебя за всё время было лишь 3 сбоя.
Аналогичным образом действует FSF, который переопределил понятие "свобода".
Как ни странно, соглашусь.
Угу, свобода по FSF это жизнь в ограничениях.
"локальное переполнение буфера" Шёл 21 век...
Всё ещё находятся "не слишком умные" товарищи, пишущие на C/C++?? При том обилии языков и главное - безопасных платформ (.NET, Java) просто стыдно читать про такие "уязвимости" - это бестолковость, а не уязвимость!
Ну были бы у ошибок другие названия - что кардинально это бы изменило? Причина ошибок не в ЯП, а в ошибках, допускаемых людьми.
> пишущие на C/C++??Пишущие на C. На C, запомни это - не надо мешать эти языки в одну кучу ибо общего у них только синтаксис и легаси, а на C++ можно и очень просто писать безопасный код.
А вот .net/java не только не безопасней, но ещё намного тормозней.
> А вот .net/java не только не безопасней, но ещё намного тормозней.расскажешь, чем java не безопасней си?
>> А вот .net/java не только не безопасней, но ещё намного тормозней.
> расскажешь, чем java не безопасней си?В Си нет дырявой VM. Очевидно.
> "локальное переполнение буфера" Шёл 21 век...
> Всё ещё находятся "не слишком умные" товарищи, пишущие на C/C++?? При том
> обилии языков и главное - безопасных платформ (.NET, Java) просто стыдно
> читать про такие "уязвимости" - это бестолковость, а не уязвимость!Человек из 21 века, расскажи ка нам про уязвимости в JVM и дотнете? Конечно, на этих платформах дураки от чего-то застрахованы, т.к. их квалификация хуже разработчиков JVM и дотнета, но для умных людей - это прямая дорога к уязвимостям. Какой бы надёжный код они не написали, а уязвимости в виртуальной машине все их усилия сведут на нет.
Ещё один клоун...Ты исходишь из собственной непогрешимости, списывая ошибки на платформу и других людей.
Непогрешимых людей нет. Косячат все. Одни говорят прямо, других тычут в какую-нибудь никчёмную строку ТЗ, переводят стрелки, кричат, или ведут себя так, словно их на горячую сковородку посадили. Что интересно, они себя ведут так даже когда наказания не последует. Уверовали в самих себя. В крайних формах они себя (иногда в окружении других людей, иногда нет) даже на рабочий стол ставят.
> Ещё один клоун...
> Ты исходишь из собственной непогрешимости, списывая ошибки на платформу и других людей.
> Непогрешимых людей нет. Косячат все. Одни говорят прямо, других тычут в какую-нибудь
> никчёмную строку ТЗ, переводят стрелки, кричат, или ведут себя так, словно
> их на горячую сковородку посадили. Что интересно, они себя ведут так
> даже когда наказания не последует. Уверовали в самих себя. В крайних
> формах они себя (иногда в окружении других людей, иногда нет) даже
> на рабочий стол ставят.Я не оспариваю тезис, что есть непогрешимые люди, которые никогда не допускают ошибок (хотя, может быть Кнут?) Я оспариваю, что одним лишь выбором "правильного" языка можно внезапно избавиться от всех ошибок, как думают некоторые:
>"локальное переполнение буфера" Шёл 21 век...
>Всё ещё находятся "не слишком умные" товарищи, пишущие на C/C++?? При том обилии языков и
>главное - безопасных платформ (.NET, Java) просто стыдно читать про такие "уязвимости" -
>это бестолковость, а не уязвимость!Я за то, чтобы люди всегда думали своей головой, а не надеялись на волшебные средства, которые якобы защитят от всех ошибок.
www2,
"Я оспариваю, что одним лишь выбором
"правильного" языка можно внезапно избавиться от всех ошибок, как думают некоторые"
В этой части согласен с вами, но стоит ли игнорировать возможность избавиться от некоторых?
Давайте поговорим об ошибках в ядрах ОС и железе. Ошибки в VM и рядом не валялись.
> "локальное переполнение буфера" Шёл 21 век...
> Всё ещё находятся "не слишком умные" товарищи, пишущие на C/C++??http://www.opennet.dev/openforum/vsluhforumID3/104987.html#69
пошла их пиар компания далеко и на долго.
> компанияКомпания – это общество/фирма/организация/группа людей.
Кампания – это чреда действий/мероприятий с общей целью.// Grammar Nazi
В самом OpenBSD эту проблему эксплуатировать реально? Или она затрагивает только "портовые версии"?
> В самом OpenBSD эту проблему эксплуатировать реально?Уже нет:
http://ftp.openbsd.org/pub/OpenBSD/patches/5.7/common/017_sm...
Патч из cvs у меня накачен (на 5.8 -stable, как я понимаю, 5.8 -release так и выйдет с этой уязвимостью). Просто у нас столько техник по устранению подобных уязвимостей, что интересно вообще, может ли она работать в практических условиях.
> Патч из cvs у меня накачен (на 5.8 -stable, как я понимаю,
> 5.8 -release так и выйдет с этой уязвимостью).Верно. Нужно или на 5.8 тоже накатывать патчи, или собирать 5.8-stable.
> Просто у нас
> столько техник по устранению подобных уязвимостей, что интересно вообще, может ли
> она работать в практических условиях.Вопрос практики, но ProPolice и остальные техники не панацея, так что не исключено.