> А че, никсы тоже юзают флат-модель памяти? Почему в них > вообще возможно переполнение? > Ведь при сегментной организации выход за границы > отведенного под буфер сегмента не возможен (будет эксепшн).
Тут идет речь о переполнении буфера в стеке, и модель памяти тут не имеет значения. Вот классичекий пример:
int verify()
{
char s[10];
gets(s);
return strcmp(s, "mypass");
}
---
Если ввести строку > 10 символов, то можно перезаписать на стеке адрес возврата из этой функции, т.е. передать управление в любую точку программы. Обычно передают управление на свой код в стеке, помещенный в переменную s.
Кстати в некоторых Юниксах страницы стека имеют такие атрибуты защиты, что читать/писать стек можно, а исполнять код в стеке - нет. Вот тогда большинство подобных атак обламывается. Но если я не ошибаюсь, это только на платформах, отличных от Intel 80x86.
Теоретичекий вопрос про права программ и не только29.05.02 04:47 Автор: Renkvil <Boris> Статус: Member Отредактировано 29.05.02 20:49 Количество правок: 1
Во всех мануалах предлагается запускать потенциально опасные программы (или вирусы ;-) ) под Линукс из-под юзера с не root-правами, ибо он навредит лишь себе.
Мне бы хотелось поближе ознакомиться с механизмами, блокирующими работу программы.
Ведь она уже загружена в память и код выполняется.
Все переполнения буфера основаны на получении прав, выходящих за рамки программы с "дыркой" путём исполнения кода, прямиком в процессор.
Возможно ли сэмулировать виртульный режим, в котором переполнения буфера невозможны, и как это реализуется, хотя бы в теории.
Далее хотелось бы классифицировать все варианты удалённого вторжения с получением прав любого пользователя системы и отдельно root'а (процессора ;-) ), или возможностью выполнять желаемые действия (исполнять код..)
Например Unicode Bug, Buffer Overflow...
Буду признателен, если вы укажите любые, более-менее конкретные ссылки в этих направлениях, или хотя бы на что-то натолкнёте.
А че, никсы тоже юзают флат-модель памяти? Почему в них вообще возможно переполнение?
Ведь при сегментной организации выход за границы отведенного под буфер сегмента не возможен (будет эксепшн).
> А че, никсы тоже юзают флат-модель памяти? Почему в них > вообще возможно переполнение? > Ведь при сегментной организации выход за границы > отведенного под буфер сегмента не возможен (будет эксепшн).
Тут идет речь о переполнении буфера в стеке, и модель памяти тут не имеет значения. Вот классичекий пример:
int verify()
{
char s[10];
gets(s);
return strcmp(s, "mypass");
}
---
Если ввести строку > 10 символов, то можно перезаписать на стеке адрес возврата из этой функции, т.е. передать управление в любую точку программы. Обычно передают управление на свой код в стеке, помещенный в переменную s.
Кстати в некоторых Юниксах страницы стека имеют такие атрибуты защиты, что читать/писать стек можно, а исполнять код в стеке - нет. Вот тогда большинство подобных атак обламывается. Но если я не ошибаюсь, это только на платформах, отличных от Intel 80x86.
Почему рискну? Хороший ответ!29.05.02 21:47 Автор: Renkvil <Boris> Статус: Member Отредактировано 29.05.02 21:49 Количество правок: 1
> > Мне бы хотелось поближе ознакомиться с механизмами, > > блокирующими работу программы. > > Механизм: установлены права на файлы и проч. Чужие файлы ты > не сотрешь.
Как этот механизм в общих чертах работает?
Какой процесс, какая часть ядра отвечает за это?
> > Все переполнения буфера основаны на получении прав, > > выходящих за рамки программы с "дыркой" путём > исполнения > > кода, прямиком в процессор.
> Не понял... Права - ТЕ ЖЕ, что у проги с дыркой... Только > надо найти дырявую прогу с правами рута (если хочешь рута).
Спасибо. Хороший момент.
> Прямиком в процессор - это как?! Это жзащищенныйрежим.
Это тоже хороший момент, про который я временно забыл.
Т.е. то про что я хотел узнать в этом подвопросе, называется защищённый режим.
Иногда простейшие вещи выпадают из головы, пока не напомнят. ;-)
> И проги все - это, что называется, пространство > пользовательское. Даже проги рута.
Т.е. если все запущенные сервисы на машине запущены не от рута, то рута удалённо не получить?
спасибо на добром слове...30.05.02 12:30 Автор: Dude Статус: Незарегистрированный пользователь
Сервисы рута – я такого не говорил. Я говорил, «прога рута», что тоже не совсем корректно, но если я скажу: "Процесс, имеющий uid=0 или euid=0", - то так лучше? Речь идет о Линуксе, поэтому думаю что да.
0) Какие именно части ядра отвечают за проверку привилегий - не знаю, но как это происходит, представить не очень сложно. Просто каждая функция ядра (init не при чем, как говорят тут некоторые), которая для процессов с низкими привилегиями должна себя вести иначе, чем для процессов с высокими (работа с файлами, сигналами, ...) проверяет эти привилегии, прежде чем выполнять требуемые действия.
1) С помощью только традиционных переполнений буфера получить uid=0 или euid=0 из процесса, не имеющего их, НЕЛЬЗЯ. Ведь что происходит: выполняется процесс с низкими привилегиями, после переполнения буфера в память этого процесса попадает твой код, и если все нормально, то процесс продолжает выполняться как ни в чем не бывало, с теми же привилегиями, со ВСЕМ тем же. Просто вместо одного кода – другой. Если бы можно было повысить свои права так, то всякий юзер мог бы написать свою какую-то программу (не эксплоит чужой программы, а свою независимую программу), запустить ее как юзер, и получить рута. Может ли это быть?
2) Да, это может быть, но переполнения тут не при чем. Возможно, тебя это заинтересует.
Вся реальная работа выполняется ядром, и, если его обдурить, то все окей. А обдурить уязвимое ядро можно, причем, поскольку системные вызовы могут вызывать ВСЕ, то привилегии не играют роли.
Так, ядра Линукс ниже 2.2.19 (в ветке 2.2, но поскольку некоторые ранние из 2.4 вышли раньше, чем 2.2.19, то и 2.4.0, и некоторые другие) имеют уязвимость «ptrace/execve race condition». Суть ошибки я плохо знаю (частично суть в том, что ptrace устанавливает процессу тот euid, который указан на файле, соответственно эксплоит работает с любым suid-файлом: запускает такой процесс и приписывает – ptrace позволяет - к нему шелл-код), а выглядит использование эксплоита со стороны, примерно так: садится юзер за машину с Линуксом с ядром, скажем, 2.4.0, без единой дырявой программы, и через секунду имеет рутшелл. (эксплоит есть на секьюритифокусе и называется epcs.c)
Примерно в тех же ядрах, говорят, были глюки в syscall, позволявшие писать в память ядра.
Аналогично, ядра до 2.4.12 (по крайней мере; про те, что выше, не знаю) – «ptrace/setuid exec vulnerability» - тоже local root. Этот эксплоит я никогда не тестил, но говорю то, что написано на securityfocus’е.
(Это все можно найти на securityfocus, примерно под такими же названиями).
То есть единственное, при чем тут может быть переполнение, это при том, чтобы удаленно получить хотя бы низкопривилегированный шелл, а потом повысить свои привилегии (если, конечно, ядро соответствующее).
> Как этот механизм в общих чертах работает? > Какой процесс, какая часть ядра отвечает за это? процесс - по-моему init или ядро напрямую, хотя я могу ошибаться. С доступам к файлам - все просто есть 12 бит, отвечающие за доступ к файлу. Это право на чтение, исполнения и записи в файл для владельца, группы, к которой владелец принадлежит и всех остальных (получается 9). Дополнительные 3 бита - это пользовательский S бит, групповой S бит и sticky - бит (сейчас почти не используется). Установленный s-бит означает то, что программа будет запущена с привилегиями владельца, а не юзера, запустившего файл.
Вот на этом и основаны атаки с использованием переполнения буфера. Например, есть программа passwd, которая менят пароль пользователя. Очевидно, что ей необходимо иметь доступ на запись в файл shadow (master-passwd), а это право есть только у рута (by default). У файла passwd установлен юзерский s-бит, то есть она всегда будет стартовать от имени root. Если вызвать переполнение буфера, и с помощью этого изменить адрес возврата из процедуры, можно выполнить свой код с правами root.
> Т.е. если все запущенные сервисы на машине запущены не от > рута, то рута удалённо не получить? да, например apache редко когда запускается от имени root, обычно от nobody. Часть сервисов правда работают от имен bin и daemon, а это в принципе, тоже, что и root.
Почему рискну? Хороший ответ!30.05.02 23:18 Автор: Renkvil <Boris> Статус: Member
> процесс - по-моему init или ядро напрямую, хотя я могу > ошибаться. С доступам к файлам - все просто есть 12 бит, > отвечающие за доступ к файлу. Это право на чтение,
Я буду нуден: где именно хранятся эти 12 бит?
> > Т.е. если все запущенные сервисы на машине запущены не > от > > рута, то рута удалённо не получить? > да, например apache редко когда запускается от имени root, > обычно от nobody. Часть сервисов правда работают от имен > bin и daemon, а это в принципе, тоже, что и root.
А как делаются дефейсы, можно ведь ограничить nobody?
> А как делаются дефейсы, можно ведь ограничить nobody? Значит у nobody есть право на изменение файла главной страницы, или apache работает с правами root. Настроить нормально права nobody можно, также можно проверить скрипты на дырявость, только админам в падлу этим заниматься, поэтому и дефейсят их сайты.
Почему рискну? Хороший ответ!29.05.02 21:59 Автор: ZloyShaman <ZloyShaman> Статус: Elderman
> Т.е. если все запущенные сервисы на машине запущены не от > рута, то рута удалённо не получить? Хмы. В основном не сервисы "рута" (как вы его называете :)) важны, а сервисы с привилегией system. Вот они-то есть всегда. Эт точно.
А вообще етсь ништячная книжка "Внутренне устройство Windows 2000". Соломон и Руссинович написали. Крутые ребята. Я думаю тебе она будет интересна.
Почему рискну? Хороший ответ!29.05.02 22:04 Автор: Renkvil <Boris> Статус: Member
> > Т.е. если все запущенные сервисы на машине запущены не > от > > рута, то рута удалённо не получить? > Хмы. В основном не сервисы "рута" (как вы его называете :)) > важны, а сервисы с привилегией system. Вот они-то есть > всегда. Эт точно.
Тогда ясно...
> А вообще етсь ништячная книжка "Внутренне устройство > Windows 2000". Соломон и Руссинович написали. Крутые > ребята. Я думаю тебе она будет интересна.
Вообще мне про Линукс, но это тоже будет интересно.
ну ты и рискнул29.05.02 21:45 Автор: ZloyShaman <ZloyShaman> Статус: Elderman
> Механизм: установлены права на файлы и проч. Чужие файлы ты > не сотрешь. Мякго говоря, там всё немного глубже...
> > Все переполнения буфера основаны на получении прав, > > выходящих за рамки программы с "дыркой" путём > исполнения > > кода, прямиком в процессор. Кстати да, вот про такое я не слышал. Каждая программа (в 2000 уже даже и 16-разрядная) выполняется в своём пространстве памяти. И что-то мне не кажется, что получится вылезти за рамки атакуемой программы. А вот презаписать исполняющийся в данный момент код - это да.
> Прямиком в процессор - это как?! Это жзащищенныйрежим. > И проги все - это, что называется, пространство > пользовательское. Даже проги рута. Видимо имелось в виду, что поскольку этой программе выдано разрешение выполянться на процессоре :)) то если некоторый кусок её кода будет заменён, то всё равно он выполнится на процессоре.
А вообще, человек явно просил не такого ответа.
Сэнкс за ответ29.05.02 21:57 Автор: Renkvil <Boris> Статус: Member
> > Механизм: установлены права на файлы и проч. Чужие > файлы ты > > не сотрешь. > Мякго говоря, там всё немного глубже...
Можно чуть поподробнее?
Я практичекски не знаком с этими механизмами.
> > > Все переполнения буфера основаны на получении > прав, > > > выходящих за рамки программы с "дыркой" путём > > исполнения > > > кода, прямиком в процессор. > Кстати да, вот про такое я не слышал. Каждая программа (в > 2000 уже даже и 16-разрядная) выполняется в своём > пространстве памяти. И что-то мне не кажется, что > получится вылезти за рамки атакуемой программы. А вот > презаписать исполняющийся в данный момент код - это да.
Т.е. прога, не имеющая прав читать /etc/passwd его не прочитает, даже если через неё будет выполнен buffer overflow?
> > Прямиком в процессор - это как?! Это жзащищенный > режим. > > И проги все - это, что называется, пространство > > пользовательское. Даже проги рута. > Видимо имелось в виду, что поскольку этой программе выдано > разрешение выполянться на процессоре :)) то если некоторый > кусок её кода будет заменён, то всё равно он выполнится на > процессоре.
Угу. ;-)
> А вообще, человек явно просил не такого ответа.
На самом деле я в настоящий момент рад вообще любым замечаниям по теме и смежным темам, конкретным ответа - втройне.
А просто вопрос можно выразить так: можно ли выйти за рамки программы, запущенной с правами не-root'а, путём переполнения буфера в ней или иначе?
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
