Luka 0day w sql/password.c

[Miłosz 2311]

Luka bezpieczeństwa dotyczy MySql oraz MariaDB.

Więcej informacji: http://seclists.org/oss-sec/2012/q2/493

[krk 2]

nie groźna luka

[xorg 693]

Ciekawe.

 

Jakis szybki sposob na sprawdzenie buga istnieje ? Bo nie wiem czy przysiadac do patchowania.

[xorg 693]

Mógłby ktoś skompilować ? Nie mam u siebie gcc ani nic podobnego.

Edytowano Czerwiec 11, 2012 przez xorg (zobacz historię edycji)

[Syndrom 95]

regdos bez obrazy, ale tylko tak dla potomych, jeśli już chcecie puszczać binarki to najpierw w jakimś testowym środowisku strace

[regdos 1848]

@Syndrom bez obrazy ale @Xorg prosił o kompilację o nic więcej więc to zrobiłem.

[lazy 33]

@Syndrom bez obrazy ale @Xorg prosił o kompilację o nic więcej więc to zrobiłem.

 

tylko to trzeba skompilowac na systemie na ktorym chcemy zweryfikowac "podatnosc",

bez tego duzo bedzie fałszywych alarmow bo zwykle wszystko jest kompilowane conajmniej z -O2 i wtedy jest duza szansa ze uzyta bedzie implementacja nie prowokujaca luki w mysqlu

 

jesli u ciebie gcc inlinował swoja niepodatna wersje memcmp() to wszedzie bedzie pokazywac ze jest ok,

 

do tego z opcjami takimi jak skompilowany został mysql np. takie -O2 robi roznice ktora implementacja zostanie uzyta

 

--

Lazy

Edytowano Czerwiec 11, 2012 przez lazy (zobacz historię edycji)

[Kalmar 0]

Uśmiałem się..

@regdos @xorg Problem wynika z optymalizacji w gcc, więc gratuluję pomysłu sprawdzania podatności przez uruchomienie skompilowanej binarki. Profesjonaliści...

 

Domyślny mysql z paczek w ubuntu jest podatny (a przynajmniej w 11.10 64bit - sprawdziłem).

Ogólnie ciekawe, że nikt nie zauważył takiej luki wcześniej, przewiduję dużo wycieków baz z amatorskich hostingów.

[kcp 41]

Info z niebezpiecznika:

MySQL podatne na ataki
Jak na razie potwierdzono, że poniże systemy są podatne na ten błąd:
Ubuntu Linux 64-bit (10.04, 10.10, 11.04, 11.10, 12.04)
OpenSuSE 12.1 64-bit MySQL 5.5.23-log
Fedora 16 64-bit
Arch Linux (unspecified version)

 

Więcej info: http://niebezpieczni...-zostac-rootem/

 

A tu z innego źródła:

So far, the following systems have been confirmed as vulnerable:
   Ubuntu Linux 64-bit ( 10.04, 10.10, 11.04, 11.10, 12.04 ) ( via many including @michealc )
   OpenSuSE 12.1 64-bit MySQL 5.5.23-log ( via @michealc )
   Debian Unstable 64-bit 5.5.23-2 ( via @derickr )
   Fedora 16 64-bit ( via hexed )
   Arch Linux (unspecified version)
Feedback so far indicates the following platforms are NOT vulnerable:
   Official builds from MySQL and MariaDB (including Windows)
   Red Hat Enterprise Linux, CentOS (32-bit and 64-bit) [ not conclusive ]
   Ubuntu Linux 32-bit (10.04, 11.10, 12.04, likely all)
   Debian Linux 6.0.3 64-bit (Version 14.14 Distrib 5.5.18)
   Debian Linux lenny 32-bit 5.0.51a-24+lenny5 ( via @matthewbloch )
   Debian Linux lenny 64-bit 5.0.51a-24+lenny5 ( via @matthewbloch )
   Debian Linux lenny 64-bit 5.1.51-1-log ( via @matthewbloch )
   Debian Linux squeeze 64-bit 5.1.49-3-log ( via @matthewbloch )
   Debian Linux squeeze 32-bit 5.1.61-0+squeeze1 ( via @matthewbloch )
   Debian Linux squeeze 64-bit 5.1.61-0+squeeze1 ( via @matthewbloch )
   Gentoo 64-bit 5.1.62-r1 ( via @twit4c )
   SuSE 9.3 i586 MySQL 4.1.10a ( via @twit4c )
   OpenIndiana oi_151a4 5.1.37 ( via @TamberP )

Edytowano Czerwiec 11, 2012 przez kcp (zobacz historię edycji)

[voti 19]

The MySQL bug (casting of the int to char, which may lead to truncation) exists in MySQL code base since 4.x versions. However, it only is an issue when used with memcmp() implementation that can return values out of the -255 .. 255 range.

 

memcmp() function is defined as:

 

int memcmp(const void *s1, const void *s2, size_t n);

 

It returns an integer less than, equal to, or greater than zero if the first n bytes of s1 is found, respectively, to be less than, to match, or be greater than the first n bytes of s2.

 

memcmp() implementations often return values that do not use full range of the int type and rather return one of the following:

 

- normalized values (-1/0/1)

- diff of the first non-equal bytes (this is a documented behavior of BSD libc

implementation, but also a behavior of the gcc builtin implementation used on x86 architectures)

 

A glibc x86_64 SSE4 optimized memcmp() implementation was identified as one that returns values out of the -255 .. 255 range. Depending on the position of the first non-equal byte, it often returns value that is multiple of 256, which results in non-0 memcmp() return value to be incorrectly converted to 0 after casting the value to char type. This optimized memcmp() version is only available in recent glibc versions. Red Hat Enterprise Linux 6 is the first Red Hat Enterprise Linux version that has this optimized implementation available.

 

However, mysql packages in Red Hat Enterprise Linux 6 do not use glibc optimized memcmp() version. A gcc builtin is used in check_scramble(), which do not trigger this problem (see above).

 

This problem was tested on all Red Hat Enterprise Linux 4, 5, and 6 architectures using the latest released mysql packages and was not found to affect any version. There is no plan for an immediate update correcting this issue, it will be corrected with future mysql packages updates.

 

In Fedora, glibc memcmp() function is called from check_scramble() and hence x86_64 SSE4 systems are known to be affected by this problem.

 

https://bugzilla.red...i?id=814605#c19

[devilMedia.pl 26]

Idąc tym błędem, jest szansa (jedna na 256) aby uwierzytelnić się jako root i uzyskać dostęp do bazy danych.

Prosty przykład, nie wymagający kompilowania to wykonanie flooda w kierunku mysql, jeżeli się uda, pojawi się prompt od mysql.

for i in `seq 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; done

[Misiek08 285]

Ta podatność była często spotykana. Żeby gcc nie użyło optymalizowanych SSE ( nie wiem dokładnie, więc może źle odmieniłem), trzeba podać mu kilka flag przy kompilacji. Tak jak napisał ktoś u góry - w paczkach raczej były optymalizowane, więc podatne wersje.

[LANcaster (kotkowicz.pl) 52]

nie groźna luka

 

Na jakiej podstawie tak twierdzisz? Ja uważam, że to wyjątkowo groźna luka, szczególnie na współdzielonych hostingach.