中国真实偷乱视频,东京道一本热中文字幕,久久精品国产99国产精品亚洲,欧美激情一区二区三区在线

Board logo

標(biāo)題: [建議] 建議管理員在wdcp下把mysql版本升級到最新版本 [打印本頁]

作者: 霹靂小魚    時(shí)間: 2012-6-19 20:35     標(biāo)題: 建議管理員在wdcp下把mysql版本升級到最新版本

mysql 5.1.61存在權(quán)限漏洞,建議管理員升級到最新版本
作者: admin    時(shí)間: 2012-6-19 22:17

具體是哪個(gè)漏洞?有沒地址發(fā)來看下
作者: 霹靂小魚    時(shí)間: 2012-6-20 09:41

http://seclists.org/oss-sec/2012/q2/493
作者: admin    時(shí)間: 2012-6-20 09:42

這個(gè)跟編譯環(huán)境有關(guān)的
你下載一鍵包里的安裝看看,有沒這問題?
作者: 霹靂小魚    時(shí)間: 2012-6-20 09:42

可以百度搜索:mysql身份認(rèn)證漏洞
作者: kideny    時(shí)間: 2012-6-20 15:16

我今天早上打開電腦,在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表中找不到對應(yīng)的,也無法登陸。
這個(gè)BUG實(shí)際上早在4月份就被發(fā)現(xiàn)了,今年5月7號,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)境下才會觸發(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í)代。

原文鏈接: http://www.udpwork.com/redirect/7463




歡迎光臨 WDlinux官方論壇 (http://ahbydz.com/bbs/) Powered by Discuz! 7.2