null Byte Injection in PHP's preg_replace()
Hi list.
PHP's function preg_replace suffers from a null byte injection vulnerability
as mentioned in MOPS Submission 07.
I noticed that only some OSes seems vulnerable to this null byte injection
and I'm trying to collect some data of which for this blog post.
http://ha.xxor.se/2011/06/null-byte-injection-in-pregreplace.html
It would be greatly appreciated if a few people would run this test code and
reply the results to me.
<?php
$res = false;
@preg_replace("/test/e\x00ing/i",'$res = true;',"test");
if(false===$res)echo 'Not ';
echo "Vulnerable, PHP ".phpversion().", ".php_uname('s')." ".php_uname('r');
?>
So far, from my own tests, only PHP running on Windows 7 has proved
vulnerable. I'm specially interested in how Windows Server reacts.
Vulnerable
PHP 5.2.13, Windows 7
Not Vulnerable
PHP 5.2.13, OpenBSD 4.7
PHP 5.2.17, Linux 2.6.18
/Mango
Hi again.
Big thanks to those two who helped me by running the test code. I now
believe that my initial results where distorted by Suhosin. face palm
I thought I had done enough to check for the presence of Suhoshin
but obviously not.
Conclusion, all versions of PHP suffer from this vulnerability. Why don't
they not fix things like this?
2011/7/2 Mango h@xxor.se
Hi list.
PHP's function preg_replace suffers from a null byte injection
vulnerability as mentioned in MOPS Submission 07.
I noticed that only some OSes seems vulnerable to this null byte injection
and I'm trying to collect some data of which for this blog post.
http://ha.xxor.se/2011/06/null-byte-injection-in-pregreplace.html
It would be greatly appreciated if a few people would run this test code
and reply the results to me.
<?php
$res = false;
@preg_replace("/test/e\x00ing/i",'$res = true;',"test");
if(false===$res)echo 'Not ';
echo "Vulnerable, PHP ".phpversion().", ".php_uname('s')."
".php_uname('r');
?>
So far, from my own tests, only PHP running on Windows 7 has proved
vulnerable. I'm specially interested in how Windows Server reacts.
Vulnerable
PHP 5.2.13, Windows 7
Not Vulnerable
PHP 5.2.13, OpenBSD 4.7
PHP 5.2.17, Linux 2.6.18
/Mango
Hi,
Conclusion, all versions of PHP suffer from this vulnerability. Why
don't they not fix things like this?
If I understand the issue correctly, this would only be a security issue
if you were including user input in a regular expression pattern. I'd
normally advise against doing that at all - and if you needed to do it,
performing extensive validation, including stripping nulls.
I expect that's why it's not high-priority for PHP. They have other
null-byte issues, most notably in file names, although Suhosin does
protect these. I don't see any reason why they can't fix them in the
main line though. I notice Python, for example, doesn't have null byte
issues:
open('myfile\00', 'w')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: file() argument 1 must be encoded string without NULL bytes,
not str
Paul
2011/7/2 Mango <h@xxor.se mailto:h@xxor.se>
Hi list.
PHP's function preg_replace suffers from a null byte injection
vulnerability as mentioned in MOPS Submission 07.
I noticed that only some OSes seems vulnerable to this null byte
injection and I'm trying to collect some data of which for this
blog post.
http://ha.xxor.se/2011/06/null-byte-injection-in-pregreplace.html
It would be greatly appreciated if a few people would run this
test code and reply the results to me.
-------------------------------------
<?php
$res = false;
@preg_replace("/test/e\x00ing/i",'$res = true;',"test");
if(false===$res)echo 'Not ';
echo "Vulnerable, PHP ".phpversion().", ".php_uname('s')."
".php_uname('r');
?>
-------------------------------------
So far, from my own tests, only PHP running on Windows 7 has
proved vulnerable. I'm specially interested in how Windows Server
reacts.
Vulnerable
PHP 5.2.13, Windows 7
Not Vulnerable
PHP 5.2.13, OpenBSD 4.7
PHP 5.2.17, Linux 2.6.18
/Mango
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
--
Pentest - When a tick in the box is not enough
Paul Johnston - IT Security Consultant / Tiger SST
Pentest Limited - ISO 9001 (cert 16055) / ISO 27001 (cert 558982)
Office: +44 (0) 161 233 0100
Mobile: +44 (0) 7817 219 072
Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy
Registered Number: 4217114 England & Wales
Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK
On 5 July 2011 13:54, Paul Johnston paul.johnston@pentest.co.uk wrote:
**
I expect that's why it's not high-priority for PHP. They have other
null-byte issues, most notably in file names, although Suhosin does protect
these. I don't see any reason why they can't fix them in the main line
though.
I've no idea either, it's not like it's useful functionality and it's been
around for years.
"They have other null-byte issues, most notably in file names"
Null bytes in filenames have actually been disallowed in recent versions of PHP.
http://php.net/ChangeLog-5.php#5.3.4
"Paths with NULL in them (foo\0bar.txt) are now considered as invalid. (Rasmus)"
On Tue, Jul 5, 2011 at 12:15 PM, gaz Heyes gazheyes@gmail.com wrote:
On 5 July 2011 13:54, Paul Johnston paul.johnston@pentest.co.uk wrote:
I expect that's why it's not high-priority for PHP. They have other
null-byte issues, most notably in file names, although Suhosin does protect
these. I don't see any reason why they can't fix them in the main line
though.
I've no idea either, it's not like it's useful functionality and it's been
around for years.
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
If you want to see a real world example of this vulnerability, read
about my findings in phpMyAdmin.
http://ha.xxor.se/2011/07/phpmyadmin-3x-multiple-remote-code.html
/Mango
2011/7/5 Neal Poole neal@nealpoole.com:
"They have other null-byte issues, most notably in file names"
Null bytes in filenames have actually been disallowed in recent versions of PHP.
http://php.net/ChangeLog-5.php#5.3.4
"Paths with NULL in them (foo\0bar.txt) are now considered as invalid. (Rasmus)"
On Tue, Jul 5, 2011 at 12:15 PM, gaz Heyes gazheyes@gmail.com wrote:
On 5 July 2011 13:54, Paul Johnston paul.johnston@pentest.co.uk wrote:
I expect that's why it's not high-priority for PHP. They have other
null-byte issues, most notably in file names, although Suhosin does protect
these. I don't see any reason why they can't fix them in the main line
though.
I've no idea either, it's not like it's useful functionality and it's been
around for years.
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org