Решето!

// ну кто-то же

Не слишком страшно. Можно ли вообще это считать уязвимостью?

> Не слишком страшно. Можно ли вообще это считать уязвимостью?

Можно. Атака как минимум сильно сокращает перебор. А если собрать много данных (много раз вводили один и тот же пароль в ssh), то ИМХО можно и без перебора.

Постоянное чтение /proc/$PID$/stat и парсинг прочитанного слегка демаскирует "атакующего". А если учесть, что для набора вменяемой статистики нужно очень много раз эти регистры читать -- выцепить злую каку, думается, окажется легко. Сто лет уже как доказано, что абсолютно надёжного цомпутера существовать не может. И удобство пользования обратно коррелирует с неуязвимостью.

читал уже про это ещё пару месяцев назад

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

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

Тут то не требуется физический доступ к компьютеру и оборудование стоимостью несколько миллионов пендобаксов. Нужен только SSH-доступ с любыми правами.

Капитан Очевидность спешит на помощь!

> читал уже про это ещё пару месяцев назад

Конференция была на прошлой неделе.

Кто-то еще вводит пароли через ssh?

> Кто-то еще вводит пароли через ssh?

При чём тут SSH и пароли?

> Конференция была на прошлой неделе.

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

>> читал уже про это ещё пару месяцев назад

>Конференция была на прошлой неделе.

у вот, тем самым он доказал: Машина времени существует.

не удивлюсь, если он скажет, кто в России будет президент в будущем.

Это примерно как утечка данных через электромагнитное излучение системника. Или шум клавиатуры. Можно сильно сократить область поиска...

> не удивлюсь, если он скажет, кто в России будет президент в будущем.

Это и я могу, без машины времени =).

Что-то не пойму, а толку то от знания значений ESP и EIP. Ну стало известно по каким адресам что-то происходит, или происходило. Дальше что? Данные то как получить?

> Это примерно как утечка данных через электромагнитное излучение системника. Или шум клавиатуры. Можно сильно сократить область поиска...

Или как джиттер при пинговании :)

> Что-то не пойму, а толку то от знания значений ESP и EIP. Ну стало известно по каким адресам что-то происходит, или происходило. Дальше что? Данные то как получить?

В первом посте ссылка, по ссылке PDF'ка, в PDF'ке заяц^Wвсё написано.

и кто из двух?

ну ясно же

или пу или медведа.

>...текущее значение регистров ESP (Extended Stack Pointer) и EIP (Extended Instruction Pointer). На первый взгляд эта информация бесполезна, но...

Ответный удар перловцев функциональщикам: уязвимость в рекурсии!

Я вот не понимаю, кто вообще додумался на такие вещи давать право чтения кому-то кроме владельца? Безалаберность просто.

> Постоянное чтение /proc/$PID$/stat и парсинг прочитанного слегка демаскирует "атакующего".

Эта "кака" ведет себя весьма похоже на top, например. _Очень_ пристально не посмотрев - отличить нельзя.

Тем более, что постоянно "вести себя плохо" подобная программа не обязана - достаточно ей следить за определенным процессом shell, пока тот не наплодит что-то более интересное (sudo, su).

Что характерно -- на Emacs не испытывали :)

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

Выбирайте безопасность, выбирайте Emacs!

Тогда уже Java, ибо отследить по этим регистрам что именно делает виртуальная машина ещё сложнее :)

Каой же дырявый этот ваш линукс.

Да это _потенциальное_ узкое место безопасности, надо в ядро Линуксса ОБЯЗАТЕЛЬНО включить патч от http://grsecurity.net/ , который кроме всего прочего защищает инфу в проц от лишних глаз "A restriction that allows a user to only view his/her processes"

почти каждый месяц появляется уязвимость позволяющая поднятся до рута.

Данная "уязвимость" не значительна

>Каой же дырявый этот ваш линукс.

man hardened_system

да ванильный Линукс надо патчить, но патчи есть и дистр тоже есть... А во фре нету... опенбздя имеет только нечто подобное...

>Я вот не понимаю, кто вообще додумался на такие вещи давать право чтения кому-то кроме владельца? Безалаберность просто.

Нет это свобода выбора, которую имеют те кто о её существовании знает!!!

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

Gentoo: cd /etc && rm make.profile && ln -s ../usr/portage/profiles/hardened/linux/x86/2008.0/server/ make.profile && \ emerge --oneshot binutils gcc virtual/libc && emerge -e world

DEB: http://kernelsec.cr0.org/

RPM: http://rpm.cormander.com/repo/grsec/

Чето-та не работает на дебиане/sid с 2.6.29-2-686. только от рута показывает эти поля:

start_stack: 0
esp: 0
eip: 0

> Эта "кака" ведет себя весьма похоже на top

o_O А что, top уже запрашивает данные несколько сотен раз в секунду?

> Тем более, что постоянно "вести себя плохо" подобная программа не обязана - достаточно ей следить за определенным процессом shell, пока тот не наплодит что-то более интересное (sudo, su).

Это как? В пдф по ссылке говорят, что они отлавливали специфические последовательности состояний регистров. --> частые запросы к /proc.

По ссылке, кстати, обсуждали три возможных варианта защиты

1) ограничить число запросов 10 в секунду
2) отдавать данные через неравные промежутки времени
3) выдавать по запросу не реальное состояние регистра, а некое
кешированное значение.

По ссылке много букв. Кто-нибудь может вкратце объяснить, как именно используется эта информация.

>Другие Unix-подобные системы (например Solaris и FreeBSD) не предоставляют информацию о регистрах, но предоставляют другую информацию, которую можно использовать для подобных атак.

Нет, ничего не предоставляет:

% ls /proc/
total 1
dr-xr-xr-x 2 root wheel 2B 10 авг 00:07 .
drwxr-xr-x 18 root wheel 24B 17 авг 03:38 ..
% uname -a
FreeBSD rio.fire 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Sun Aug 16 17:57:24 VOLST 2009 root@rio.fire:/usr/obj/usr/src/sys/RIO amd64

Рещето, ну ктож не то!

> o_O А что, top уже запрашивает данные несколько сотен раз в секунду?

Да (тот что из procps, умеет, по крайней мере). Не по-умолчанию, конечно, но в зависимости от опции. Так что без трассировки отличить нельзя (это, кстати, упомянуто в работе).

> Это как? В пдф по ссылке говорят, что они отлавливали специфические последовательности состояний регистров. --> частые запросы к /proc.

(1) Мониторим запуск интересных процессов из shell. (2) Как только запущено пользователем что-то типа su - начинаем опрашивать /proc/pid/stat. Только на втором этапе действительно нужны частые запросы к /proc.

их там предложено много более трех, например:

4) вынести состояние регистров в отдельный файл с более ограниченным доступом (только для пользователя)

5) забивать определенные поля /proc/$pid/stat нулями (в зависимости от того, кто читает)

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

Вас послушать, так Windows самая удобная и в меру безопасная система.

> Нет, ничего не предоставляет:

А что, во FreeBSD вообще никак не получить никакую информацию о процессах, да? И ps там видимо нету?

> Нет, ничего не предоставляет:

Читай доку, перчик, во FreeBsd и соплярисе всё ещё хуже и проще:

FreeBSD... ... Howevers, we found that other information released by procfs can lead to similar attacts. A prominent example is the system time reported by /proc/pid/status a file open to every user. ...

А твоя бета, конешна, кошерна, но таки бета.

А вообще интересно, можно ли сделать девайс подбирающий пароль по звуку щелканья кнопок :)

> Не по-умолчанию, конечно, но в зависимости от опции.

Мой мануал говорит, что нет. Предел около 100 раз в секунду, по умолчанию задержка 3 сек.

* ’d’ - Delay time 3.0 seconds
-d : Delay time interval as: -d ss.tt (seconds.tenths)
Specifies the delay between screen updates

> Так что без трассировки отличить нельзя (это, кстати, упомянуто в работе).

По структуре запросов, но не по частоте.

> 1) Мониторим запуск интересных процессов из shell.

Какова у вас задержка между набором команды, оканчивающимся нажатием enter и набором пароля? Вопрос риторический.

Думается, что тут тоже запросы должны следовать минимум по 10-20 штук в секунду. Хотя это, конечно, меньше, чем на второй стадии.

Против этих двух нашлись существенные возражения, поэтому я их приводить не стал ;)

> Против этих двух нашлись существенные возражения, поэтому я их приводить не стал ;)

народ вроде как раз к (4) склоняется: http://lkml.org/lkml/2009/8/16/307

> Мой мануал говорит, что нет. Предел около 100 раз в секунду, по умолчанию задержка 3 сек.

ну, имелось в виду - "порядка сотни раз в секунду ;-) Это как раз то что надо, при мониторинге "интересных" для злоумышленника процессов. А вторую стадию можно сделать непродолжительной (для ssh, su, sudo - не более десятка секунд).

>А что, во FreeBSD вообще никак не получить никакую информацию о процессах, да?

Почему же, можно. Пользователь по умолчанию видит только свои процессы. Чтобы увидеть чужие, нужно в sysctl ключик специальный выставить, но это делается от root'a.

>И ps там видимо нету?

Есть, но не про вашу честь.

> не удивлюсь, если он скажет, кто в России будет президент в будущем.

Путин.

> Почему же, можно. Пользователь по умолчанию видит только свои процессы.

Ну тогда ГОЛАКТЕКО БЕЗОПАСНОСТЕ =).

Если стоит sysctl security.bsd.see_other_uids=0
то никаких чужих процессов ты не видишь. Вообще нигде.

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

iZEN уже сказал.

>А вообще интересно, можно ли сделать девайс подбирающий пароль по звуку щелканья кнопок :)

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

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

:-)

<trollmode>Так что ваш ляликс - решето ещё то ! :) </trollmode>