LINUX.ORG.RU

OpenBSD избавляется от ошибок переполнения буфера


0

0

"Самая безопасная ОС" намерена стать еще безопаснее

Тео де Раадт (Theo de Raadt), лидер проекта OpenBSD, считает, что его участникам удалось сделать успешное использование ошибок переполнения буфера (buffer oveflow error) маловероятным, если не вообще невозможным. Это было достигнуто путем перемещения стека в произвольное место памяти, что существенно затруднило угадывание адреса, по которому необходимо разместить вредоносный код. Кроме того, система теперь отслеживает сохранение критических адресов в стеке и разделяет основную память приложения на исполняемую и записываемую части (пока только для 64-битных платформ). Все эти изменения появятся в OpenBSD 3.3, выход которой запланирован на 1 мая.

>>> Подробности

anonymous

Проверено: maxcom

ага, живо принялись деньги отрабатывать

anonymous
()

Если я не ошибюсь, то эти "фишки" (и не только они) уже давно есть в grsec.

syomin
()

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

anonymous
()

Мониторим Apache через web.

>Если я не ошибюсь, то эти "фишки" (и не только они) уже давно есть в grsec.

grsec - это патч, который используется на свой страх и риск.

А приведенные выше фичи OpenBSD будут включены в стабильный релиз,

что дает определенные гарантии, что софт (ports) поставляемый с 3.3

будет оттестирован, не на пользователях :))).

Sun-ch
()

... Вопрос вообще не в тему :)

Есть ли что-то подобное STL для C (не cpp) ?

(Может об этом уже писали но поиска на сайте нет...)

NiKel
()
Ответ на: Мониторим Apache через web. от Sun-ch

>grsec - это патч, который используется на свой страх и риск.

а что не используется на свой страх и риск, неужели OpenBSD ?

anonymous
()

Интерсно а на сколько это изменение замедлит систему, и замедлит ли вообще :(

anonymous
()

Может я чего-то не понимаю - но зачем знать адрес стека? Эксплойты легко писать работающими из любого места в памяти, а системные вызовы в юниксах вызываются через прерывание (то есть тоже не надо знать никакие адреса)..

hvv
()

trunk: ах, да! Спасибо, запамятовал..

hvv
()

извините, может я что-то не понимаю - а почему не внести контроль на этабе заполнения (и использования) соответствующих буферов?

Гена

anonymous
()

Потому как 99% C и C++ софта тогда надо переписывать.
А после переписывания и включения это защиты (и некоторых еще) мы получим "тормоза" типа Java.

anonymous
()

А на кой чорт вообще что то проверять! Есть же например начиная с 386 проца различные предназначения для сегментов, и к примеру на сегмент стека можно назначить бит ЗАПРЕЩАЮЩИЙ выполнение кода на аппаратном уровне процессора. Но почему то все разработчики ядер нихрена не используют разделяемые сегменты для кода, данных, и стека, для простоты (и от лени) используя тупую flat модель.

Если бы в свое время начали использовать эти возможности на linux (а Торвальдс вполне мог это сделать еше на 1.0 ядре) то никогда бы не было такого рода ошибок. Но... имеем что имеем, пытаясь прикрутить крылья к паровозу.

anonymous
()

Мониторим Apache через web.

>Но почему то все разработчики ядер нихрена не используют разделяемые сегменты для кода, данных, и стека, для простоты (и от лени) используя тупую flat модель.

Ну уж наверное не глупей тебя были :)

Ну нет на мирсе или альфе сегментов как на i386, что теперь

под каждую архитектуру свою VM писать ?

Sun-ch
()

>А на кой чорт вообще что то проверять! Есть же например начиная с > 386 проца различные предназначения для сегментов, и к примеру на >сегмент стека можно назначить бит ЗАПРЕЩАЮЩИЙ выполнение кода на >аппаратном уровне процессора. Но почему то все разработчики ядер >нихрена не используют разделяемые сегменты для кода, данных, и >стека, для простоты (и от лени) используя тупую flat модель.

Тут думаю не лень а исторически сложившаяся модель использоватся стала. Ведь приделать неисполняемый стек не так то и сложно (пример - openwall, grsecurety). К тому-же и особой сложности это не представляет.

>Если бы в свое время начали использовать эти возможности на linux (а >Торвальдс вполне мог это сделать еше на 1.0 ядре) то никогда бы не >было такого рода ошибок. Но... имеем что имеем, пытаясь прикрутить >крылья к паровозу.

И imho одной только защитой памяти все проблемы безопасности не решить ;)

sseREGa
()
Ответ на: комментарий от anonymous

Вы сначала немного почитайте теории, чтобы так категорично говорить. Сегментная защита тут очень плохо помогает, и ее то как раз использовали в Open для nonexec stack/heap. Нужна постраничная защита, а ее на i386 нет. На x86_64 уже есть.

trunk
()

>>А на кой чорт вообще что то проверять! Есть же например начиная с 386 >>проца различные предназначения для сегментов, и к примеру на сегмент >>стека можно назначить бит ЗАПРЕЩАЮЩИЙ выполнение кода на аппаратном >>уровне процессора. Но почему то все разработчики ядер нихрена не >>используют разделяемые сегменты для кода, данных, и стека, для >>простоты (и от лени) используя тупую flat модель.

Юниксы и юних-лайк очень ограничено используют сегментацию. Это потому что на некоторых процах вообще нет Segmentation Unit. А OpenBSD типа на многих платформах должна шпилить.

Banshee
()

При пометке сегмента стека неисполняемым некоторые программы перестают работать (кажется с IBM DB2 была такая проблема) - они в стеке создают код для CPU, который потом исполняют. Но таких программ мало, и посему использование неисп. стека на сервере - очень разумно, если точно знаешь что на нем будет работать.

hvv
()
Ответ на: комментарий от anonymous

На мой взгляд в STL таких проблем нет. STL при правильном пользовании
безопасен как, например, Pascal :)

anonymous
()

Мониторим Apache через web.

>На мой взгляд в STL таких проблем нет. STL при правильном пользовании безопасен как, например, Pascal :)

Сделай заявку на грант в DARPА,

пообещай им что OpenBSD перепишешь на паскале, нет лучше на аде

и всем будет счастье.

Sun-ch
()
Ответ на: комментарий от anonymous

у тебя с башкой всё в порядке? продемонстрировать переполнение буфера на паскале?

anonymous
()

@#$#$%#@!!!! Не говорите мне что в STL нет проблем!!!! Для начала попробуйте её пользовать в программе с кучей тредов (ну тыща, например).

anonymous
()

D избавляется от ошибок переполнения буфера от anonymous Re: Re: Re: OpenBSD избавляется от ошибок переполнения буфера

set noexec_user_stack=1 set noexec_user_stack_log=1

Это параметры ядра в солярке. :)

anonymous
()
Ответ на: комментарий от trunk

> Нужна постраничная защита, а ее на i386 нет.
А как mprotect(2) работает тогда?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.