В модуле mod_rewrite популярного HTTP-сервера Apache серии 2.2.x обнаружена интересная уязвимость (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-1862) (CVE-2013-1862), позволяющая удаленному злоумышленнику выполнить произвольную команду в момент просмотра лог-файла администратором сервера.
Уязвимость обусловлена тем фактом, что mod_rewrite при записи в лог-файл не экранирует специальные символы, что позволяет удаленному злоумышленнику, при помощи специально оформленных запросов к веб-серверу, записать туда, например, управляющие последовательности для терминала. При правильном манипулировании такими последовательностями, можно добиться запуска произвольных команд с правами пользователя, осуществлявшего просмотр лога (как правило, подобные лог-файлы доступны для чтения только пользователю root).
Доступен патч (http://people.apache.org/~jorton/mod_rewrite-CVE-2013-1862.p...), исправляющий данную уязвимость. К настоящему моменту проблема исправлена в RHEL (https://rhn.redhat.com/errata/RHSA-2013-0815.html) и CentOS (http://lists.centos.org/pipermail/centos-announce/2013-May/0...). Разработчики Debian в курсе наличия уязвимости, однако не считают (https://security-tracker.debian.org/tracker/CVE-2013-1862) возможность удаленного запуска команд с правами root серьезной угрозой безопасности («Such injection issues are not treated as security issues»). Разработчики Gentoo также осведомлены (https://bugs.gentoo.org/show_bug.cgi?id=CVE-2013-1862) о наличии уязвимости, однако пока не предпринимали каких-либо шагов для ее исправления.URL: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-1862
Новость: http://www.opennet.me/opennews/art.shtml?num=36932
в nginx (и не только, хотя апача в том списке не было)
тоже было 3 года назад )
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-4487
Неоспоримое достоинство текстового формата лога - на одни и те же грабли можно наступать множество раз, потому что экранировать должен тот, кто пишет, а не тот, кто читает.
Не холивара ради, а ответа для: SQL-инъекции придумали куда раньше. Но еще раньше появились криворукие кодеры.... Так что я вряд ли почувствую себя таким дофига защищенным, если обще-системный лог у меня будет автоматом заливаться в СУБД.
> Не холивара ради, а ответа для: SQL-инъекции придумали куда раньше.Что характерно - SQL-инъекции существуют именно из-за использования текста как промежуточной формы обмена данными (строка запроса). При обмене через чисто бинарный API (да даже и через prepared statements) они отсекаются как класс.
> Так что я вряд ли почувствую себя таким дофига защищенным, если обще-системный лог у меня будет автоматом заливаться в СУБД.
Классическим реализациям syslog, СУБД - как телеге пятое колесо. Все фишки уже прогажены на этапе формирования сообщения в формате plain text, так что полезный выход практически нулевой. Починить это можно разве что программой, которая парсит логи, сортируя записи по классам и разделяя их на поля, после чего пишет в базу.
Но гораздо проще - не убивать полезную информацию кривым дизайном.
> Но гораздо проще - не убивать полезную информацию кривым дизайном.Не UNIX way.
Настоящий UNIX way - создать себе трудности, а потом героически их преодолеть. Дополнительные бонусы начисляются, если трудности созданы при помощи комбайнов.Например, классический лог-файл - типичный комбайн as is: создан в расчете на то, что его должны легко читать как человек, так и машина. В результате, как обычно, ни одного зайца не догнали.
> Например, классический лог-файл - типичный комбайн as is: создан в расчете на то, что его должны легко читать как человек, так и машина. В результате, как обычно, ни одного зайца не догнали.Впрочем, надо отметить, большинство форматов конфигов (INI и ему подобные) все-таки стали приятным исключением из этого "как обычно". Но применить этот полезный опыт на логах пока никто не попытался.
>> Например, классический лог-файл - типичный комбайн as is: создан в расчете на то, что его должны легко читать как человек, так и машина. В результате, как обычно, ни одного зайца не догнали.
> Впрочем, надо отметить, большинство форматов конфигов (INI и ему подобные) все-таки стали
> приятным исключением из этого "как обычно". Но применить этот полезный опыт
> на логах пока никто не попытался.А как вы будите порсить логи в случае если хард посыпется или еще что случится с файлом бд?
Если логи лежат вместе со всеми данными в базе? Ну, допустим, есть бэкапы, но логи все равно надо бы глянуть, чтобы иметь представление в какой момент все пошло не так.
Просто в логи надо писать только необходимую инфу, которая понадобится при анализе.
Плюс каким образом, без извращений, "грепнуть" логи из базы, особенно если демон бд в дауне?
> Плюс каким образом, без извращений, "грепнуть" логи из базы, особенно если демон бд в дауне?Лучше скажи, как ты грепаешь в логе нагруженного сервака на хренадцать гигз "все обращения от 5 до 7 числа такого-то месяца с вон того айпишника". И сколько времени это занимает.
База то по индексам такое сможет довольно быстро лукапать. А вот текстовую портянку придется прочесть ВСЮ, отсеяв все что не попало под критерий. Так что аналитика больших логов грепом получается не слишком пресной.
> Лучше скажи, как ты грепаешь в логе нагруженного сервака на хренадцать гигз
> "все обращения от 5 до 7 числа такого-то месяца с вон
> того айпишника". И сколько времени это занимает.Увольняю админа нафиг. Ротация неадекватная (гигабайты в одном файле), выноса логов на отдельную машину нет, несоответствует должности.
грепать тысячу файлов по мегабайту не легче чем грепать один на гигабайт.
иначе - теряется информация, что не всегда приемлемо
если это действие одноразовое, да к тому же нужна информация за определённый период — то не надо грепать все логи за 100500 лет работы сервера.а если нужна именно «аналитика», то не ясно, кто мешает перенести логи в любимую БД и там уже навыбираться по самое удовлетворение.
Ну вот если у вас есть такие портянкии необходиомсть оперативно в них что-то искать - то и индексируйте, кто ж вам меашет? Индексированию текстовый формат лога ну никак не помеха.
> в логе нагруженного сервака
> База то по индексам1. сколько раз в минуту ты смотришь в лог?
2. сколько раз в минуту лог пишется?
3. по каким полям индексируется?а теперь представь, какая нагрузка создаётся *на нагруженном серваке* при записи лога в базу (INSERT + индекс). Осталось только писать в лог ещё и сообщения о записи лога, для полного счастья.
Стоит ли это того, чтобы раз в день получить индексированную инфу?> А вот текстовую портянку придется прочесть ВСЮ
grep в текстовом файле выполняется обычно на порядки быстрее, чем SELECT WHERE даже если с индексом. Потому что
1. греп оперирует текстом, а не записями - нет оверхеда на создание кучи объектов
2. греп не требует парсинга запроса
3. греп не требует составления плана запроса
4. греп не требует держать весь индекс БД в памяти
5. греп читает из одного файла, с информацией обычно записанной линейно, не требуя seek по файлу. Скорость обработки байтов на проце - гигабайты/сек, поэтому при чтении с не-супер-быстрого RAID нагрузка на проц от грепа будет практически незаметна.
6. греп не требует базы, может быть запущен в любой момент и в любой момент прерван по ctrl-c.Вывод: лог в SQL-базе - это бред.
> Лучше скажи, как ты грепаешь в логе нагруженного сервака на хренадцать гигз
> «все обращения от 5 до 7 числа такого-то месяца с вон
> того айпишника». И сколько времени это занимает.это занимает примерно столько времени, сколько надо, чтобы написать приказ об увольнении идиота, у которого «логи сервака на хренадцать гигз», не ротируются, никуда ремотно не уходят, и он занимается «грепом логов» на нагруженом боевом сервере (называя это «аналитикой»).
> Не UNIX way.Unix way ничего не говорит о формате данных.
> Но гораздо проще - не убивать полезную информацию кривым дизайном.Удивлён текстовым представлением Ваших бесценных комментариев.
Отстает апач, отстает...
Тогда ждем обнаружения в апаче аналога http://www.opennet.me/opennews/art.shtml?num=36875
>>Разработчики Debian в курсе наличия уязвимости, однако не считают возможность удаленного запуска команд с правами root серьезной угрозой безопасности
я фигею без баяна !
> я фигею без баяна !это просто «пиривотчек» дегенерат.
> это просто «пиривотчек» дегенерат.Кто о чем, а arisu о своем :)
нет, не о своём, об опеннетовском.
Разработчики Debian считают, что настоящая уязвимость - это удаленная запись управляющих последовательностей для терминала.Добавьте к новости, что разработчики Debian изнасиловали переводчика.
>я фигею без баяна !я фигею с Петросяна переводчика.
а можна пример escape-последовательности, которая при выводе в терминал через cat/tail выполняет команды?
Присоединяюсь к вопросу
> Присоединяюсь к вопросудобавляю дополнительный вопрос!:
существуют ли esc-последовательности, которые при выводе на экран -- переключают терминал в режим доминирования над человеком?...
[ну тоесть человек, прочитавший текст, написанный в этом режиме доминирования, -- выполняет беспрекословно то что прочитал...]
* * * * * * * * *
и ещё хочу выяснить такие esc-последовательности, напечатав которые компьютер ВЗРЫВАЕТСЯ БАБАХ!!! (что-то такое точно должно быть!).. и даже в случае если esc-последоватености посылаются удалённо на терминал компьютера, компьютера который в данный момент отключён от питания (но включена батарейка на материнской плате).
# P.S.: вот кстате почему батарейку на материнской плате -- нужно тоже вынимать -- после отключения питания компьютера..
Сдаётся мне, что при таком поведении терминала уязвимость не в mod_rewrite, а в терминале.
> Сдаётся мне, что при таком поведении терминала уязвимость не в mod_rewrite, а в терминале.Уязвимость терминала в том, что он выполняет функции терминала? Вот так новость.
Херассе функции.Так полсистемы уязвимо будет - даже специально сформированным word документом, пропустив его через catdoc, можно будет rm -rf / сделать.
Только при наличии уязвимости в catdoc, разумеется.
и всетаки, если по делу, - кто может показать пример, а не пустописанием заниматься?
Безусловно.Непонятно, в чем смысл эмулировать эти функции алфавитно-цифровых терминалов сегодня.
Присоединяюсь к вопросу. Подобные ескейп-комманды - это явная дыра в терминале.
Не могу дать законченного ответа, но имею предположение. По-крайней мере в urxvt есть т.н. perl-extensions, к которым можно обращаться через esc-seqs. Как подсказывает ман надо делать так:echo -en '\e]EXT:PARAMS\a'Вместо EXT пишем имя extension'а, вместо PARAMS его параметры. Но к чему это приведёт -- я не знаю, просто когда-то, выясняя зачем urxvt тянет perl промеж прочих bdeps, выяснил наличие такой esc-последовательности.
вот как (
> как правило, подобные лог-файлы доступны для чтения только пользователю rootЭто где такие правила? На шаредах, например, админу логи апача нахрен не нужны, в отличие от клиентов.
> Это где такие правила? На шаредах, например, админу логи апача нахрен не нужны, в отличие от клиентов.На шаредах клиентов к ним и не подпускают. В классическом случае, ими занимается техподдержка - студенты на полставки. Как правило, с рутовым доступом.
> На шаредах клиентов к ним и не подпускают.они прям в домашней директории лежат у клиента среднестатистического шаред-хостинга :) ...туда сразу и пишутся
> не считают возможность удаленного запуска команд с правами root серьезной угрозой безопасностиЭто вообще-то передергивание и личное мнение автора.
>> не считают возможность удаленного запуска команд с правами root серьезной угрозой безопасности
> Это вообще-то передергивание и личное мнение автора.Не передергивайте. Это личное мнение разработчиков Debian.
> Это вообще-то передергивание и личное мнение автора.на опеннете это считается нормальным. тут нормальным считается даже написание «пиривотчиком» МегаПеревода со смыслом, противоположным оригиналу.
> на опеннете это считается нормальным. тут нормальным считается даже написание «пиривотчиком»
> МегаПеревода со смыслом, противоположным оригиналу.Эээ... в оригинале разработчики дебиана очень переживали, сокрушались, и спешили срочно исправить? Переведите правильно, голубчик, будьте так добры!
Rasch abkochen, dann Vormarsch nach Sokal.
> Rasch abkochen, dann Vormarsch nach Sokal.Вы таки полагаете, что новости на опеннете должны быть написаны в таком стиле?
Не читай логи - спи спокойно =)
> Не читай логи - спи спокойно =)Тогда так и не узнаешь, как тебя взломали. Хотя, не знать об этом - тоже важно для спокойного сна.
Sieve
В Советской России логи читают администратора.
$ cat >tmp
^[[A^[[D^[[B^[[C
$ less tmp
ESC[AESC[DESC[BESC[C
tmp (END)Расходимся?
там в виде байтов а не символов
> там в виде байтов а не символовВ Юникоде нет байтов.
>> там в виде байтов а не символов
> В Юникоде нет байтов.ты записал тупо текст, такое не сработает
> ты записал тупо текст, такое не сработаетВнимательнее. Я тупо нажал четыре стрелки, которые загнали в файл esc-последовательности, что и показал less.
$tail tmp?
ССЗБ
> $tail tmp
$less +G tmp!Вообще, что за детский сад для админов локалхостов? Читайте маны, они рулят.
$ man man
> пользователю rootОдна проблема. Во многих дистрибутивах, говоря формально, нет пользователя root.
>> пользователю root
> Одна проблема. Во многих дистрибутивах, говоря формально, нет пользователя root.в каких? насколько формально? куда он делся?
еще один вендузятник о своем болоте запел
> Одна проблема. Во многих дистрибутивах, говоря формально, нет пользователя root."Только гиена и павиан" (с)
>> Одна проблема. Во многих дистрибутивах, говоря формально, нет пользователя root.
> "Только гиена и павиан" (с)$ grep root </etc/passwd
$
> $ grep root </etc/passwd
$ grep -G hyena </etc/passwd
hyena:x:1000:1000:Hyaena Brunnea,,,:/home/hyena:/bin/bash
ну так не пользуйся бубунтой.
Господа, но нельзя же так.cat(1), tail(1), head(1) и классическая more(1) небезопасны при выводе на текстовый терминал.
Об этом говорят в любом курсе по администрированию, начиная с появления VT52, VT100 и иже с ними (так называемых "smart terminals", англ. "хитрожопых терминалов").
Если не умеете termcap(5) или аналоги, пользуйтесь less(1). Изучите ее ключи. "GNU less" хорошая программа с разумными умолчаниями, люди старались.
less != tail
"less +G" лучше, чем "tail".
> «less +G» лучше, чем «tail».а чем заменить «tail -f»?
less +F
вот хитрые какие, умеют маны читать…
man man