Re: [Full-disclosure] Critical PHP bug - act ASAP if you are running web with sensitive data
Peter Conrad wrote: Hi, On Mon, Apr 03, 2006 at 11:06:01PM +0900, Moriyoshi Koizumi wrote: While this is not part of the HTML / HTTP standards, major browsers around try to send such characters in the user input as HTML entities that cannot all be represented in the encoding of the originating HTML page out of curiosity: can you give an example for that behaviour? I've never seen it. http://www.voltex.jp/~moriyoshi/test/demo.php Moriyoshi
Re: [Full-disclosure] Critical PHP bug - act ASAP if you are running web with sensitive data
Moriyoshi Koizumi wrote: Jasper Bryant-Greene wrote: I very much doubt there are many applications at all containing code like this. It is illogical to be decoding html entities from user input. Therefore I would not call this a "very serious problem" and certainly not a critical bug. Not really. While this is not part of the HTML / HTTP standards, major browsers around try to send such characters in the user input as HTML entities that cannot all be represented in the encoding of the originating HTML page, it's quite probable the function is used to filter the query strings. Indeed, it probably is, but hopefully the results of that are not then echoed out to the browser without running htmlspecialchars() etc on them... If they are (which is the root of this "security problem") then that is the fault of the idiot who wrote the code, not PHP. You can only protect users from their own stupidity to a certain degree... -- Jasper Bryant-Greene General Manager Album Limited http://www.album.co.nz/ 0800 4 ALBUM [EMAIL PROTECTED] 021 708 334
Re: [Full-disclosure] Critical PHP bug - act ASAP if you are running web with sensitive data
On 3/29/06, Jeff Rosowski <[EMAIL PROTECTED]> wrote: > It also doesn't affect all versions of PHP. on 5.0.5, it returns \0 > followed by however many Ss you put after it. And your right you wouldn't > trust user imput like that. > > ___ I get this behaviour on php v5.0.4 on windows box
Re: [Full-disclosure] Critical PHP bug - act ASAP if you are running web with sensitive data
Jasper Bryant-Greene wrote: Moriyoshi Koizumi wrote: Jasper Bryant-Greene wrote: I very much doubt there are many applications at all containing code like this. It is illogical to be decoding html entities from user input. Therefore I would not call this a "very serious problem" and certainly not a critical bug. Not really. While this is not part of the HTML / HTTP standards, major browsers around try to send such characters in the user input as HTML entities that cannot all be represented in the encoding of the originating HTML page, it's quite probable the function is used to filter the query strings. Indeed, it probably is, but hopefully the results of that are not then echoed out to the browser without running htmlspecialchars() etc on them... If they are (which is the root of this "security problem") then that is the fault of the idiot who wrote the code, not PHP. You can only protect users from their own stupidity to a certain degree... OK, ignore that, forgot what we were talking about for a while there :) htmlspecialchars() should still be run on the output, otherwise you have another security hole, but of course that won't protect against sending memory contents back to the user... -- Jasper Bryant-Greene General Manager Album Limited http://www.album.co.nz/ 0800 4 ALBUM [EMAIL PROTECTED] 021 708 334
Re: [Full-disclosure] Critical PHP bug - act ASAP if you are running web with sensitive data
Jasper Bryant-Greene wrote: Tõnu Samuel wrote: Nice! I was really nervous already as I got bombed with e-mails and I really did not knew much more than was discovered. Meanwhile I am bit disappointed that we had nearly month such a bug in wild and software distributors like SuSE in my case did not published patches. I think as long enough time passed and I hope distributors maybe need to see it - I publish exploit. Sorry, this was discovered independently and for me it looks like very serious problem. Script is: I very much doubt there are many applications at all containing code like this. It is illogical to be decoding html entities from user input. Therefore I would not call this a "very serious problem" and certainly not a critical bug. Not really. While this is not part of the HTML / HTTP standards, major browsers around try to send such characters in the user input as HTML entities that cannot all be represented in the encoding of the originating HTML page, it's quite probable the function is used to filter the query strings. Moriyoshi Jasper
Re: [Full-disclosure] Critical PHP bug - act ASAP if you are running web with sensitive data
really did not knew much more than was discovered. Meanwhile I am bit disappointed that we had nearly month such a bug in wild and software distributors like SuSE in my case did not published patches. I think as long enough time passed and I hope distributors maybe need to see it - I publish exploit. Sorry, this was discovered independently and for me it looks like very serious problem. Script is: I very much doubt there are many applications at all containing code like this. It is illogical to be decoding html entities from user input. Therefore I would not call this a "very serious problem" and certainly not a critical bug. It also doesn't affect all versions of PHP. on 5.0.5, it returns \0 followed by however many Ss you put after it. And your right you wouldn't trust user imput like that.
Re: [Full-disclosure] Critical PHP bug - act ASAP if you are running web with sensitive data
I very much doubt there are many applications at all containing code like this. It is illogical to be decoding html entities from user input. Therefore I would not call this a "very serious problem" and certainly not a critical bug. Somewhat I agree. I suspected this may affect more functions that only this one and was very alarmed. I never digged around in PHP source and was not able to verify it fast. So if PHP developer says, it is affects only on function, this is fine. There are application which are known to use it. Like http://www.phpmyfaq.de/, so I attacker may use social engineering easily to gain access to such feature. I am security auditor and 90% cases I get to goal combining using bunch of small, useless problems. Sorry if you do not see problem. EOD :).
Re: [Full-disclosure] Critical PHP bug - act ASAP if you are running web with sensitive data
Tõnu Samuel wrote: Nice! I was really nervous already as I got bombed with e-mails and I really did not knew much more than was discovered. Meanwhile I am bit disappointed that we had nearly month such a bug in wild and software distributors like SuSE in my case did not published patches. I think as long enough time passed and I hope distributors maybe need to see it - I publish exploit. Sorry, this was discovered independently and for me it looks like very serious problem. Script is: I very much doubt there are many applications at all containing code like this. It is illogical to be decoding html entities from user input. Therefore I would not call this a "very serious problem" and certainly not a critical bug. Jasper
Re: [Full-disclosure] Critical PHP bug - act ASAP if you are running web with sensitive data
Hello, just to stop this: The bug is a binary safety issue in html_entity_decode. A function that is not usually used on user input, because user input is usually not expected in HTML format and then decoded. Even if the function is used on user input it can only leak memory to a potential attacker if the decoded user input is send back to the client. The bug was found in late February by one of the japanese PHP developers and was fixed in CVS one day later. Because the bug is a local memory leak it was not considered top critical and is among the usual bugfixes. PHP 5.1.3-RC1 which was released in the beginning of March already fixes this issue. Stefan
