Какого года эта статья? Там упор делается на NT4.0 и только вскользь упоминается w2k, а ведь уже и w2k3 уже как полгода назад вышел...

>Поэтому, любая мало-мальски серьезная акция начинается с изучения атакуемого объекта (целенаправленный взлом). Отсюда: при прочих равных условиях степень защищенности системы обратно пропорционально легкости анализа ее кода.

Недоказанный вывод из вообщем то правильного посыла. Следовательно - следующие выкладки на основе этого вывода не истинные.

RE:

>В частности, в большинстве UNIX'ов вводимый пароль открытым текстом передается по сети

RE:

>Взять хотя бы классическую задачу смены пароля.
Интересно, а чувак вообще знает о том, что в винде есть LSA, библиотека SAMLib и т.д., в которых тоже могут быть ошибки?

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

RE:

>К тому же, обмен сообщениями в графических оболочках UNIX обычно осуществляется по протоколам TCP/IP,

Вот это перл... круче только статьи Руссиновича про Linux...

RE:

>>выполнение привилегированных операций
>выполняется операционной системой
интересно, все службы (services.msc), выполняемые под System тоже выполняются операционной системой? :)))

RE:

>>возможность отладки активных процессов
>отсутствует

это финиш...

Ааа, Крис Касперски? СЛышал слышал. На самом деле это неудачник, которого на самом деле зовут что-то типа Вася Козявкин. Пытался устроиться на работу в несколько серъезных организаций, откуда был выгнан со смехом. И по сей день никем, кроме как мелким писакой в дешевые журналы, не является... Ню-ню :))

М-да перлы оннако ...

>б) в UNIX [skip], отладка уже запущенных процессов запрещена!

(gdb) help attach Attach to a process or file outside of GDB. This command attaches to another target, of the same type as your last "target" command ("info files" will show your target stack). The command may take as argument a process id or a device file. For a process id, you must have permission to send the process a signal, and it must have the same effective uid as the debugger. When using "attach" with a process id, the debugger finds the program running in the process, looking first in the current working directory, or (if not found there) using the source file search path (see the "directory" command). You can also use the "file" command to specify the program, and to load its symbol table.

из таблички >возможность доступа в адресное пространство чужого процесса >UNIX >отсутствует

по крайней мере в Linux имеет место это можно сделать через /proc/[pid]/mem

>UNIX, и NT имеют исполняемый стек (то есть разрешают выполнение >кода в стеке) и запрещают его выполнение в сегменте данных. А это >значит, что переполнение буферов, содержащихся в автоматических >(т.е. стековых) переменных несет в себе угрозу полного захвата >управления над уязвимой программой. Правда, для некоторых UNIX >существуют заплаты, отнимающие у стека право выполнения, но сфера >их применения весьма ограничена (исполняемый стек необходим >множеству вполне легальных программ, в частности, компиляторов).

Автор видимо не в курсе что

a) Существует аналогичный патч для NT б) существующие патчи для Linux прекрасно решают проблемы - связанные с ограничениями возможности исполнения кода в стеке

Резюме:

Человек явно слабо знаком с *NIX - системами ...

sS:
>по крайней мере в Linux имеет место это можно сделать через /proc/[pid]/mem
Угу, а через ptrace вообще много где :)

>существующие патчи для Linux прекрасно решают проблемы - связанные с ограничениями возможности исполнения кода в стеке
Ну да. IIRC, signal trampoline с 2.5 уже находится не на стеке.

Ну если вспоминать все способы то есть еще и LD_PRELOAD ;)

Писано не программером, однако.
Впрочем все его статьи удивительно прикольны.
Ляп на ляпе.
Может он пишет розыгрыши?

>>В частности, в большинстве UNIX'ов вводимый пароль открытым
>>текстом передается по сети и при наличии хотя бы одного уязвимого
>>узла в цепочке передачи, может быть перехвачен хакером.

Странно, telnet вроде как совсем не обязательно использовать. Я так telnet уже и не помню когда пользовал. Все SSH да SSH...
А вот NFS 3 и меньше - действительно пакостная штука в отношении security :( Да и тормозная...
Хорошо хоть в 4-й версии все поправили, использовав Kerberos 5. Но вот только реализаций пока ее маловато

> Кроме того, и UNIX, и NT имеют
> исполняемый стек (то есть разрешают выполнение кода в стеке) и
> запрещают его выполнение в сегменте данных.
Странное утверждение. Вообще-то некоторые проги, такие как, например,
dosemu, выполняют код в сегменте данных, даже не подозревая о том,
что это, оказывается, запрещено.

> Ну да. IIRC, signal trampoline с 2.5 уже находится не на стеке.
А по-подробнее можно? Они теперь без sigreturn() чтоли обходятся,
или просто trampoline в другое место кладут? А если используется
sigaltstack(), то куда trampoline теперь помещается?
Или я что-то не так понял?

> Ааа, Крис Касперски? СЛышал слышал. На самом деле это неудачник, которого на самом деле зовут что-то типа Вася Козявкин. Пытался устроиться на работу
> в несколько серъезных организаций, откуда был выгнан со смехом.
А ссылку можно? Интересно будет почитать об этом человеке. Помнится
в Фидо он немало шуму наделал году в 97, что-то всё время писал, хакал,
группу единомышленников собрать хотел, а потом вдруг слинял.
Вообще-то со смехом редко выгоняют, так как увольнение в серьёзной
конторе - процесс обычно давольно сложный. У нас например (хотя это
гос. организация) до сих пор одного программера уволить не могут,
хотя он начальство открытым текстом посылает и раскладывает пасьянс
вместо работы:)

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

Про запрет исполнения кода в стеке - это маловероятно. Потому как при использовании flat-модели (а её используют как Windows, так и Linux) все сегменты (и код, и стек) проецируются в одну и ту же область , поэтому любой байт стека принадлежит также и сегменту код и наоборот. Если и существуют какие-то патчи, перекрывающие наиболее частые метода взлома через bufer overflow, то это лишь пришлёпки. Нужно было изначально сегментную модель использовать, а не гнаться за простотой. В целом же статья на редкость неграмотная, как в отношении Linux (открытые пароли и пр. бред), так и в отношении Windows (взлом с помощью сообщений и пр.)

+

>Про запрет исполнения кода в стеке - это маловероятно. Потому как при
>использовании flat-модели (а её используют как Windows, так и Linux) все
>сегменты (и код, и стек) проецируются в одну и ту же область , поэтому
>любой байт стека принадлежит также и сегменту код и наоборот. Если и
>существуют какие-то патчи, перекрывающие наиболее частые метода взлома
>через bufer overflow, то это лишь пришлёпки. Нужно было изначально
>сегментную модель использовать, а не гнаться за простотой.

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

2kilolife: >Недоказанный вывод из вообщем то правильного посыла. Следовательно - следующие выкладки на основе этого вывода не истинные.

Что тут доказывать? По-моему это очевидно. "Прочие равные" видели? Другое дело, что прочими равными в нашем случае и не пахнет. Так, что выкладки на основе этого вывода все равно не истинные :)

Очень хорошая статья. Автор не встаёт ни на сторону NT, ни на сторону UNIX. Просто показывает что где хорошо и что где плохо. И он в отличие от всяких там "Рыбниковых" действительно разбирается в том что пишет. Приятно почитать умного человека.

2Dr_Tux

>действительно разбирается в том что пишет

Ты это серьезно или издеваешся ;) ?

про привилегии юз-зверей

> Модель привилегий пользователей, применяемая в большинстве UNIX, является одноуровневой

А как же MAC, RBAC и иже с ними?

защита сокетов от нежелательных подключений - отсутствует????
Бред собачий.

flat vs segmentation

2 Eugene_Korobko:

> Про запрет исполнения кода в стеке - это маловероятно.

Не, это просто медицинский факт

http://pageexec.virtualave.net/

> Потому как при использовании flat-модели (а её используют как Windows, так и Linux)

s/Linux/vanilla Linux kernel/

про dosemu.

2 anonymous (*) (19.10.2003 2:43:01):

> Вообще-то некоторые проги, такие как, например, dosemu, выполняют код в сегменте данных, даже не подозревая о том, что это, оказывается, запрещено.

Если не сделать chpax -psrm ..., dosemu под PaX'-онутым ядром не запускается.

>Нужно было изначально сегментную модель использовать, а не гнаться за простотой.
Про не-IA32 архитектуры что-нибудь слышали? Расскажите мне в каком месте Alpha живут енти самые сегменты (а на Alpha живут как NT4 так и Linux).

К тому же все равно как обращались к локальным переменным через DS: префикс - так же будут обращаться через SS и такие же overflow будут.

А вот сделать EXEC бит на страничках по-моему особой проблемы не было... но Intel как всегда были впереди планеты всей...

>А по-подробнее можно? Они теперь без sigreturn() чтоли обходятся
Нет, просто теперь код возврата из сигнала живет по адресу 0xFFFFE000 (kernel/user read-only, то бишь read-exec-only :)), это т.н. VSYSCALL страничка. Там же живут и точки входа в SYSENTER/SYSEXIT.

Раньше же было примерно так: когда ты входишь в сигнал ядро кладет на стек (либо на altstack) целиком фрейм и код, выполняющий sigreturn, и возврат указывает как раз на этот код. Теперь на стек кладется только фрейм, а код возврата перманентно живет в 0xFFFFE000 (на него указывает точка возврата в фрейме).


>А если используется sigaltstack(), то куда trampoline теперь помещается?
Все тоже самое, по-моему. На altstack кладется только фрейм, точка возврата - __kernel_sigreturn на VSYSCALL странице.

То бишь код теперь на стеке не живет (во всяком случае сигнальный).

> А вот NFS 3 и меньше - действительно пакостная штука в отношении security :(

SecureRPC есть сто лет в обед. В том числе и с аутентификацией Kerberos. То, что "передовая ОС Linux" этого не умеет, проблемы Linux.

Если развести данные, код и стек по разным сегментам, то им можно установить разные флаги доступа. Код - только исполнение и чтение, данные и стек - только чтение и запись (не исполнение), и следить за этим будет процессор (аппаратно). Я почитал про Exec Shield. Эта утилита как раз и вводит элементы сегментации. Сегмент кода ограничивается по размеру, чтобы не накрывал стек. Т.е. это отход от flat-модели. Что, собственно, и требовалось доказать. Управление правами доступа на уровне страниц сделсть, конечно, можно было, но зачем? Управлять на уровне сегментов логичнее и естественнее, что и было реализовано. Нужно было просто в ОС поддержать. Про другие платформы: управление сегментами - это настольно низкоуровневая фича, что всё равно для каждой платформы пишется отдельно. Поэтому поддержка сегментации для платформы Intel не сильно бы отразилась на переносимости. Про быстродействие: сдаётся, что flat-модель не добавляет скорости, и вот почему. Процессор ничего не знает про flat. Процессор ВСЕГДА (а защищённом режиме) работает с сегментами. И даже при flat-модели существует три сегмента: код, данные и стек. для каждого из которых заведён дескриптор. А то, что базы этих сегментов совпадают,на скорости вычисления линейных адресов не отражается. Операции всё равно будут "межсегментными", даже если работают с одним и тем же блоком памяти. Впрочем, есть серьёзные сомнения относительно того, что на процессорах начиная с 386 "межсегментность" на что-то влияет.

Eugene_Korobko:

>Про другие платформы: управление сегментами - это настольно низкоуровневая фича, что всё равно для каждой платформы пишется отдельно.

Управление - да, но если ввести сегменты, то для ядра не будет существовать понятие "адреса" в адресном пространстве (ну или по меньшей мере его нужно будет расширить до "сегмент:адрес", ведь тому же copy_to_user понадобится знать куда копировать - в сегмент кода, данных или стека процесса/нити или же вообще в "виртуализированный сегмент"), к тому же возникнет куча гемора с тем, что IA-32 хоть и имеет сегменты, но во многом предполагает плоскую модель, например breakpoints расставляются отладчиком в сегменте кода (еще можно привести примеры).

>Про быстродействие: сдаётся, что flat-модель не добавляет скорости, и вот почему. Процессор ничего не знает про flat. Процессор ВСЕГДА (а защищённом режиме) работает с сегментами. И даже при flat-модели существует три сегмента: код, данные и стек. для каждого из которых заведён дескриптор. А то, что базы этих сегментов совпадают,на скорости вычисления линейных адресов не отражается. Операции всё равно будут "межсегментными", даже если работают с одним и тем же блоком памяти.

Тут согласен, ведь все равно сегментные регистры на IA-32 кэшируют дескрипторы.

>Эта утилита как раз и вводит элементы сегментации. Сегмент кода ограничивается по размеру, чтобы не накрывал стек. Т.е. это отход от flat-модели. Что, собственно, и требовалось доказать.

На самом деле это не отход от flat модели, просто у сегмента кода уменьшается предел, при этом сама трансляция логических адресов в линейные остается той же x->x. То есть это - ни что иное как единственный способ борьбы с отсутствием exec битов на IA-32.

>>действительно разбирается в том что пишет
>Ты это серьезно или издеваешся ;) ?
Абсолютно. Вы все его критикуете, мне он показался очень умным. По крайней мере он умнее меня в вопросах безопасности:)

>>>Поподробней, пожалуйста ...

Dr_Tux (*) Блин, ты бы хоть анонимусом подписывался, не позорился...

>Абсолютно. Вы все его критикуете, мне он показался очень умным.

А мне он показался очень !умным. Вообще мне не понятно слово "умный". Бывают "специалисты", "хорошие специалисты", "мастера". А этот клоун на весь мир такую ерунду несет (повторяться не буду - уже вроде все написано здесь). Какой же он тогда "умный" :).

ЗЫ. А на ЛОР приятно поглядеть - все по теме, никакого флейма, фуда :) или это только по выходным? Когда у глупых и злых ананимусов инета нет? :)

ЗЗЫ. Сори за офтопик.

Я согласен, я и сам заметил несколько "недочётов" в статье: например, говоря об одноуровневой модели привелегий UNIX автор не упомянул про RSBAC, да и с открытой передачей пароля по сети автор явно лажанулся:) Но даже так я бы отнёс его к "хорошему специалисту". Я лично с ним не знаком, но мне, скажем так, было бы интересно поговорить с ним про информационную безопасность. Думаю я узнал бы много нового.

Насчёт того, чтобы писать под анонимусом - не-е-е :) я не опущусь до такой низости :) Лучше уж прослыть ламером :)

>А как же MAC, RBAC и иже с ними?

применяемая в __большинстве__ UNIX !!!
в твоём любимом Debian'е работает MAC и RBAC ??
нет ! также как и почти во всех дистрибутивах

сказки про накладывание патчей рассказывать мне тут не надо

> Нужно было изначально сегментную модель использовать, а не
> гнаться за простотой.
Ну ещё чего. Использование защиты на уровне страниц гораздо
практичнее. То, что она у x86 практически отсутствует, ещё не
означает, что нормальные ОС должны из-за этого на сегментацию
переходить.

> так и в отношении Windows (взлом с помощью сообщений и пр.)
Взлом с помощью сообщений не он придумал. На эту тему совсем
недавно было написано не мало статей и даже в Микрософт признали
угрозу и вроде бы поставили даже какие-то костылики.

> А если используется sigaltstack(), то куда trampoline теперь помещается?
> Все тоже самое, по-моему. На altstack кладется только фрейм,
> точка возврата - __kernel_sigreturn на VSYSCALL странице.
А, то есть теперь trampoline вообще не создаётся, а просто
лежит по фиксированному адресу, куда и производится возврат?
Вроде разумно.
Интересно почему раньше так сделать не могли, это же вроде как
проще гораздо...

> А вот сделать EXEC бит на страничках по-моему особой проблемы
> не было... но Intel как всегда были впереди планеты всей...
А я думаю, проблемы как раз были и очень серьёзные:)
Вот например почему сделали для страниц бит U вместо некоего
аналога DPL из двух бит - это сделало практически бесполезным
использование двух колец защиты из четырёх, и теперь актуально
использовать только Ring-0 и Ring-3, что и делают все современные
ОС. А казалось бы, зачем надо было 1 бит экономить?
Ну и вообще там ещё много приколов было, так что проблемы у Интел
явно были довольно серьёзные на этот период. Они явно куда-то
сильно спешили... :)
Вообще это наверное большой гемор писать операционку для х86...
Вот интересно мне, а как они при таком раскладе ухитрились
mprotect() отхакать? Ведь по идее он не должен тут нормально
работать:)

> Если не сделать chpax -psrm ..., dosemu под PaX'-онутым ядром
> не запускается.
Да он нигде почти не запускается, особенно когда DPMI используется.
Разработчики уже запарились с тем, что малейшие изменения в ядре,
в glibc, в опциях gcc при компиляции и вообще в чём угодно
приводят к его неработоспособности:)

anonymous:
>Интересно почему раньше так сделать не могли, это же вроде как
проще гораздо...

Хороший вопрос... в принципе можно порыться в kernel-mailing list... может там есть какие-нибудь умные мысли по этому поводу.

>Вот интересно мне, а как они при таком раскладе ухитрились
mprotect() отхакать? Ведь по идее он не должен тут нормально
работать:)

А он разве работает? :) Или ты о всяких патчах к ядру? Тот, про который я читал в свое время, просто расширит предел для сегмента кода, если ты PROT_EXEC на страницу поставишь. Там был такой смысл: ld-linux и ядро "стараются" размещать в младших адресах адресного пр-ва исполняемый код, но если ты делаешь mprotect на старшие адреса, то ты сам себе злобный буратино.

Может сейчас что-нибудь умное придумали, хотя вряд ли эту схему можно сильно усовершенствовать.

Про проблемы переносимости при переходе к сегментной модели спорить не буду - я плохо знаю другие архитектуры. Что же касается запрета на исполнение кода в стеке - модель flat, насколько я её понимаю, предполагает ПОЛНОЕ совмещение сегментов, а не только баз. Так что ограничение длины сегмента - это всё-таки уход от плоской модели. Про защиту на уровне страниц - не убедили. Вообще, есть три уровня адросации - виртуальные адреса (те, с которыми работает приложение), линейные (после примнения десегментации) и физические (после примнения страничного механизма к линейному адресу). Разделение на типы памяти (стек, код, данные) нужно делать на уровне виртуальных адресов, т.к. именно здесь адреса разделяются по назначению. Линейные адреса аморфны, в них уже нет информации о том, в каком качестве используется память. У механизма страничного разбиения другая функция.

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

>Операционные системы семейства NT, укомплектованные более чем скромным
>набором утилит, в этом отношении выглядят более защищенными.

Добавлю свою ложку дегтя - когда наконец взаимодействия между ПРОЦЕССАМИ будут называть МЕЖПРОЦЕССНЫМИ а не МЕЖПРОЦЕССОРНЫМИ?????

> mprotect() отхакать? Ведь по идее он не должен тут нормально
> работать:)
> А он разве работает? :)
Вроде да, хотя конечно все возможные комбинации я не проверял.

> Или ты о всяких патчах к ядру?
Да обычный mprotect() (man 2 mprotect)
Написано, что есть PROT_NONE, PROT_READ, PROT_WRITE и PROT_EXEC.
Ну с PROT_NONE и PROT_WRITE ещё понятно, а вот как они реализовали
PROT_READ и PROT_EXEC, мне лично не совсем ясно...

про RBAC, MAC и всех-всех-всех...

2 anonymous (*) (19.10.2003 16:23:29):

> применяемая в __большинстве__ UNIX !

В Solaris есть, в Linux есть, в FreeBSD скоро будет,...

> в твоём любимом Debian'е работает MAC и RBAC ??

http://www.adamantix.org/

> нет ! также как и почти во всех дистрибутивах

Никуда они не денутся -- SELinux есть в стандартном ядре 2.6, так что поддерживать [хотя бы его] придется...

RE:

>Вроде да, хотя конечно все возможные комбинации я не проверял.
Ну я только что перепроверил на 2.4 vanilla и RH, вроде не работает, как и раньше...

>allocated a chunk of length 5 @0x40150000
>Running stupidity with PROT_EXEC @ 0x40150000...
>Checking if we can read the area ...
>U
>Running stupidity with PROT_READ @ 0x40150000...
>Running stupidity with PROT_READ|PROT_EXEC @ 0x40150000 ...
>Running stupidity with PROT_NONE @ 0x40150000 ...
>Received SIGSEGV, reason SEGV_ACCERR @ 0x40150000
>failed!

Выполняю примерно такой код (с разными флажками):
> st = (stupidity_t)area;
> if (setjmp (env) == 0) {
> if (mprotect (area, stupidity_len, PROT_READ) == -1) {
> fprintf (stderr, ".failed to set protection to READ\n");
> }
> printf ("Running stupidity with PROT_READ @ %p...\n", st);
> st ();
> }
> else printf ("failed!\n");

RE:

2.4.20 имелся в виду (vanilla и из RH 9.0)

> в Linux есть, в FreeBSD скоро будет,...

скоро будет не всчёт, а количество дистрибутивов Linux в которых есть можно по пальцам пересчитать и это называется _большинство_ ?

Статья описывает ряд уязвимостей, которые на сегодня либо вообще невозможны, либо устранены. Такое чувство, что автор при её написании пользовался переведёнными на русский язык изданиями популярных на Западе и США книг. Дело в том, что информация в таких книгах частично устаревает к тому моменту, когда её успевают перевести. Кроме того, статья изобилует многими теоретически возможными уязвимостями. Вероятность применения их на практике ничтожна.

Автор путает терминологию, не учитывает наличие средств аппаратной защиты сети. Также не учитывается такое распространённое на сегодня понятие как сборка дистрибутива UNIX-подобной ОС. Например, Linux дистрибутивы на одни и те же уязвимости, даже касаемо ядра, реагируют по-разному. Кроме того, не учитывается различие аппаратной платформы (архитектуры).

Автор не правильно оценивает доступность исходного кода. Доступность исходников, может расцениваться не только со знаком "-", но и со знаком "+", так как позволяет быстро исправить ошибки. Присутствует явная некомпетентность по вопросам многообразия UNIX. Прочитав статью можно сделать вывод, что все UNIX системы распространяются с открытым исходным кодом. Наличие коммерческих дистрибутивов не рассматривается. Хотя все ведущие поставщики коммерческих дистрибутивов (AIX, IRIX, HP), по понятным причинам, исходный код не предоставляют. Исключение компания SUN, но это они делают не бесплатно. Таким образом, открытость исходного кода, может говорить о уязвимости системы только теоретически.

Последнее, вопрос безопасности зависит больше не от системы как таковой, а от того, кто этой системой управляет, от количества и качества администраторов, если это большая система. От политики организации. По статистике в 50-60% всех успешно реализованных атак виноваты корпоративные пользователи (установка несанкционированного софта или иные действия). 30-40% приходится на некомпетентность администраторов. И только в 10% случаев или менее успешность атак возможна благодаря ошибкам (уязвимостям) ОС или приложений.