BugTraq.Ru
Русский BugTraq
https://bugtraq.ru/rsn/archive/2012/06/03.html

Обход парольной защиты в линуксовых MySQL: уязвима половина доступных серверов
dl // 12.06.12 11:48
Некорректное приведение типов в процедуре проверки паролей ряда сборок MySQL и MariaDB приводит к тому, что с вероятностью 1/256 удается выполнить подключение, используя любой пароль - достаточно знать имя пользователя (ну а root-то там обычно бывает).
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2012/06/03.html]
Затронуты версии вплоть до 5.1.61, 5.2.11, 5.3.5, 5.5.22. Разумеется, во многих конфигурациях MySQL закрыт для всех коннектов снаружи, но так бывает далеко не всегда. Ну и героический брутфорс открывает все двери за пару-тройку сотен попыток, на что уйдет менее секунды.

Уязвимые версии собраны с использованием функции memcmp из оптимизированной под SSE линуксовой glibc. Встроенная memcmp из gcc незатронута, как и memcmp из BSDшной libc.

В пересчете на реальные операционные системы, затронуты 64-битные Ubuntu версий 10.04, 10.10, 11.04, 11.10, и12.04, Fedora и OpenSUSE 12.1. Чисты Debian, Gentoo и RHEL, равно как и официальные сборки MySQL и MariaDB. Быстрое сканирование 1.74 миллиона доступных MySQL-серверов показало, что уязвимы практически 50 процентов. Звучит довольно апокалиптично - просто представьте, что половина всех доступных MySQL-серверов прямо сейчас стоит с настежь открытой дверью.

Источник проблемы - возврат функцией целочисленного значения за границами диапазона -127..128. Вообще, возвращаемым значением функции memcmp является целое число, про которое можно лишь утверждать, что оно меньше, больше, либо равно нулю в зависимости от результата сравнения переданных ей блоков памяти. Разработчики понадеялись на то, что этот результат можно безболезненно привести к своему псевдобулевскому типу (typedef char my_bool) - что, строго говоря, справедливо лишь для указанного диапазона (при подобном преобразовании просто отбрасываются старшие биты и 0x100 окажется эквивалентно 0x00). Но с учетом описания функции как возвращающей int, этого никто никогда и не обещал.

Источник: The Register    
теги: mysql  |  предложить новость  |  обсудить  |  все отзывы (2) [10433]
назад «  » вперед

аналогичные материалы
Квартальные патчи Oracle: махнула ли компания рукой на безопасность своей базы? // 18.01.12 16:55
Взлом MySQL.com // 27.09.11 09:34
MySQL.com взломали через SQL injection // 28.03.11 16:43
Мегапатч от Apple // 29.03.10 21:53
HighLoad++ - программа конференции // 30.09.08 17:33
Sun собралась прикупить MySQL // 16.01.08 19:37
Конференция по PHP // 13.08.04 15:13
 
последние новости
Бэкдор в xz/liblzma, предназначенный для атаки ssh-серверов // 30.03.24 17:23
Три миллиона электронных замков готовы открыть свои двери // 22.03.24 20:22
Doom на газонокосилках // 28.02.24 17:19
Умер Никлаус Вирт // 04.01.24 14:05
С наступающим // 31.12.23 23:59
Четверть приложений, использующих Log4j, до сих пор уязвима // 11.12.23 18:29
Google Drive находит файлы // 07.12.23 01:46

Комментарии:

"Да это просто праздник какой-то!" (c)Карабас-Барабас 13.06.12 14:14  
Автор: stream <Roman Trunov> Статус: Member
<"чистая" ссылка>
"Да это просто праздник какой-то!" (c)Карабас-Барабас

Проблема не в -1/0/1, а тупом преобразовании результата memcmp к некому типу my_bool (скорее всего, обычному char). Классическая реализация memcmp обрабатывает байт за байтом, с ней проблемы не будет. А оптимизированная небось обрабатывает по несколько байт за раз, вычитая полное слово - возвращает что-то типа 0x12345600 - последний байт 0x00 - добро пожаловать, люди добрые!
да, я уже потом посмотрел. надо будет поправить 13.06.12 16:39  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
<добавить комментарий>





  Copyright © 2001-2024 Dmitry Leonov Design: Vadim Derkach