В выпусках (http://www.bugzilla.org/security/4.0.14/) 4.0.14, 4.2.10, 4.4.5 и 4.5.5 системы для ведения базы данных ошибок, контроля за их исправлением и общего координирования процесса разработки BugZilla устранена опасная уязвимость (http://blog.gerv.net/2014/10/new-class-of-vulnerability-in-p.../) (CVE-2014-1572 (https://bugzilla.mozilla.org/show_bug.cgi?id=1074812)), позволяющая получить доступ новых пользователей к закрытым группам. Теоретически аналогичные ошибки могут присутствовать и в других проектах на языке Perl, использующих модуль CGI.pm и заполняющих хэши неэкранированными значениями функции param.
Проблемы вызвана непониманием особенности разбора повторяющихся параметров в URL - в случае передаи скрипту нескольких параметров с одинаковым именем, функция param модуля CGI.pm возвращает не скалярную переменную, а массив, в котором перечислены все значения подобных параметров. При заполнении хэша открытым списком по сути производится перечисление пар ключ/значение (символ "=>" в присвоении вполне может быть заменён на запятую), поэтому если вместо одного из аргументов передан массив и этот аргумент не экранирован, то можно перечислить в данном массиве имена ключей и их значение, и данные ключи будут определены в хэше.
Например, в случае запроса "index.cgi?realname=JRandomUser&realname=login_name&realname=admin@mozilla.com", переменная realname передаётся три раза, что приведёт к выдаче функцией param массива ("JRandomUser", "login_name", "admin@mozilla.com"). Если в коде присутствует присвоение "realname => $cgi->param('realname')", то по сути этот блок можно отождествить с конструкцией ("realname", "JRandomUser", "login_name", "admin@mozilla.com"), что аналогично представлению (realname => "JRandomUser", login_name => "admin@mozilla.com"), т.е. осуществлено определение нового ключа "login_name". Простейшим способом устранения проблемы является явное определение скалярного типа переменной, т.е. указание "realname => scalar $cgi->param('realname')".
Используя данный метод выявившие уязвимость исследователи безопасности смогли (http://www.checkpoint.com/blog/bug-bug-tracker/) завести (https://bugzilla.mozilla.org/show_bug.cgi?id=1074812) аккаунты с доступом к закрытым областям BugZilla проекта Mozilla, обойдя стадию верификации почтового адреса. Уязвимость использовалась для передачи фиктивного email в момент определения группы пользователя - bugzilla автоматически назначает новых пользователей в группы, на основании проверки email (например, можно вместо реального адреса, заполнить поле значением в поддомене @mozilla.com, при том, что изначально для верификации использовался совершенно другой адрес).Одним из векторов атаки может быть получение доступа к записям, в которы отвечающие за безопасность команды разработчиков могут обсуждать ещё не исправленные уязвимости, до их придания огласке. BugZilla достаточно широко используется для координации внесения исправлений в открытых проектах, например, применяется сообществами
Apache, LibreOffice, Mozilla, ядра Linux , OpenSSH, Eclipse, KDE, GNOME.URL: http://krebsonsecurity.com/2014/10/bugzilla-zero-day-exposes.../
Новость: http://www.opennet.me/opennews/art.shtml?num=40766
:-D красиво!
fail. Удивительно, как можно делать столь сильные предположения о типе переменной в динамическом яп, особенно таком как перловка.
Как можно вообще использовать в web языки с динамической типизацией?!? (что есть уже потенциальная проблема)
> Как можно вообще использовать в web языки с динамической типизацией?!? (что есть
> уже потенциальная проблема)А ты чо, часто на сях сайтики пишешь? :D
Так теперь основной объем дыр - в вебне и прочей скриптятине...
http://bloodhound.apache.org/
> http://bloodhound.apache.org/Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /.Reason: Error reading from remote server
Apache/2.2.22 (Ubuntu) Server at bh-demo2.apache.org Port 443
> Apache/2.2.22 (Ubuntu) Server at bh-demo2.apache.org Port 443Единственное чего полезного отсюда можно узнать - что про забивон апачистов на бзды не врут. Опач под убунтой, однако :).
>CGI.pm
>2014
знакомые буквы увидел?
Я всегда охреневал от людей, которые вообще CGI.pm используют. Его достаточно один раз открыть, чтобы понять, что его писал героиновый наркоман. Эталонный кусок перл-говнокода.И Bugzilla сама тоже хороша, я её форк пилю уже лет 5, планомерно говнокод (и CGI.pm тоже, ага) оттуда выкашивая. Хочу допилить и потом опубликовать где-нибудь с намёком на то, что "эй смотрите мазильщики, я тут ваш говнокод немного в чувство привёл"...
а им патчи отослать, не?
Бессмысленно, там столько переделано, что живого места нет. Даже если умудриться это как-то разбить на патчи (что просто АБСОЛЮТНО НЕРЕАЛЬНО), авторы изменения всё равно не примут.Да и не хочется уже ничего им отправлять, они там дикие говнокодеры, на некоторые вещи реально страшно смотреть было.
Даже смержить с 4.4 почти нереально (моя форкнута от 3.6). Хотя и невелика беда, там всё равно никаких масштабных фич не появилось.
Я раньше ещё стеснялся и как-то ограничивал себя, чтобы совсем ВСЁ не перехреначивать - думал мержить же потом... а сейчас надоело и я просто переделываю ВСЁ, что мне отсвечивает.
Хочу уже доделать и как форк зарелизить.
> Я всегда охреневал от людей, которые вообще CGI.pm используют.Да весь CGI - протокол для тех кто хочет по мелочи сэкономить сначала и много и героически долбаться потом.
Я правильно понял, что надо написать примерно так:%hash = (key=>$cgi->param('key'));
??
Так НЕ надо писать... Надо писать %hash = (key => scalar $cgi->param('key'));Иначе если передать несколько значений key, то у тебя весь хеш "поедет" - контекст списочный, cgi->param вернёт список всех значений, и часть из них станет ключами, т.к. "=>" - синоним запятой.
А ещё лучше ВООБЩЕ НЕ ЮЗАТЬ $cgi->param - даже если используется CGI.pm, то просто стырить себе куда-нибудь все параметры в виде хеша и хавать их оттуда. Причём $cgi->Vars возвращает криво tie'енный хеш, так что нужно просто в цикле вытаскивать все параметры.
Ну или вообще юзать какой-нибудь PCGI.pm.
Эмм, я как раз и имел ввиду, что так писать не надо, и если так написать - то именно так и схватишь уязвимость. 0)В чем кривизна $cgi->Vars(), если это можно в двух словах описать?
Если у какого-то ключа несколько значений, то в $cgi->Vars значением этого ключа будут просто сконкатенированные все эти значения. Т.е. из строчки &a=1&a=1 получится { a => '11' }.
ух-ты, прикольно. Спасибо за разъяснение.)
А, кстати нет, с PCGI та же хрень - он вообще не умеет хеш значений вернуть...
сам повысил свои привилегии, потом сам же и пофиксил с новыми привилегиями :)
Зря смеетесь. На практике был случай убираения проблемного демео скрипта bash как cgi через уязвимость shellshock