The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Пример анализа потенциально серьезной уязвимости в OpenSSH"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от opennews (??) on 02-Авг-11, 13:47 
В списке рассылки Full Disclosure опубликован (http://seclists.org/fulldisclosure/2011/Aug/2) разбор достаточно интересной уязвимости в OpenSSH, найденной в реализации алгоритма аутентификации через вызов модулей GSSAPI. Сама по себе уязвимости малопригодна для осуществления атаки, так как может быть использована для осуществления DoS-атаки (исчерпание доступной процессу памяти) на стадии после совершения аутентификации, т.е. эксплуатировать проблему можно только имея работающий аккаунт в системе. Тем не менее интерес вызывает то, что несмотря на то, что проблема проявляется в большинстве современных Linux-дистрибутивов, которые используют метод аутентификации "gssapi-with-mic", ошибка была найдена еще в 2008 году и обнародована только сейчас.


По словам (http://blog.pi3.com.pl/?p=159) нашедшего ошибку исследователя, проблема была так долго не обнародована так как было предположение, что ошибку можно использовать на стадии до совершения аутентификации, т.е. оставалась надежда н...

URL: http://seclists.org/fulldisclosure/2011/Aug/2
Новость: https://www.opennet.ru/opennews/art.shtml?num=31368

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от anonymous (??) on 02-Авг-11, 13:47 
А разве нельзя установить квоты на максимальный размер выделяемой памяти для sshd?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от codejumper on 02-Авг-11, 13:56 
если ограничивать на каждый процесс, то их можно ещё кучу наплодить
если по сумме, то легальные пользователи не смогут заходить, т.ч. также получаем dos
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Аноним (??) on 02-Авг-11, 16:48 
Вообще-то достаточно ограничить пользователя и всё. Если уязвимость требует наличия аккаунта, значит sshd уже сделал setuid и работает из-под пользователя - итого никакой опасности и в логах сразу будет видно кто шалит.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Аноним (??) on 02-Авг-11, 16:45 
Большими malloc'ами нельзя исчерпать свободную память в системе, потому что при malloc'е физические страницы не выделяются - делается банальный анонимный mmap. Либо переводчик лажанул и там было что-нибудь про заполнение этой памяти, либо это уязвимость - чушь на постном масле, либо работает только на редких системах с ущербной виртуальной памятью.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Аноним (??) on 02-Авг-11, 17:38 
> Большими malloc'ами нельзя исчерпать свободную память в системе, потому что при malloc'е
> физические страницы не выделяются - делается банальный анонимный mmap.

Вы бы вначале на код посмотрели, прежде чем критиковать. OpenSSH сразу забивает содержимое буфера перед использованием, что и приводит к физическому выделению страниц:

name->value = xmalloc(name->length+1);
memcpy(name->value, tok+offset, name->length);

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от pro100master (ok) on 02-Авг-11, 18:49 
рискую быть неправым, но разве в современных менеджерах не copy-on-write схема? Где копирование физически происходит только при изменении исходных данных? Память она такая - сейчас самая дорогая операция, глупо писать бит при пенальти в 50-200 тактов.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

8. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Аноним (??) on 02-Авг-11, 19:13 
> рискую быть неправым, но разве в современных менеджерах не copy-on-write схема?

При чём тут cow? Если вы думаете что процессор через libastral определяет что содержимое страниц идентично и шарит страницы вместо копирования, то это бред.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

9. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от pro100master (ok) on 02-Авг-11, 19:17 
Ни процессор, ни процесс тут совершенно не причем. Это забота MM. Он как раз всё про всех знает. Причем, он еще и тем самым астралом планирует выделения/освобождения на основе своей статистики.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Аноним (??) on 02-Авг-11, 19:20 
> Ни процессор, ни процесс тут совершенно не причем. Это забота MM. Он как раз всё про всех знает. Причем, он еще и тем самым астралом планирует выделения/освобождения на основе своей статистики

Лол.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от pro100master (ok) on 02-Авг-11, 19:35 
понятно, работа менеджера памяти ядра недоступна до понимания...
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Аноним (??) on 02-Авг-11, 21:22 
Вполне доступна, если захотите разберётесь. Начните с осознания того, что менеджер памяти приложений работает в userspace, а не в ядре.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от pro100master (ok) on 03-Авг-11, 00:21 
вот это точно лол :)))
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +1 +/
Сообщение от Сергей (??) on 03-Авг-11, 02:26 
А что лол-то? Это чистая правда.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

18. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от ананим on 03-Авг-11, 12:28 
угу. как и я к примеру пишу файлы на винт(!!!) из юзер-спейсной проги.
это магия! :D
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

15. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Аноним (??) on 03-Авг-11, 05:05 
Начали нормально с "рискую быть неправым", а закончили пятой точкой глубоко в луже... аллокатор ничего не знает про страницы и cow, а у ядра память запрашивает через банальный mmap, что уже в этом треде, между прочим, было сказано. cow же работает при форках, например, и в свою очередь не имеет ни малейшего понятия что память используется каким-то там аллокатором.

А вот вас с понятием на уровне "Он как раз всё про всех знает" серьёзно воспринимать невозможно :)

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

16. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Andrew Kolchoogin on 03-Авг-11, 10:22 
Нет. Аллокатор всегда выделяет страницы сразу.

Функция malloc() возвращает либо указатель на область ОЗУ, либо NULL, если выделение ОЗУ по каким-либо причинам не удалось. Если выделять ОЗУ фиктивно, тогда от момента вызова malloc() до момента записи в выделенную область ОЗУ вполне может выполниться несколько malloc()'ов других процессов (напоминаю: UNIX -- система многозадачная), и когда фиктивное выделение придётся сделать физическим, ОЗУ может просто закончиться.

Что тогда? SIGKILL "Out of swap space"? Это неправильно. Противоречит семантике работы malloc(). Если ОЗУ нет -- возвратите NULL и не полируйте моск. Если возвратили указатель -- отдайте моё ОЗУ мне.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

17. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Михаил (??) on 03-Авг-11, 11:26 
>Если ОЗУ нет - возвратите NULL и не полируйте моск. Если возвратили указатель - отдайте моё ОЗУ мне.

echo "vm.overcommit_memory = 2" >> /etc/sysctl.conf

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

19. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Andrew Kolchoogin on 03-Авг-11, 17:51 
===
{3} user@host:~ $ sysctl -a | grep overcommit_memory | wc -l
       0
===

sysctl сами придумали?-)

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

24. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Аноним email(??) on 04-Авг-11, 17:46 
sudo sysctl -a | grep overcommit_memory | wc -l
1
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

23. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  –1 +/
Сообщение от Andrew Kolchoogin on 03-Авг-11, 23:48 
Тщательный анализ grep'ом по исходникам ядра показал, что слово 'overcommit' встречается в vm/swap_pager.c, но отвечает только за возможность выделения ФИЗИЧЕСКОГО ОЗУ для процесса в количестве, большем, чем есть СВОБОДНОГО СВОПА.
Такая ситуация возможна, если в системе размер ОЗУ больше размера свопа, но для FreeBSD такие настройки нехарактерны -- Handbook рекомендует иметь свопа больше, чем физического ОЗУ.
Впрочем, доки на Солярис говорят, что лучше наоборот, но там и sysctl такого нет. :)
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

20. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +1 +/
Сообщение от Аноним (??) on 03-Авг-11, 21:47 
> Нет. Аллокатор всегда выделяет страницы сразу.

Вы уже не раз показали себя ламером, может пора научиться хотя-бы проверять, прежде чем говорить о том, о чём понятия не имеете? Сделайте программу, malloc(); system("ps"); memset(); system("ps"); и посмотрите что будет с VM и RSS.

> Что тогда? SIGKILL "Out of swap space"?

Именно, и это правильно.

> Противоречит семантике работы malloc()

OOM killer не имеет никакого отношения к семантике работы malloc, и избежать его всё равно нельзя из-за фундаментальных принципов работы системы виртуальной памяти. Кроме того, выделение физических страниц на аллокации - это кошмарное падение производительности, рост потребления памяти,  невозможность выделить фрагмент больше размера физической памяти.

Почему нельзя избежать OOM - показываю на примере: процесс выделил много памяти, допустим даже честно выделил физические страницы, далее он форкается. Либо вы честно копируете всё адресное пространство (а с такой системой вы никому не нужны), либо одна из копий будет убита при записи в память, когда при cow кончатся физические страницы.
Другой пример - процесс выделил память-ok, был вытеснен в swap и весь его занял. Другой процесс выделил память-ok, и занял всё физическую. Когда проснётся первый процесс и полезет из swap'а, он будет прибит безо всяких malloc по причине исчерпания физических страниц.

Итого - на деле malloc вернёт 0 скорее всего только в одном случае - при исчерпании адресного пространства (т.е. невозможности сделать анонимный mmap). Во всех остальных случаях процесс будет убит по OOM, это полностью ожидаемое и корректное поведение.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

21. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  –1 +/
Сообщение от Andrew Kolchoogin on 03-Авг-11, 23:02 
>> Нет. Аллокатор всегда выделяет страницы сразу.
> Вы уже не раз показали себя ламером, может пора научиться хотя-бы проверять,
> прежде чем говорить о том, о чём понятия не имеете? Сделайте
> программу, malloc(); system("ps"); memset(); system("ps"); и посмотрите что будет с VM
> и RSS.

Я бы порекомендовал вам перед тем, как говорить о личности собеседника, научиться программировать хотя бы на каком-нибудь языке программирования. Ну, хоть на Бейсике, что ли.

>> Что тогда? SIGKILL "Out of swap space"?
> Именно, и это правильно.

Ну-ну.

>> Противоречит семантике работы malloc()
> OOM killer не имеет никакого отношения к семантике работы malloc, и избежать
> его всё равно нельзя из-за фундаментальных принципов работы системы виртуальной памяти.
> Кроме того, выделение физических страниц на аллокации - это кошмарное падение
> производительности, рост потребления памяти,  невозможность выделить фрагмент больше
> размера физической памяти.

Это вы сами придумали, да?

> Почему нельзя избежать OOM - показываю на примере: процесс выделил много памяти,
> допустим даже честно выделил физические страницы, далее он форкается. Либо вы
> честно копируете всё адресное пространство (а с такой системой вы никому
> не нужны), либо одна из копий будет убита при записи в
> память, когда при cow кончатся физические страницы.
> Другой пример - процесс выделил память-ok, был вытеснен в swap и весь
> его занял. Другой процесс выделил память-ok, и занял всё физическую. Когда
> проснётся первый процесс и полезет из swap'а, он будет прибит безо
> всяких malloc по причине исчерпания физических страниц.

Вы бредите. Почитайте про VM в Юниксе на досуге.

Понятия "процесс был вытеснен в swap" и VM -- взаимоисключающие параграфы.


> Итого - на деле malloc вернёт 0 скорее всего только в одном
> случае - при исчерпании адресного пространства (т.е. невозможности сделать анонимный mmap).
> Во всех остальных случаях процесс будет убит по OOM, это полностью
> ожидаемое и корректное поведение.

Чудесный, непередаваемый бред.

===
{11} user@host:/usr/src/lib/libc $ grep 'return (NULL)' stdlib/malloc.c | wc -l
      30
{12} user@host:/usr/src/lib/libc $ grep 'mmap' stdlib/malloc.c | wc -l
      22
===

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

22. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Andrew Kolchoogin on 03-Авг-11, 23:19 
> Итого - на деле malloc вернёт 0 скорее всего только в одном
> случае - при исчерпании адресного пространства (т.е. невозможности сделать анонимный mmap).
> Во всех остальных случаях процесс будет убит по OOM, это полностью
> ожидаемое и корректное поведение.

По уточнённым данным:

===
{40} user@host:/usr/src/lib/libc $ cc -I /usr/src/lib/libc/include -E stdlib/malloc.c | grep -v "^#" | grep '= mmap'|wc -l
       1
{41} user@host:/usr/src/lib/libc $ cc -I /usr/src/lib/libc/include -E stdlib/malloc.c | grep -v "^#" | grep 'return (0)' | wc -l
      16
===

Итого, случаев возврата NULL'ей в malloc() ровно в 16 раз больше случаев вызова mmap().

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

7. "Пример анализа потенциально серьезной уязвимости в OpenSSH"  +/
Сообщение от Аноним (??) on 02-Авг-11, 19:11 
> Вы бы вначале на код посмотрели

Я, по-моему, всё ясно написал:

> Либо переводчик лажанул и там было что-нибудь про заполнение этой памяти

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру