[COMM] Атаки типа buffer overflow

[COMM] Атаки типа buffer overflow

[Alexey Morsov]

Привет,

Не секрет что многое в линуксе (а точнее там где используються 
некоторые распространенные функции Си - скажем strcpy, sprintf) 
подвержено переполнению буфера - и является уязвимым место многих 
сервисов...

Собственно вопрос - как обстоят с этим дела и как можно 
попроверять, поисследовать, помониторить на этот счет (про snort 
слышал но не пользовался)?

-- 
Всего наилучшего,
Системный Администратор ЗАО "ИК "РИКОМ-ТРАСТ"
Алексей Морсов
ICQ: 196766290
Jabber: Samurai@jabber.ru
http://www.ricom.ru
http://www.fondmarket.ru

[Comm] Re: Атаки типа buffer overflow

[Денис Смирнов]

On Thu, Aug 12, 2004 at 04:47:06PM +0400, Alexey Morsov wrote:

 AM> Не секрет что многое в линуксе (а точнее там где используються 
 AM> некоторые распространенные функции Си - скажем strcpy, sprintf) 
 AM> подвержено переполнению буфера - и является уязвимым место многих 
 AM> сервисов...

Я бы сказал что подавляющее большинство ошибок безопасности с этим и
связано.

Собственно проблема в том, что в C отсутствует тип данных "строка". Есть
только тип данных "указатель на символ", который и используется для работы
со строками. Следить за тем, чтобы не было записи в память, не
принадлежащую этой переменной, должен сам программист.
 
 AM> Собственно вопрос - как обстоят с этим дела и как можно 
 AM> попроверять, поисследовать, помониторить на этот счет (про snort 
 AM> слышал но не пользовался)?

Копать в сторону утилит типа valgrind, которые умеют отлавливать некоторые
проблемы такого рода. В общем случае проблема неразрешима, и является
основной причиной крайней неразумности использования языка С для написания
прикладного ПО.
 
-- 
С уважением, Денис

http://freesource.info

Re: [Comm] Re: Атаки типа buffer overflow

[Alexey Morsov]

Денис Смирнов wrote:
>  AM> Собственно вопрос - как обстоят с этим дела и как можно 
>  AM> попроверять, поисследовать, помониторить на этот счет (про snort 
>  AM> слышал но не пользовался)?
> 
> Копать в сторону утилит типа valgrind, которые умеют отлавливать некоторые
> проблемы такого рода. В общем случае проблема неразрешима, и является
> основной причиной крайней неразумности использования языка С для написания
> прикладного ПО.
Т.е. ваше мнение что на Си нужно (и достаточно безопасно) писать 
только системное ПО (модули, ядра, драйвера)? А приложения (и уж 
тем более взаимодействующие с интернет) на чем-то ином?
А на чем тогда (вроде тотже апач, mysql, squid на Си и писаны)?

-- 
Всего наилучшего,
Системный Администратор ЗАО "ИК "РИКОМ-ТРАСТ"
Алексей Морсов
ICQ: 196766290
Jabber: Samurai@jabber.ru
http://www.ricom.ru
http://www.fondmarket.ru

[Comm] Re: Атаки типа buffer overflow

[Денис Смирнов]

On Mon, Aug 16, 2004 at 12:48:11PM +0400, Alexey Morsov wrote:

 AM> Т.е. ваше мнение что на Си нужно (и достаточно безопасно) писать 
 AM> только системное ПО (модули, ядра, драйвера)? А приложения (и уж 
 AM> тем более взаимодействующие с интернет) на чем-то ином?

Именно так.
 
 AM> А на чем тогда 

Хоть на Visual Basic. Я абсолютно серьёзно.

Если совсем серьёзно, то при программировании по Windows лучше всего
использовать любой .NET язык, а при портабельном программировании либо
Java (из распространённых), либо, что гораздо лучше, Tcl.

 AM> (вроде тотже апач, mysql, squid на Си и писаны)?

Ну и светятся в багтраке с завидной периодичностью. И будут светиться
_всегда_. Просто потому, что при программировании на C нужно иметь очень
высокую квалификацию, и требуемая квалификация растёт экспоненциально с
ростом программы. Притом затраты на организацию совместной разработки тоже
растут нелинейно.

Кстати апач, mysql и squid не совсем прикладные программы всё-таки, и при
их написании вставки кода на си отнюдь не помешают (особенно это касается
апача и сквида).

SQL-сервер можно и нужно писать на язычках вроде OCaml, ибо бОльшая часть
нагрузки на процессор это:
 - парсер
 - оптимизатор
 - вычисление функций

Всё это прекрасно оптимизируется. Я не удивлюсь если движок типа SQLite,
написаный на OCaml, окажется:
а) быстрее;
б) надёжнее;
в) менее требовательным к памяти;
г) легче расширяемым;

Но это всё _сейчас_ имеет смысл только в mission critical приложениях.
Просто потому, что хороших программистов на языках отличных от C++ и жабы
за разумные деньги найти сложно, и они _потребуют_ великолепной зарплаты,
соц программ, хорошего менеджмента. Далеко не всегда руководство просто
достаточно квалифицировано, чтобы создать такие тепличные условия (дело не
в деньгах даже, программисты за 2-3k$ реально дешевле программистов за
500-1000$).

Поэтому:

1. делается декомпозиция программы на _модули_ (ООП в жопу)
2. для каждого модуля продумывается на каком языке его стоит писать
3. каждый модуль либо пишется своими силами, либо заказывается у кого-то
сильно более крутого (если модуль критичен по производительности)

интерфейс -- пишется на Tcl (превосходная переносимость, элементарно
сам встраивается в программы на других языках, а также в него легко
встраиваются модули).

логика -- зависит от её объёмов, в порядке убывания: OCaml, Tcl, Java, C++

вещи, требующие максимальной производительности -- OCaml, C++, Java

Ну и далее смотреть и смотреть по ситуации.

Главный принцип программиста -- лень.
Второй главный принцип -- "разделяй и властвуй"

Если код можно не писать, а лицензировать -- он лицензируется. Если код
можно не писать, а взять готовую библиотеку и написать вокруг обёртку --
так и делается. Если код не является тем, ради которого покупается
написаный продукт -- код продвигается в виде правок к используемым
библиотекам (пусть другие люди, которые лучше знают эту сферу, занимаются
его поддержкой).

В случае свободных программ не зазорно использовать в качестве
_расширений_ проприетарные библиотеки (IMHO). Например написать патч к
mplayer, который бы использовал Intel'овские примитивы для DSP _если они
есть у пользователя_ было бы полезно (это как пример).

Ну и следует понимать, что написаное выше есть всего лишь результат
_моего_ весьма небольшого опыта в IT -- я знаю меньше десятка языков
программирования и практически не владею функциональным программированием,
а значит уже большую часть возможностей попросту не вижу. Посему каждый
раз надо внимательно обследовать сферу, для которой пишется программа, и
искать наилучший инструмент. После чего садиться, и изучать этот
инструмент.

Скажем пример -- пишется приложение. Приложение должно быть _очень_
масштабируемых (грубо говоря от сотового телефона до мейнфрейма). Какой
язык будет выбран? Java. Просто потому что это "политика партии" и в этом
случае можно получить больше поддержки, больше кода будет написано
сторонними разработчиками.

Или смотреть что нужно пользователю. Скажем _сейчас_ производительность
находится чуть ли не на последнем месте по важности, а _безопасность_ на
первом. Поэтому выбирая интерпретируемые языки программирования, или
языки вроде OCaml (где написание кривого кода несколько усложняется) можно
получить преимущество на рынке за счёт большей надёжности и более быстрого
добавления новой функциональности.

В любом случае, надо действовать осознанно -- где приоритет "плыть туда
же, куда main stream", где "плаву не туда, куда плывёт течение, а туда,
куда я хочу", где ориентироваться на дешивизну разработчиков, а где на
качество результата.

Если же вопрос в плане "чему учиться?" то я рекомендую:

1. Tcl (обязательно)
2. OCaml (мозги несколько сдвигает, всё не могу найти время чтобы
полностью с ним разобраться, но уже даже теоретическое знание изменило
стиль написания кода на других языках)
3. Java (придётся)
4. Perl (знать надо, но лучше стараться на нём не писать, изучать лучше
после вышеперечисленность, мозги портит почти как бейсик, по себе сужу)

Стоит обратить внимание на Lisp -- так говорят умные люди, которым я
доверяю. Времени пока не нахожу.

-- 
С уважением, Денис

http://freesource.info

Re: [Comm] Re: Атаки типа buffer overflow

[Aleksey Novodvorsky]

Денис Смирнов пишет:

>On Mon, Aug 16, 2004 at 12:48:11PM +0400, Alexey Morsov wrote:
>
> AM> Т.е. ваше мнение что на Си нужно (и достаточно безопасно) писать 
> AM> только системное ПО (модули, ядра, драйвера)? А приложения (и уж 
> AM> тем более взаимодействующие с интернет) на чем-то ином?
>
>Именно так.
> 
>  
>
Проблема в том, что на С написаны и операционные системы, и серверы, и, 
что важнее всего, все системы программирования. Так что сколько бы ни 
рекламировать perl, java, VB (ну, вот этого уж точно не надо!), -- в них 
самих будут дыры.
Конечно, увеличивать число дыр в геометрической прогрессии не стоит. 
Потому нужно просто хорощо писать. А если не хочется, или время 
поджимает -- сваливать свои баги на баги системы программирования. :-)
Сейчас почти всюду, Россия не исключение, приходят к пониманию того, что 
нужны многоплатформенные приложения.
На самом деле, практически все программы, грамотно разработанные на 
linux как платформе разработки, легко переносятся куда угодно. Но есть и 
технологии, приспособленные для этого.
Если не говорить о программировании на C/C++ с использованием 
многоплтформенных библиотек (в частности, графических тулкитов, таких 
как Qt, Gtk (пока -- с оговорками, но их все меньше), WxWidgets (бывший 
WxWindows), то это:
-- скриптовые языки (perl, python, tcl, ruby) с bindings к тем же toolkits;
-- Java, особенно Eclipse;
-- Mozilla development framework (Mozilla это не браузер в первую 
очередь, как многие думают, а очень удобная платформа разработки на 
XUL/js, поддерживающая больше платформ, чем Java и свободная, в отличие 
от нее).

Mono и DotGNU тоже можно включить в этот список, но не стоит 
рассчитывать на их совместимость с .NET.

Rgrds, Алексей

Re: [Comm] Re: Атаки типа buffer overflow

[Maxim Tyurin]

Aleksey Novodvorsky <aen@altlinux.ru> writes:

> Денис Смирнов пишет:
>
>>On Mon, Aug 16, 2004 at 12:48:11PM +0400, Alexey Morsov wrote:
>>
>> AM> Т.е. ваше мнение что на Си нужно (и достаточно безопасно) писать
>> AM> только системное ПО (модули, ядра, драйвера)? А приложения (и уж
>> AM> тем более взаимодействующие с интернет) на чем-то ином?
>>
>>Именно так.
>>
>>
> Проблема в том, что на С написаны и операционные системы, и серверы,
> и, что важнее всего, все системы программирования. Так что сколько бы
> ни рекламировать perl, java, VB (ну, вот этого уж точно не надо!), --
> в них самих будут дыры.

Будут. Но одно дело написать на C только ядро интерпретатора,
проверить и отладить его код и совсем другое писать на C большое
приложение. 

\scip

> -- Mozilla development framework (Mozilla это не браузер в первую
> очередь, как многие думают, а очень удобная платформа разработки на
> XUL/js, поддерживающая больше платформ, чем Java и свободная, в
> отличие от нее).

Если бы XUL не менялся так от версии к версии была бы очень удобная
платформа. А пока с XUL приложением нужно таскать ту версию Mozilla
для которой оно было написано :(

\scip
-- 

With Best Regards, Maxim Tyurin aka Bungarus
JID:	MrKooll@jabber.pibhe.com

Re: [Comm] Re: Атаки типа buffer overflow

[Aleksey Novodvorsky]

Maxim Tyurin пишет:

>Aleksey Novodvorsky <aen@altlinux.ru> writes:
>
>  
>
>>Денис Смирнов пишет:
>>
>>    
>>
>>>On Mon, Aug 16, 2004 at 12:48:11PM +0400, Alexey Morsov wrote:
>>>
>>>AM> Т.е. ваше мнение что на Си нужно (и достаточно безопасно) писать
>>>AM> только системное ПО (модули, ядра, драйвера)? А приложения (и уж
>>>AM> тем более взаимодействующие с интернет) на чем-то ином?
>>>
>>>Именно так.
>>>
>>>
>>>      
>>>
>>Проблема в том, что на С написаны и операционные системы, и серверы,
>>и, что важнее всего, все системы программирования. Так что сколько бы
>>ни рекламировать perl, java, VB (ну, вот этого уж точно не надо!), --
>>в них самих будут дыры.
>>    
>>
>
>Будут. Но одно дело написать на C только ядро интерпретатора,
>проверить и отладить его код и совсем другое писать на C большое
>приложение. 
>
>\scip
>
>  
>
>>-- Mozilla development framework (Mozilla это не браузер в первую
>>очередь, как многие думают, а очень удобная платформа разработки на
>>XUL/js, поддерживающая больше платформ, чем Java и свободная, в
>>отличие от нее).
>>    
>>
>
>Если бы XUL не менялся так от версии к версии была бы очень удобная
>платформа. А пока с XUL приложением нужно таскать ту версию Mozilla
>для которой оно было написано :(
>
>  
>
XUL уже давно стабилен,  с версии 1.4 -- точно.


Впрочем, к концу года должна быть альфа версия xulruner , -- будет проще.

Rgrds, Алексей