<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Wed, 23 May 2012 04:27:40 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[PHP-Security.net: New PHP-CGI Exploit (CVE-2012-1823)]]></title>
      <guid>http://www.phpdeveloper.org/news/17908</guid>
      <link>http://www.phpdeveloper.org/news/17908</link>
      <description><![CDATA[<p>
The PHP-Security.net site has two posts related to the recently discovered bug in PHP (hence the <a href="http://phpdeveloper.org/news/17907">new versions</a>) related to the CGI handling in certain server configurations. 
</p>
<p>
In <a href="http://www.php-security.net/archives/9-New-PHP-CGI-exploit-CVE-2012-1823,-PoC-exploit.html">the first</a> they detail more of what the bug is, how it could be exploited and link to the <a href="http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/">original advisory</a> for the problem. Also included are more details on the issue, including sample avenues of attack.
</p>
<p>
In the <a href="http://www.php-security.net/archives/11-Mitigation-for-CVE-2012-1823-CVE-2012-2311.html">second post</a> they look at the recent PHP release and note that it does not completely rid the language of the problem. They point out that the Rewrite rule that's included in their post (not the one on PHP.net) should be used to prevent this issue from effecting your installations.
</p>]]></description>
      <pubDate>Fri, 04 May 2012 08:24:44 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[PHP.net: Security Notice (wiki.php.net)]]></title>
      <guid>http://www.phpdeveloper.org/news/16087</guid>
      <link>http://www.phpdeveloper.org/news/16087</link>
      <description><![CDATA[<p>
On PHP.net there's a <a href="http://www.php.net/index.php#id2011-03-19-2">quick security advisory</a> for those that didn't see the news - the wiki.php.net machine was compromised but has been wiped and all accounts reset and requiring a password reset.
</p>
<blockquote>
The wiki.php.net box was compromised and the attackers were able to collect wiki account credentials. No other machines in the php.net infrastructure appear to have been affected. Our biggest concern is, of course, the integrity of our source code. We did an extensive code audit and looked at every commit since 5.3.5 to make sure that no stolen accounts were used to inject anything malicious. Nothing was found. The compromised machine has been wiped and we are forcing a password change for all svn accounts.
</blockquote>
<p>
The issue was caused by a combination of a problem with the wiki software and a Linux root exploit. <a href="http://www.theregister.co.uk/2011/03/21/php_server_hacked/">The Register</a> has additional comments about the issue and outage.
</p>]]></description>
      <pubDate>Wed, 23 Mar 2011 10:43:05 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Community News: PHP Remote Exploit - Floating Point Issue Causes Freeze/Crash]]></title>
      <guid>http://www.phpdeveloper.org/news/15697</guid>
      <link>http://www.phpdeveloper.org/news/15697</link>
      <description><![CDATA[<p>
As reported by both <a href="http://www.theregister.co.uk/2011/01/04/weird_php_dos_vuln/">The Register</a> and <a href="http://www.zend.com/en/company/news/news-links/php-remote-exploit-information-and-hotfix">Zend</a>, there's a new remote exploit bug that possibly has something to do with the way 32-bit processors handle floating point numbers.
</p>
<p>From Zend:</p>
<blockquote>
Due to the way the PHP runtime handles internal conversion of floating point numbers, it is possible for a remote attacker to bring down a web application simply by adding a specific parameter to a query string in their web browser.
</blockquote>
<p>
The bug, <a href="http://bugs.php.net/bug.php?id=53632">found here</a> on bugs.php.net, has been reproduced on Windows and 32-bit linux systems and can cause the server hang and/or crash as a result. The real issue comes from <a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323">this bug</a> on the x87 FPU design. The bug has already been fixed in the latest SVN versions (including 5.2 that was end-of-life recently). A release to fix the issue should be coming shortly.
</p>]]></description>
      <pubDate>Thu, 06 Jan 2011 08:06:31 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Stefan Esser's Blog: Some facts about the PHPList vulnerability and the phpbb.com hack]]></title>
      <guid>http://www.phpdeveloper.org/news/11897</guid>
      <link>http://www.phpdeveloper.org/news/11897</link>
      <description><![CDATA[<p>
Some of you might have <a href="http://www.phpdeveloper.org/news/11868">heard about</a> the hacking of the phpBB.com website earlier this week. Well, <i>Stefan Esser</i> has <a href="http://www.suspekt.org/2009/02/06/some-facts-about-the-phplist-vulnerability-and-the-phpbbcom-hack/">posted a bit more</a> about the vulnerability in the PHPList software that lead to the problem.
</p>
<blockquote>
A few days ago <a href="http://www.phpbb.com/">phpbb.com</a> was hacked through a super-globals-overwrite vulnerability in <a href="http://www.phplist.com/">PHPList</a> that was used by an attacker for a local file inclusion <a href="http://www.milw0rm.com/exploits/7778">exploit</a>. Details about the whole attack, written down by someone who claims to be the attacker, can be <a href="http://hackedphpbb.blogspot.com/2009/01/place-holder.html">read here</a>.
</blockquote>
<p>
<i>Stefan</i> talks about the superglobal problem PHPList had - allowing the superglobal information to overwrite the variables inside the script without so much as a check. Example code shows how it was possible for the attacker to provide their own configuration file value to be opened via a stream wrapper.
</p>]]></description>
      <pubDate>Fri, 06 Feb 2009 08:44:25 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[GNUCitizen.org: Reviewing Practical PHP Exploitation Techniques]]></title>
      <guid>http://www.phpdeveloper.org/news/9915</guid>
      <link>http://www.phpdeveloper.org/news/9915</link>
      <description><![CDATA[<p>
From the GNUCitizen blog, there's <a href="http://www.gnucitizen.org/blog/reviewing-practical-php-exploitation-techniques/">a new post</a> about a recent meeting (of the OWASP London Chapter) where several presentations were given on methods for exploiting PHP applications. The three talks given were:
</p>
<ul>
<li><i>Rodrigo Marcos</i> - hacking PHP sockets for fun and profit
<li><i>David Kierznowski</i> - exploitation techniques using real world examples
<li><i>Colin Watson</i> - talk about security badges
</ul>
<p>
There's links to the slides for one the formal presentations, the exploitation techniques - two sets: the <a href="http://www.withdk.com/archives/PHP%20Code%20Analysis-%20Real%20World%20Examples.pdf">remote exploit examples</a> and <a href="http://www.gnucitizen.org/blog/reviewing-practical-php-exploitation-techniques/PHP%20Code%20Analysis%20-%20Real%20World%20Examples.pdf">local exploit examples</a>.
</p>]]></description>
      <pubDate>Fri, 04 Apr 2008 12:09:22 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Gareth Heyes' Blog: Exploiting PHP SELF]]></title>
      <guid>http://www.phpdeveloper.org/news/9413</guid>
      <link>http://www.phpdeveloper.org/news/9413</link>
      <description><![CDATA[<p>
<i>Gareth Heyes</i> has a <a href="http://www.thespanner.co.uk/2008/01/14/exploiting-php-self/">new post</a> today talking about one of the vulnerable values in the $_SERVER superglobal - PHP_SELF.
</p>
<blockquote>
I thought it might be a good idea to gather a few test cases demonstrating the problem. Why PHP allows these URL's is beyond me and it wouldn't take much work to filter out these malicious URL's in the PHP code.
</blockquote>
<p>
He <a href="http://www.thespanner.co.uk/2008/01/14/exploiting-php-self/">provides</a> four test cases to show how simple it is to abuse - one using a HTTP header, another pushing XSS through, the third mentions search pages and the fourth a direct code injection.
</p>
<p>
You can <a href="http://www.thespanner.co.uk/wp-content/uploads/2008/01/php_selfphp.zip">download the code here</a>.
</p>]]></description>
      <pubDate>Mon, 14 Jan 2008 07:54:00 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Gareth Heyes' Blog: Faking the unexpected]]></title>
      <guid>http://www.phpdeveloper.org/news/9167</guid>
      <link>http://www.phpdeveloper.org/news/9167</link>
      <description><![CDATA[<p>
<i>Gareth Heyes</i> has <a href="http://www.thespanner.co.uk/2007/12/02/faking-the-unexpected/">an example</a> of yet another way he's seen developers incorrectly handle incoming connections and the information inside. This time, he focuses on the remote IP coming from the client.
</p>
<blockquote>
Developers place too much trust in everything, they assume that certain data cannot be faked and therefore these pieces of data can be used as a Trojan horse. Lets take the REMOTE IP of a user, it seems a trusted source because of the TCP/IP connection between the user and the server.
</blockquote>
<p>
He points out the difference between HTTP_X_FORWARDED_FOR and REMOTE_ADDR and how, despite them being the same almost all of the time, shouldn't be trusted since they could be spoofed. He even includes an example script showing how it could be done (and how a bit of Javascript can even be inserted).
</p>]]></description>
      <pubDate>Tue, 04 Dec 2007 08:36:04 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Community News: Ubuntu Updates PHP Packages]]></title>
      <guid>http://www.phpdeveloper.org/news/9148</guid>
      <link>http://www.phpdeveloper.org/news/9148</link>
      <description><![CDATA[<p>
The Ubuntu linux group has <a href="http://www.ubuntu.com/usn/usn-549-1">released an update</a> for their PHP packages to help protect their users from issues like security bypass and remote exploits.
</p>
<blockquote>
This fixes a weakness and some vulnerabilities, where some have unknown impacts and others can be exploited by malicious, local users to bypass certain security restrictions and by malicious users to bypass certain security restrictions.
</blockquote>
<p>
Packages can either be <a href="http://www.ubuntu.com/usn/usn-549-1">downloaded manually</a> or via the linux distro's package manager. This advisory also applies to the corresponding versions of Kubuntu, Edubuntu, and Xubuntu.
</p>]]></description>
      <pubDate>Fri, 30 Nov 2007 08:41:00 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Secunia.com: Slackware Update for PHP]]></title>
      <guid>http://www.phpdeveloper.org/news/8645</guid>
      <link>http://www.phpdeveloper.org/news/8645</link>
      <description><![CDATA[<p>
As mentioned in <a href="http://secunia.com/advisories/26748/">this new advisory</a> on the Secunia website, the Slackware linux group has posted their latest updates to their PHP package (in light of the released of PHP 5.2.4).
</p>
<blockquote>
Slackware has issued an update for php. This fixes a weakness and some vulnerabilities, where some have unknown impacts and others can be exploited by malicious users and malicious, local users to bypass certain security restrictions.
</blockquote>
<p>
The update is marked as "moderately critical" so it's recommended that you update as soon as possible. The packages can be downloaded from <A href="http://slackware.com/security/viewer.php?l=slackware-security&y=2007&m=slackware-security.399824">the Slackware website</a> (from the FTP sites they link to in the original advisory).
</p>]]></description>
      <pubDate>Thu, 13 Sep 2007 08:45:00 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Builder.com.au: PHP exploit code plants itself in GIF]]></title>
      <guid>http://www.phpdeveloper.org/news/8107</guid>
      <link>http://www.phpdeveloper.org/news/8107</link>
      <description><![CDATA[<p>
Builder.com.au has a <a href="http://www.builderau.com.au/news/soa/PHP-exploit-code-plants-itself-in-GIF/0,339028227,339278850,00.htm">new article</a> today about the recent image issue - the PHP code embedded inside the GIF - that's come up on several sites.
</p>
<blockquote>
The exploit code slipped through the site's defenses with the aid of a legitimate image at the beginning of the file, <a href="http://isc2.sans.org/diary.html?storyid=2997">according to a blog post</a> on the Sans Institutes's Internet Storm Center. [...] Malicious attackers planted PHP coded exploit script within an image file. PHP is often used as a programming language to create dynamic Web sites.
</blockquote>
<p>
The article reports that, while this exploit hasn't happened much, the occurrences of it's use are growing with victims in a wide range of classifications - from small personal sites out to a certain major image hosting site. This same issue was discussed <a href="http://www.phpdeveloper.org/news/8088">here</a> on the PHPClasses.org website as well.
</p>]]></description>
      <pubDate>Fri, 22 Jun 2007 12:41:00 -0500</pubDate>
    </item>
  </channel>
</rss>

