ID: 49687 Updated by: scott...@php.net Reported By: sird at rckc dot at -Status: Open +Status: Feedback Bug Type: *Unicode Issues Operating System: * PHP Version: 5.2.11 New Comment:
On a 16-bit processor an int might be 16-bit, if you can get PHP to compile then well done :-) Did you even try running the test code? Previous Comments: ------------------------------------------------------------------------ [2009-10-16 01:36:27] sird at rckc dot at : ras...@php.net It has come to my attention that this hasn't been fixed.. unsigned int has a size of 16 bits, don't take my word for it http://www.acm.uiuc.edu/webmonkeys/book/c_guide/1.2.html Section: 1.2.2 Variables unsigned int 16 bits I just downloaded PHP 5.2.11, and I quote the code: // php-5.2.11.tar.bz2/php-5.2.11/ext/xml/xml.c#558 PHPAPI char *xml_utf8_decode( // ... { int pos = len; char *newbuf = emallo // ... unsigned int c; // sizeof(unsigned int)==16 bits char (*decoder)(unsig // ... xml_encoding *enc = x // ... // ... // #580 c = (unsigned char)(*s); if (c >= 0xf0) { /* four bytes encoded, 21 bits */ if(pos-4 >= 0) { c = ((s[0]&7)<<18) | ((s[1]&63)<<12) | ((s[2]&63)<<6) | (s[3]&63); } else { c = '?'; } s += 4; pos -= 4; // ... Also no checking at ALL is made on the leading bytes (they should be in the form: 10xx xxxx, a check is very easy, to check if s[0] has the correct form: you do an AND with 1100 0000 and then compare it with 1000 0000. s[0]&0xC0==0x80 Also, Overlong UTF is not being taken care of, that's yeah, yet another vulnerability. Greetings!! ------------------------------------------------------------------------ [2009-09-29 05:29:22] sird at rckc dot at the rest is still dangerous.. eating chars without the 10xx xxxx is against the spec, and overlong UTF. ------------------------------------------------------------------------ [2009-09-29 04:56:08] ras...@php.net > there are several bugs in the code, one of them is that a variable holding the value of the char is overflowed (trying to put 21 bits in a 16 bits int) That was fixed in 5.2.11 ------------------------------------------------------------------------ [2009-09-29 01:58:37] sird at rckc dot at it is a PHP bug, the function is not decoding correctly, check the ppt and the acunetix blog for details. there are several bugs in the code, one of them is that a variable holding the value of the char is overflowed (trying to put 21 bits in a 16 bits int), also the code is not checking if it is a valid unicode char (reading unicode specification should explain it). the example r...@80sec gave you was an overlong utf representation of a single quote. that is forbidden by unicode, and should transform the char to ?. also, the code is not checking if the chars are valid UTF, so stuff like: <img alt="\x90" title=" src=x:x onerror=alert(1)//"> are going to be transformed to <img alt="? title=" src=x:x onerror=alert(1)//"> this is a very serious vulnerability and there are several bugs in the same function (there's even unreachable code). you can check the implementation of utf by Mozilla or Webkit, they do it right. dont use java as a reference since they are also flawed. due to the fact that PHP is for web applications and utf is widely used, and it allows an attacker to do all type of attacks (from sql injection to xss) its imperative to fix that function. Greetings!! ------------------------------------------------------------------------ [2009-09-28 19:38:24] sjo...@php.net Is this a bug in PHP or in scripts which do utf8_decode(addslashes()) instead of addslashes(utf8_decode())? What do you propose to solve this bug? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/49687 -- Edit this bug report at http://bugs.php.net/?id=49687&edit=1
