Gld Format String Flaws and Buffer Overflows

а что такое "Greylisting демон"?

>а что такое "Greylisting демон"?

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

Отношение к этой технике у аксакалов ммм... неоднозначное, :), так например "неправильные" почтари полезут в backup MX и нафлудят там, и приходится там давать поболее задержку. Разумеется это не панацея - нужен целый комплекс мер.

Какое то время успешно юзал. Кому интересно - apt-cache show postgrey.

вдогонку..

man http://www.greylisting.org/

новость о вреде postfix'а вобщем
нормальные пацаны сами знаете что юзают :))

>новость о вреде postfix'а вобщем
>нормальные пацаны сами знаете что юзают :))

ну и при чем тут пофикс?? это ошибка в gld.
а правильные пацаны конечно юзают сендмыл ;)))

> ну и при чем тут пофикс?? это ошибка в gld.

Это ошибка архитектуры. "нормальные пацаны" не работают на приеме почты с правами root-а и вне chroot-а.

>Это ошибка архитектуры. "нормальные пацаны" не работают на приеме почты с правами root-а и вне chroot-а.

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

>кеше правильных серверов


И чтобы вести этот кеш нужно иметь рутовые права?! Однозначно в помойку. Вместе с поцфиксом.

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

А что, в твоей системе есть документированный способ выйти из chroot?

Ты действительно недопонимаешь. В правильно спроектированной системе тебе необходимо найти сразу ТРИ эксплоита: а) заставить того, кто слушает TCP 25 исполнить твой код, б) выбраться из chroot, в) получить права root.

Ну проломал ты аналог gld, допустим, а дальше-то что? Файлы ты читать писать не можешь (сидишь в пустом chroot без прав на запись), на память, процессор и файловые дескрипторы у тебя жестокие лимиты, с внешним миром общаешься через заренее открытые сокеты, новых открыть не можешь, поскольку запрещено, процессы, которые тебя слушают, тебе не доверяют. Даже форкнуться нельзя. И что?

Слишком идеализированное представление о chroot :)

2baka-kun

Вы представляете из чего состоит exploit ? если нет то могу на пальцах объяснить. По сути exploit состоит из 2-х частей: первая часть вызывает buffer overflow (может еще что-нибудь, по buffer overflow наиболее распространен), вторая часть запускает shell-код (состоит из нопов, части определяющей адреса в памяти, int 80 (linux) и пр), так вот, если написать довольно грамотный shell-код, то никакой chroot вас не спасет, постольку поскольку, мне в chroot-окружении не нужно иметь shell, gcc и прочую лабуду, все уже будет забито в в моем shell-коде (не на C, а прямо в hex). Можете порыскать по архивам LOR, где-то есть обсуждение о полезности chroot.

chroot просто отпугнет скрипт-кидди, но если Ваш сервер будут ломать целеноправленно, то, увы, Вас chroot не спасет.

> если написать довольно грамотный shell-код, то никакой chroot вас не спасет

Дело не только в chroot, а в _комплексе_ мер. Я описал подход реально существующей и работающей системы. При чем тут shell и gcc, если средствами ядра ты ни одного дескриптора открыть не сможешь? Ты даже пару лишних килобайт памяти не получишь, лимиты впритык рассчитаны. Или твой shell-код настолько грамотный, что из ring3 умудряется работать напрямую с железом минуя ядро? И при этом умещается в те жалкие 10-20 кб, которые ты сможешь наскрести? Это еще при условии, что тебе повезло, и в системе исполняемые стек и куча. ;)

молодой человек, это у _Вас_ вот такой код:

main(){ execl("/bin/sh","/bin/sh",0); }

весит килобайты (у меня 4Kb), увы, если переписать на asm, то размер у такой вещи будет исчисляться байтами, так что не надо лечить про "жалкие" килобайты и комплексы мер.

>лимиты впритык рассчитаны И сколько же postfix'у надо лимитов? :)

Добавь еще к этому MAC-acls от SELinux или GRSec.

с чего это в chroot /bin/bash вдруг появился ? :)

Борисыч.
Или ты не понимаешь чего-то элементарного, или я, читая вашу беседу, туплю, но:

шеллкод, чтобы ты знал, исполняется в контексте атакуемого процесса. То бишь с euid, рутом и прочим сопутствующим. Как, пардон, ты собираешься выламываться из чрута?! Оговорюсь: речь идёт о нормальной реализации чрута (у ленуксового некоторое время назад были с этим проблемы). Скажи вот мне общую идею - как.

//Loseki

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

//Loseki

>порыскать по архивам LOR, где-то есть обсуждение о полезности chroot.

а конкнетрее можно? Я бы почитал.

>Как, пардон, ты собираешься выламываться из чрута?!

Возможно все это уже давно залатано, а когда-то это делали так.

1. AFIAK в чрутнутой среде доступен (был?) вызов mknod, и сие означает, что можно наваять девайс a-la

mknod("/dev/kmem", 0667, 0xkmem_device);

далее читаем интересную повесть про RUNTIME KERNEL KMEM PATCHING, скажем здесь http://www.l0t3k.org/biblio/kernel/english/runtime-kernel-kmem-patching.txt

2. А если нам еще доступен (?) и mount, то чего бы не сваять /dev/hda ?

Дальше объяснять надо ? :)

Когда-то еще вот этим баловались :)

http://www.bpfh.net/computing/docs/chroot-break.html

Вот еще интересное обсужнение..

http://www.linuxquestions.org/questions/archive/4/2002/12/3/38915

> Дальше объяснять надо ? :)

Да!

Эх, Alter-Alter, кто же тебе в chroot права root даст? Все вменяемые приложения делают setuid() (например ssh) и все, больше ни mknod, ни mount, ни одна из описанных атак работать не будут.

>Все вменяемые приложения делают setuid() (например ssh)

Таки прям все ? :) Таки прям все вменяемые ? :)

P.S.
Речь насколько я понять шла о там, что апликация эксплоиться до root.. Таки да?

> Таки прям все ? :) Таки прям все вменяемые ? :)

Вменяемые - все, если не делают, то это их проблемы.

>P.S. >Речь насколько я понять шла о там, что апликация эксплоиться до root.. Таки да?

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

в grsec вот что есть (в vanilla значит такого нет:) :
Deny mounts
Deny double-chroots
Deny pivot_root in chroot
Enforce chdir("/") on all chroots
Deny (f)chmod +s
Deny fchdir out of chroot
Deny mknod
Deny shmat() out of chroot
Deny access to abstract AF_UNIX sockets out of chroot
Protect outside processes
Restrict priority changes
Deny sysctl writes
Capability restrictions

так что без соответствующих патчей, chroot грош цена.

>так что без соответствующих патчей, chroot грош цена.

borisych - дык! :) Подкинь еще идей что ли как возможно "выламываться из чрута?!"

>Enforce chdir("/") on all chroots

это я так понимаю от проказников?

mkdir(TEMP_DIR,0755)
dir_fd=open(".",O_RDONLY)
chroot(TEMP_DIR)
fchdir(dir_fd)

for(x=0;x<1024;x++) {
chdir("..");
}

chroot(".");

To Alter.

> Возможно все это уже давно залатано, а когда-то это делали так.

Я так понимаю, для FreeBSD-шного jail подобное не сработает никогда. Вопрос -- безопасно ли в jail-е запускать приложения от root'а?

>Вопрос -- безопасно ли в jail-е запускать приложения от root'а?

Я (скормно и потупив глаза) не являюсь к сожалению специалистом по *BSD и безопасности и правдиво на этот вопрос не смогу ответить. :)

4Alter:

Ах! Столько усилий, и всё зазря.
Специально для страдающих избирательной куриной слепотой я _цитирую_:

"Оговорюсь: речь идёт о нормальной реализации чрута (у ленуксового некоторое время назад были с этим проблемы)."

Ну и что теперь делать со всеми твоими примерами? Борисыч твой там палка грудь бил, что шеллкод - это сила сама по себе. Вот я его и прошу силу продемонстрировать. Универсально. Для всех состем.

//Loseki

2Loseki

дура, здесь форум не про bsd, а про linux.

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

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

//Loseki

>дура, здесь форум не про bsd, а про linux.
4borisych:

Я бы, канеш, поверил тебе на слово. Я что - я доверчивый. Но простыня новостей главной страницы говорит мне, что не всё просто, как тебе кажется.

Впрочем, если ты и дальше будешь настаивать на своём, люди, которые обсуждают тут темы bsd, соляркы, aix'оы, hp-ux'оы и прочими unix flavours несомненно совершат акт суицида, дабы не травмировать твою ранимую детскую психику тем, чего, по твоему мнению, нет и быть не может :(

//Loseki

4phicus:

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

Ошибки есть везде, от них никто не застрахован.
Просто где-то вероятность наткнуться на них больше, где-то меньше ;)

//Loseki

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

>Какая ерунда. В прямо реализованном чруте такого быть не должно.

>//Loseki

Мой юный друг, ты ведь можешь расшифровать, что есть chroot? Если нет, то вот тебе подсказка - change root.

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

Системный вызов chroot в Linux выполняет именно то, что от него требуется - смена коренного каталога, больше он ничего делать не обязан, поэтому даже "взлом chroot" абсолютно некорректная фраза в том контексте, что был здесь предоставлен.

cp /bin/sh /empty

chroot /empty /empty/sh

mknod /tmp/sda1 b 8 1

mount /tmp/sda1 /mnt

/mnt/bin/something

Этот пример не является "взломом" chroot, т.к. запуск был совершен из /mnt/bin/something, поэтому, мой юный друг, идите изучайте основы проектирования ОС.

То, о чем вы говорите, это не работа chroot, а организация jail или чего-то подобного, что решают FreeBSD jail, SELinux, Solaris containers, vserver и т.п.

2 Loseki
>Ах! Столько усилий, и всё зазря.

Ну почему же - весьма увлекательная и познавательная прогулка вышла

P.S.
Ты чё такой скрипучий ?

> Дурацкий какой-то вопрос.

Чем именно?

> Если можно не запускать от рута - не запускай.

А если не от root'а запускать нельзя... За примерами далеко ходить не надо -- samba.

> Если на этой машине лежат банковские проводки за 2004ый год (хы-хы)

Информация подобного рода за прошедшие годы у меня хранится обычно на лентах в сейфе ;)

> вынеси своё приложение, которое хочешь в jail'е крутить, на отдельную машинку.

М-да... И чем это мне поможет? Если приложение действительно ТАК критично, то у меня оно работает И на отдельной машине, И в jail-е. Понимаю, что-то параноидальное в этом есть. НО иногда лучше передобдеть, чем недобдеть. Или переBSDдеть -- забыл как правильно ;).

> Ошибки есть везде, от них никто не застрахован. Просто где-то вероятность наткнуться на них больше, где-то меньше ;)

Я не говорю про ошибки by implementation. Я спрашиваю именно про ошибки by design -- *по замыслу jail* возможно ли такое?

Дауш, чо-т я увлёкся и mknod прошляпил.
Сымаю шляпу, дяденька!

//Loseki

4phicus:
>Я не говорю про ошибки by implementation. Я спрашиваю именно про ошибки by design -- *по замыслу jail* возможно ли такое?

Нет.
Рут в jail'e таки ограничен в своих действиях.

//Loseki

Да, за ночь тут успели почти все обсудить ;)

>> Enforce chdir("/") on all chroots

> это я так понимаю от проказников?

Ответ на общеизвестное свойство FreeBSD не давать сделать chroot(), если у процесса есть открытые директории (читай, твой пример там не работает). По дефолту это защита во фре работает если процесс уже в chroot. Поведение можно менять через sysctl.

> Т.е. всего навсего смена коренного каталога.

Угу. Но у нас ведь unix-way. И я говорил о _комплексе_ мер. Тут вот что получается при нормальном подходе: чтобы выйти из chroot (на тех системах, где это возможно), нужны права суперпользователя; чтобы получить root, необходимо выйти из chroot, поскольку у тебя под руками нет даже процессов с suid-root, которые можно попробовать ломануть. Единственный выход: получать права ядра, но с такой дырявой системой уже любая "секурность" пофигу. ;)

Да, и еще один момент. С вероятностью 99.(9)% на моих серверах недоверяемый процесс получил chroot() на разделе с nodev (а вы как-то иначе монтируете /usr и /home? Тогда мы идем к вам ;) ), а возможно еще и с noexec (а вы как-то иначе монтируете /var ? Хм...)

2baka-kun

>лимиты впритык рассчитаны

Повторю вопрос. Сколько же postfix'у надо лимитов?

> Повторю вопрос. Сколько же postfix'у надо лимитов?

Кто тебе сказал, что я говорил про постфикс? Понятия не имею, какому его процессу сколько сейчас надо, сам подсчитай.

> Никакой дополнительной безопасности это не дает.

Даёт в связке с setuid. И хорошо даёт.

> Поэтому любой может создать файл устройства

Соврал, батенька. Суперпользователь может и только, а не _любой_.