Представлена (http://permalink.gmane.org/gmane.comp.security.oss.general/7844) детальная информация об уязвимости, исправленной в недавно выпущенных обновлениях MariaDB 5.5.23/5.3.6/5.1.62/5.2.12 (http://www.opennet.me/opennews/art.shtml?num=33589) и MySQL 5.5.24/5.1.63/5.6.6 (http://www.opennet.me/opennews/art.shtml?num=33607). Уязвимость позволяет злоумышленнику осуществить аутентифицированный вход под любым пользователем без ввода корректного пароля.
Из-за ошибки в коде сравнения хэшей от паролей, переданный пароль мог быть признан эквивалентным эталонному даже при возврате ненулевого значения функцией memcmp(), используемой для сравнения. Вероятность подобного исхода составляет 1 из 256, т.е. злоумышленник может за примерно 300 попыток подключиться к СУБД, указав любое значение в качестве пароля. Эксплуатация проблемы может быть совершена любым клиентом, без необходимости модификации libmysqlclient. Суть проблемы сводится к тому, что функция проверки пароля в MySQL определена (http://bazaar.launchpad.net/~mysql/mysql-server/5.1/view/hea...) как "my_bool
check_scramble(...)", но итоговый "return memcmp(...)" в данной функции не всегда возвращал данные в диапазоне -128..127, укладывающемся в тип my_bool, поэтому с вероятностью 1/256 возвращаемое memcmp ненулевое значение вне данного диапазона в результате приведения типов становилось нулём.Положительным моментом является то, что не все сборки
MySQL и MariaDB эксплуатируемы - очень многое зависит от того на какой платформе и как произведена сборка. Например, распространяемые разработчиками MySQL и MariaDB бинарные пакеты проблеме не подвержены. Предпосылкой к возникновению проблемы является возможность возвращения некоторыми реализациями memcmp() произвольных целых значений, не попадающих в диапазон -128..127. Например, реализации memcmp() из BSD libc и GCC не подвержены проблеме, а оптимизированная с использованием SSE-инструкций реализации memcmp() из Linux Glibc подвержена проблеме (GCC обычно использует собственную реализацию).URL: http://permalink.gmane.org/gmane.comp.security.oss.general/7844
Новость: http://www.opennet.me/opennews/art.shtml?num=34062
Вот что ты получаешь, если используешь язык программирования родом из 70-х, в котором, даже простейший булев тип, приходится сооружать из дерьма и палок.
Вот что получаешь, когда начинаешь выё...тся, понтоватся и создавать свои типы,
например my_bool. Ладно бы my_bool был бы int или Bool, так он же char.
В си нет типа Bool, есть _Bool или bool размер которого может быть и не int'ом. Морал простой - типы нужно приводить явно.
админоморда, хватит редактировать сообщения. Будешь за это гореть в аду
> Будешь за это гореть в адуEPERM
> _Bool или bool размер которого может быть и не int'ом.ISO/IEC 9899:201x
6.2.5 Types
An object declared as type _Bool is large enough to store the values 0 and 1.
6.3.1.1 Boolean, characters, and integers
— The rank of _Bool shall be less than the rank of all other standard integer types.
То есть уже по стандарту, Bool, максимум может быть (SHRT_MAX-1), т.е. (2^8/2-1)-1 = 32766;
> Морал простой - типы нужно приводить явно.Приведение типов только для лохов! :)
ну так не пиши на этом мерзком языке, запили свой обалденный язык. тебе мешает кто-то, что ли?
Не, лучше не надо, хватит уже.
> Не, лучше не надо, хватит уже.а вдруг выйдет что-то действительно крутое и гениальное?
да, с вероятностью 1 к 256
> да, с вероятностью 1 к 256но ведь не нулевой.
Вот, что получается, когда руки из *опы и мозгов ноль. Ну и про выпендрёж выше верно замечено.
осталось подобрать 300 паролей хэш которых увеличивается на 1...
интересная уязвимость впредь буду думать...
Совершенно не обязательно. Достаточно 300 разных(!).Зачем подбирать их по порядку? Если получится зайти - сразу увидишь.
знающие люди, почему BSD не подвержена? там по другому приводятся типы?
выше в статье написано почему. чукча не читатель?
> Предпосылкой к возникновению проблемы является возможность возвращения
> некоторыми реализациями memcmp() произвольных целых значений, не попадающих
> в диапазон -128..127.Ткните меня мордой !!! Где написано что memcmp() должно возвращать от -128 до 127 ????
IEEE Std 1003.1-2008
http://pubs.opengroup.org/onlinepubs/9699919799/functions/me...ISO/IEC 9899:201x
7.24.4.1 The memcmp function
Synopsis
1 #include <string.h>
int memcmp(const void *s1, const void *s2, size_t n);Description
2 The memcmp function compares the first n characters of the object pointed to by s1 to
the first n characters of the object pointed to by s2.
Returns3 The memcmp function returns an integer greater than, equal to, or less than zero,
accordingly as the object pointed to by s1 is greater than, equal to, or less than the
object pointed to by s2.
Почему в BSD по другому?!
> Ткните меня мордой !!! Где написано что memcmp() должно возвращать от -128
> до 127 ????да нигде. и strcmp() тоже не обязана. но кто ж эти дурацкие документации читает-то? а потом возникают вот такие школьные «уязвимости». или вонь про то, что memcpy() «поломали».
Эпично, что тут скажешь. my_bool вообще доставило.ЗЫ Вы всё ещё используете MySQL? Тогда слоник идёт к вам...
> Тогда слоник идёт к вам...Зелёный?
Розовый.
синий
Забыли добавить из оригинальной новости:
All MariaDB and MySQL versions up to 5.1.61, 5.2.11, 5.3.5, 5.5.22 are
vulnerable.
Пробовал убунту 12.04 64-битную, мускул 5.5.22 - не пускает и через 1к попыток.
Видимо уже исправили. У меня тоже не работает :)
Интересно... С root не прокатывает :) Зато с debian-sys-maint огого:
> Например, реализации memcmp() из BSD libc и GCC не подвержены проблеме, а оптимизированная с использованием SSE-инструкций реализации memcmp() из Linux Glibc подвержена проблеме (GCC обычно использует собственную реализацию).Интересно, я один после этих слов вспомнил срачик Линуса и Ульриха по поводу memcpy()? :))
А причём здесь memcpy()? Там всё дело в кастомном типе my_bool (lol), к которому приводиться результат выполнения memcpy. А так как memcpy возвращает int то иногда возникают проблемы при кастинге из "большего" типа в "меньший". Так что я вижу тут только проблему индусов.
Там тоже оптимизации под SSE "поломали" поведение функции.в случае memcpy() - это происходило на пересекающихся областях и по стандарту это Undefined behavior, а индусы из Adobe заложились на определенное поведение функции.
в этом случае в стандарте ничего не говорится что значения будут укладываться в диапазон -128..127, a приведение типов иногда дает 0
т.е. и тут и там проблема в индусах, [TROLL] но интересно, потребует ли тут Линус изменить поведение glibc [/TROLL]
> Интересно, я один после этих слов вспомнил срачик Линуса и Ульриха по
> поводу memcpy()? :))а разве был срачик? линусу сказали, что он дебил. линус утёрся и убежал рассказывать, как он круто всех победил.
По факту утерся Ульрих - http://www.opennet.me/opennews/art.shtml?num=33461
и это печалит.
> Один из них ты. Ущербный мозг не может знать что такое defacto
> стандарт.Ну, во-первых, "de facto", а во-вторых - http://ru.wikipedia.org/wiki/%D0%A1%D1%8...
И еще: практика показывает, что нежелание читать и, что важнее, ПОНИМАТЬ документацию часто приводит к необходимости в новых версиях городить "костыли" для поддержки некогда некорректно написаного софта. Таким образом, получаем замкнутый круг. Яркий пример - экосистема Windows. Посмотрите, как в WINE вместо реализации функций по документации приходится воспроизводить "особенности" оригинальной реализации, так как прикладные программы эти самые "особенности" используют во всю. И это же является причиной неработоспособности части программ, написанных "типа крутыми прогерами, которым чихать на документацию" и использующих "недокументированные" функции, в официально выпущенных новых версиях ситем от Microsoft - вспомните сколько воплей было по поводу VISTA, а потом и "семерки"!
Вы считаете это правильным и хотите иметь такую же ситуацию в UNIX?
он обычный php быдлокодер, у него нет никаких осознанных 'хочу'. Всё делается спинным мозгом
чудесно!
"На 1 000 000 000-й попытке сервер согласился что пароль - Мао Цзэдун"
$ for i in `seq 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; donemysql>
http://habrahabr.ru/post/145641/ вероятность взлома 1/256
программа проверки http://pastie.org/4064638
$ mysql --version
mysql Ver 14.14 Distrib 5.5.22, for debian-linux-gnu (x86_64) using readline 6.2Чего-то не могу вломиться на свой локалхостик. Не пущает :(
У меня тоже не получилось на Ubuntu 12.04 AMD64.
Попробуйте с debian-sys-maint :)
> mysql --versionmysql Ver 14.14 Distrib 5.1.56, for slackware-linux-gnu (x86_64) using readline 5.1
Тоже не получилось. Версия слаки - 13.37
Во 64bit FreeBSD не сработало:for i in `jot - 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; done
мне пофиг, ipfw+pf закрыты порты