我今天早上打開電腦,在seclists中看到一個(gè)很驚人的thread:http://seclists.org/oss-sec/2012/q2/493MySQL爆出了一個(gè)很大的安全漏洞，幾乎影響5.1至5.5的所有版本。出問題的模塊是登錄時(shí)密碼校驗(yàn)的部分(password.c)，在知道用戶名的情況下（如root），直接反復(fù)重試（平均大約256次）即可登入。不過，MySQL身份認(rèn)證的時(shí)候是采用3元組，username,ip,password。如果client的IP在mysql.user表中找不到對(duì)應(yīng)的，也無法登陸。
這個(gè)BUG實(shí)際上早在4月份就被發(fā)現(xiàn)了，今年5月7號(hào)，MySQL發(fā)布5.5.24的時(shí)候，修正了這個(gè)BUG。
漏洞分析：
出問題的代碼如下/* Check that scrambled message corresponds to the password; the function is used by server to check that recieved reply is authentic. This function does not check lengths of given strings: message must be null-terminated, reply and hash_stage2 must be at least SHA1_HASH_SIZE long (if not, something fishy is going on). SYNOPSIS check_scramble() scramble clients' reply, presumably produced by scramble() message original random string, previously sent to client (presumably second argument of scramble()), must be exactly SCRAMBLE_LENGTH long and NULL-terminated. hash_stage2 hex2octet-decoded database entry All params are IN. RETURN VALUE 0 password is correct !0 password is invalid*/my_boolcheck_scramble(const uchar *scramble_arg, const char *message, const uint8 *hash_stage2){ SHA1_CONTEXT sha1_context; uint8 buf[SHA1_HASH_SIZE]; uint8 hash_stage2_reassured[SHA1_HASH_SIZE]; mysql_sha1_reset(&sha1_context); /* create key to encrypt scramble */ mysql_sha1_input(&sha1_context, (const uint8 *) message, SCRAMBLE_LENGTH); mysql_sha1_input(&sha1_context, hash_stage2, SHA1_HASH_SIZE); mysql_sha1_result(&sha1_context, buf); /* encrypt scramble */ my_crypt((char *) buf, buf, scramble_arg, SCRAMBLE_LENGTH); /* now buf supposedly contains hash_stage1: so we can get hash_stage2 */ mysql_sha1_reset(&sha1_context); mysql_sha1_input(&sha1_context, buf, SHA1_HASH_SIZE); mysql_sha1_result(&sha1_context, hash_stage2_reassured); return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE);}
memcmp的返回值實(shí)際上是int，而my_bool實(shí)際上是char。那么在把int轉(zhuǎn)換成char的時(shí)候，就有可能發(fā)生截?cái)�。比如，memcmp返回0×200，截?cái)嗪笞兂闪?，調(diào)用check_scramble函數(shù)的就誤以為“password is correct“。
但是一般來說，memcmp的返回值都在[127,-128]之內(nèi)。glibc的經(jīng)SSE優(yōu)化后的代碼，不是如此。所以這個(gè)BUG只在特定的編譯環(huán)境下才會(huì)觸發(fā)：即編譯MySQL的時(shí)候加了-fno-builtin，并且所使用的glibc是經(jīng)SSE優(yōu)化后的（一般系統(tǒng)自帶的都是如此）。這里所說的glibc是指Linux的glibc，F(xiàn)reeBSD的libc不受影響。
總的來說這個(gè)BUG還是比較嚴(yán)重的，上次MySQL出現(xiàn)這樣的BUG還是在3.23/4.0時(shí)代。
發(fā)表于 2012-6-19 20:35
| 
發(fā)表于 2012-6-19 22:17
| 
