Все новости от 14 апреля 2003 г.

Команда open-source справилась с переполнением буфера

Руководитель проекта Тео де Раадт уверен, что благодаря изменениям, внесенным в новую версию варианта Unix, которая выходит 1 мая, вызвать переполнение буфера будет чрезвычайно трудно, а то и вовсе невозможно. «Я мог бы просто сказать, что с переполнением буфера покончено, но я нахожусь в аудитории экспертов по безопасности, поэтому должен взять это в кавычки», — заявил он в четверг на конференции CanSecWest.

Ошибки, связанные с распределением памяти, не удавалось искоренить почти 30 лет, поэтому утверждение группы разработчиков open-source о том, что она справилась с этой задачей, требует проверки. Некоторые участники конференции уже выразили свои сомнения. «Это просто дополнительный уровень защиты, — сказал старший менеджер по безопасности швейцарского оператора связи Colt Telecom Николас Фишбах. — Он не даст большого эффекта, так как в любом ПО всегда найдутся баги».

Чтобы использовать переполнение буфера, злоумышленник обычно присылает программу, запрашивающую слишком много информации. Данные, как правило, состоят из двух компонентов: один нарушает работу приложения, а другой содержит программу, которую старается исполнить злоумышленник, или указывающий на нее адрес ячейки памяти. Когда первый компонент выводит приложение из строя, операционная система исполняет второй.

Команда OpenBSD затруднила этот процесс при помощи трех мер.

Во-первых, место расположения стека — области памяти, в которой хранятся приложения и их данные, — теперь выбирается произвольно, так что код, призванный вызвать переполнение буфера, должен будет «знать» схему распределения памяти для данной системы. «Переполнение буфера использует определенную схему распределения памяти, — пояснил де Раадт. — Теперь памяти расходуется несколько больше, зато задача взломщиков сильно усложняется».

Во-вторых, чтобы затруднить исполнение программы в случае переполнения буфера, группа изменила способ хранения важных адресов в стеке. В структуру памяти введен маркер, называемый «канарейкой», который обнаруживает факт модификации адреса: хакеры обычно используют этот прием, чтобы заставить легитимную программу исполнить вредоносный код.

Наконец, группа нашла способ расчленить файловую систему BSD и разделить память на зоны, предназначенные для записи данных и исполнения программ. Так называемые страницы памяти, хранящие программы и данные, размещаются в одной из этих двух зон. «Мы хотим гарантировать, что ни одна страница не будет использоваться для записи и исполнения одновременно. Никакие хакеры не смогут записать код и тут же исполнить его», — сказал де Раадт.

Проблема группы OpenBSD в том, что если у 64-разрядных процессоров такая защита памяти существует, то более популярные 32-разрядные чипы ее не поддерживают. Чтобы разделить память на зоны для записи и исполнения, эту проблему необходимо решить. В первомайском релизе защищенной структуры страниц памяти для 32-разрядных процессоров еще не будет. Де Раадт обещает, что она будет готова в течение шести месяцев.

Разработка OpenBSD Project финансируется за счет гранта Управления исследовательских проектов Министерства обороны США (DARPA) размером в 2,3 млн $, однако последние изменения выходят за рамки первоначальных требований гранта. «На самом деле это не входит в грант DARPA, — заявил де Раадт. — Но это сделано благодаря гранту DARPA, потому что, когда парни соберутся в одной комнате и выпьют... вот что получается». Де Раадт очень старался подчеркнуть, что группа за пиво расплатилась.

 В продолжение темы:

Обсуждение и комментарии

	Wintermute - devnul.ru 14 Apr 2003 4:50 PM
Молодцы ребята, дело делают.
	AT - 220220pager.icq.com 14 Apr 2003 4:52 PM
А на пиво им денег конечно мало дали ..
	maq 14 Apr 2003 5:16 PM
Меня всегда интересовал вопрос: почему ОС не используют аппаратные возможности процессоров для безопасной работы с памятью. Ведь создать сегмент только для чтения/исполнения можно было уже в 386х.
	jstm 14 Apr 2003 8:01 PM
2 maq Dlia menia eto tozhe zagadka Ved' pravda mozhno sozdat' read-write (not execute) segment i zagruzhat' ego descriptor v steckovyj registr. Mozhet eto slozhno ili sil'no zamedliaet rabotu ?
	Anti-MS 14 Apr 2003 8:18 PM
поздравляю бсдишников ;) у нас в линуксе такая фишка есть уже довольно давно, я ее пробовал и тестил т.к. на х86 все это реализуется в софте, то оно подтормаживает, даже на глаз видно что подтормаживает. а еще проблема в том, что некоторый софт так работать не хочет...
	Ron - rodionlenta.ru 14 Apr 2003 9:26 PM
>> "а еще проблема в том, что некоторый софт так работать не хочет..." Ну, с учётом того, что большая часть софта OpenSource вообще на грани работоспособности находится, это не так уж и страшно :-))
	Anti-MS 14 Apr 2003 9:52 PM
Это виндовый софт находится на грани того что он может не делать то для чего предназначен
	Masonok - masonokyahoo.com 15 Apr 2003 7:13 AM
Интересно. Если в Линухе это есть давно - тогда чего добились разрабочики? еще раз изобрели велосипед? :)
	+++ 15 Apr 2003 7:23 AM
Вот оно и не понятно чего они изобрели... Например, в solaris ещё с версии 2.6 была такая фича как неисполняемый стек - достаточно было в /etc/system указать: set noexec_user_stack=1 set noexec_user_stack_log =1 и всё...
	dem 15 Apr 2003 9:24 AM
Ээээээ а разве OpenBSD финансируется ДАРПА? Разве им не выдали грант только на тестирование реализаций протоколов?
	glassy 15 Apr 2003 9:34 AM
Ребята-то делают, только работать будет один фиг медленнее.
	Qrot 15 Apr 2003 10:21 AM
dem: раз выдали грант - значит финансирует, разве нет?