Slashdot Mirror


Recently Exposed PHP Hole's Official Fix Ineffective

wiredmikey writes "On Wednesday, a remote code execution vulnerability in PHP was accidentally exposed to the Web, prompting fears that it may be used to target vulnerable websites on a massive scale. The bug itself was traced back to 2004, and came to light during a recent CTF competition. 'When PHP is used in a CGI-based setup (such as Apache's mod_cgid), the php-cgi receives a processed query string parameter as command line arguments which allows command-line switches, such as -s, -d or -c to be passed to the php-cgi binary, which can be exploited to disclose source code and obtain arbitrary code execution,' a CERT advisory explains. PHP developers pushed a fix for the flaw, resulting in the release of PHP 5.3.12 and 5.4.2, but as it turns out it didn't actually remove the vulnerability."

20 of 240 comments (clear)

  1. I finally know what PHP stands for. by DieByWire · · Score: 4, Funny

    PHP: Pretty Hard to Protect.

    --
    Never shake hands with a man you meet in a fertility clinic.
  2. Actual Details... by Anonymous Coward · · Score: 5, Informative

    Available from the source, not information week.

    The info I was looking for:
    - FastCGI installations are not vulnerable
    - can only be exploited if the HTTP server follows a fairly obscure part of the CGI spec. Apache does this, but many other servers do not.

  3. Re:Microsoft Sux! by sammyF70 · · Score: 4, Funny

    I generally don't feed your kind, but if PHP was from Microsoft it would be left unpatched for Windows Server 2003, Windows Server 2008 would get a temporary patch blocking most of the functionalities and there would be an announcement that, due to technical restrictions, everybody needs to upgrade to Windows Server 2013 (release date : late December 2015) to get an actual fix. People running iis on XP, Vista or Win7 wouldn't get a patch at all. Of course, anybody running another server than iis would be left in the cold too.

    On the positive side, it could be worse ... Apple would just ignore any mention of security problems and systematically erase any posts on their message board refering to them.

    That being said : you might want to steer away from PHP anyway. it's a stinking pile of donkey dung

    Cheers

    --
    "DRM is like the Ford Pinto: it's a smooth ride, right up the point at which it explodes and ruins your day."-C.Doctorow
  4. Training wheels without the bike by A+beautiful+mind · · Score: 5, Informative

    I think this short snippet from Rasmus is priceless:

    The point of the question here is if anybody remembers why we decided not
    to parse command line args for the cgi version? I could easily see it
    being useful to be able to write a cgi script like:

        #!/usr/local/bin/php-cgi -d include_path=/path

    and have it work both from the command line and from a web context.

    As far as I can tell this wouldn't conflict with anything, but somebody at
    some point must have had a reason for disallowing this.

    Yeah, passing arguments with full shell expansion to the bloody binary from the unsecure web sounds like a brilliant idea! Who would want to disallow that?!

    It was pretty funny so far, but then I've seen this:

    13-01: Vulnerability discovered, used to pwn Nullcon Hackim 2012 scoreboard
    13-01: We discuss the issue with Nullcon admins, find out it is a php 0day
    17-01: We contact security@php.net with a full report and a suggested patch
    01-02: We ask PHP to confirm receipt, state our intent to hand off the vulnerability to CERT if progress is not made
    01-02: PHP forwards vulnerability report to PHP CGI maintainer
    23-02: CERT acknowledges receipt of vulnerability and attempts to contact PHP.
    05-04: We ask CERT for a status update
    05-04: CERT responds saying that PHP is still working on a fix
    20-04: We ask CERT to proceed with disclosure unless a patch is imminent
    26-04: CERT prepares draft advisory.
    02-05: CERT notifies us that PHP is testing a patch and would like more time. we agree.
    03-05: Someone posts a mirror of the internal PHP bug to reddit /r/netsec /r/opensource and /r/technology. It was apparently accidentaly marked public.

    The PHP security people sat on this 0day remote code exploit for four months, ignoring multiple attempts to get them to fix this serious vulnerability. That makes me feel angry, sometimes incompetence is just not funny anymore.

    --
    It takes a man to suffer ignorance and smile
    Be yourself no matter what they say
    1. Re:Training wheels without the bike by Anonymous Coward · · Score: 3, Insightful

      I agree this is a pretty pathetic show of professionalism from the PHP team's part.

      The bug is serious, i don't know why there was even any discussion of whether or not it is a bug. It's a textbook case of not properly handling user input.

      The only thing that dampens the impact of this, is that it only impacts the CGI version of PHP. Most installations that i'm aware off, use PHP in either a SAPI or FastCGI setting, which as far as i'm aware do not use the codepath that contains this bug.

      I use PHP pretty heavily in my job, but i'm getting more and more tired of the way the project is ran. The project has some pretty clear issues that all seem to take ages getting resolved. I've often contemplated wether or not it would be worth making a fork of the project (for internal use in the company where i work) just so we could fix some of the major issues that have fouled PHP for ages now. I'm aware of several OSS projects that are attempting the same, but unfortunately none of them appear stable enough to be used for business critical applications, which makes me fear that i underestimate the amount of work that needs to be done to polish this turd.

      Now that magic quotes and register globals have finally been killed off after years of working around that mess, i started hoping that someone on the PHP team grew some balls and was beginning to push through some of the glaringly obvious fixes to PHP.

      With reasonable namespace support, there's no reason why all of PHP's functions should still be in the global namespace, and segregating them in the appropriate namespaces would finally give them a chance to fix the annoying differences in function naming and argument order, that PHP still has (for legacy reasons). This would clean up PHP tremendously for new users and would only pose a small adjustment on current users. A single configuration directive (disabled by default) could simply recreate the old functions in the global namespace, make them throw a E_STRICT notice (or something similar), and call the appropriate function from its new location.

      Many of the older/core PHP functions still use errors or empty return values, whereas all the new stuff uses Exceptions. Many experienced developers tie those together by using things like ErrorExceptions but this should just be overhauled into 1 single style (Exceptions being the most powerful one, those should probably be standardized on).

      Ever since version 5, PHP has made good progress moving towards an object oriented style of programming. However since the scalar types (String, integer, boolean, etc) are not considered to be objects, and very different rules are placed on objects compared to non-objects, another conflicting style of programming is presented. Scalar values should be able to be treated as objects (even if they're not on a fundemental level) to unify things like type hinting and passing by value/reference.

      It is my feeling that these changes would greatly improve the usability of PHP for both new and seasoned developers. It would simplify the language, and make it more powerful at the same time.

  5. Re:Cm'on by hendridm · · Score: 3, Insightful

    Millions of people.

    What is worth exploiting? Anything that you can turn into a node in your massive botnet.

  6. false - PHP has various licensing by rubycodez · · Score: 4, Informative

    http://php.net/license/index.php PHP has a license which must be respected by law. Certain parts of it have various licenses too. These are Open Source licenses, and as such have many benefits. Nevertheless, there are licenses.

  7. Re:Cm'on by nickdc · · Score: 5, Interesting

    The answer is Facebook, and I got a job by using this bug against them! see?

  8. Re:You shouldn't. Nobody should. by rubycodez · · Score: 4, Interesting

    There is ignorance, all right, between your ears. All languages have security flaws and need constant patches. PHP has robust and well tested frameworks with libraries to sanitise potentially dangerous input. There is nothing that can be done in say Ruby (my favorite language) that cannot also be done well in PHP. PHP now even has closures, lamda, internal iterators....

  9. Re:You shouldn't. Nobody should. by mikael_j · · Score: 3, Insightful

    Well, PHP has many flaws and all but I've had to maintain plain ASP/VB websites and PHP5 is miles better than that. PHP3 or ASP/VB? Well, that's a little tougher but PHP5 is just so much better than VB. As for ASP.NET (using VB or C#), that's a whole other thing. PHP doesn't compare very well to C#.NET or even VB.NET (yes, I know both are .NET and have pretty much the same features, C# is just a more pleasant language to work with).

    --
    Greylisting is to SMTP as NAT is to IPv4
  10. Re:And by drunkennewfiemidget · · Score: 5, Interesting

    > No licensing
    Wrong

    > stable
    This news post is proof that's wrong.

    > great track record
    Wrong.

    > flexable
    About as flexible as your spelling.

    > modules for everything
    This is true. AND THEYRE ALL PART OF THE CORE API! ImageMagick, MySQL (THREE TIMES!), Curl, etc .. all in the core API.

    PHP is a fucking disgrace and a blight on the world and needs to die a fiery death.

    (Spend a few minutes reading the url I linked above at veekun.com for a wonderful break won on why PHP is a heinous pile of horseshit.)

  11. Re:And by Richard_at_work · · Score: 5, Insightful

    Out of interest, what does the "great track record" refer to? The security has historically been consistently horrific, the performance has historically been consistently horrific, the consistency of the language has been consistently horrific, the development of the language has been consistently horrific...

    I do miss the documentation, now that was awesome. But I don't miss the rest of it.

  12. Re:You shouldn't. Nobody should. by digitalaudiorock · · Score: 4, Insightful

    Yea, this PHP bashing here gets really old. Sure, the fact that it's a high level language attracts some clueless programmers that write bad code, but that's not the languages fault. I happen to be in a position right now where I do most of my coding in PHP. There are in fact things about it that drive me crazy, but the fact is that you can write great stuff with PHP and you can do it very quickly. As far as this exploit goes, who actually uses PHP in cgi mode rather than as an Apache module?

  13. Re:You shouldn't. Nobody should. by mcavic · · Score: 3, Insightful

    requires you to learn a hundred different quirks and hacks

    I really don't know what quirks and hacks you're talking about. Any language has to be learned, and as long as you escape your strings before passing them to MySQL, sendmail, or another application, PHP is secure. The hole they're talking about here is an escaping problem. Although it sounds like this is actually a flaw in PHP, the method that makes it possible shouldn't be used today anyway. And you're not going to avoid escaping problems in any language that does what you're doing in PHP.

  14. Re:Cm'on by 19thNervousBreakdown · · Score: 3, Informative

    Huh, the practice is even recommended by Zend. Isn't PHP great, where a closing tag is a vector for bugs?

    --
    <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
  15. Re:You shouldn't. Nobody should. by Just+Some+Guy · · Score: 4, Insightful

    as long as you escape your strings before passing them to MySQL

    You know, I only hear PHP developers saying stupid shit like that. No one in Python talks about escaping strings (unless they're writing database libraries). Rubyists don't escape strings. Perl monks sure as hell don't escape strings. VB(\.Net)? programmers might escape strings, but we don't really count them. No one escapes strings anymore because it's stupid, error prone, and dangerous.

    And yet PHP coderz still do it. Why? Oh, right: because the official docs teach them to:

    // Formulate Query
    // This is the best way to perform an SQL query
    // For more examples, see mysql_real_escape_string()
    $query = sprintf("SELECT firstname, lastname, address, age FROM friends
    WHERE firstname='%s' AND lastname='%s'",
    mysql_real_escape_string($firstname),
    mysql_real_escape_string($lastname));

    // Perform Query
    $result = mysql_query($query);

    Fucking hell. In 2012, we're still exposing newbies to that idiocy, and when they do it poorly and some kid in Latvia owns a major PHP project as a result, defenders jump out to yell "it's the programmer, not the language!"

    --
    Dewey, what part of this looks like authorities should be involved?
  16. Re:You shouldn't. Nobody should. by rgbrenner · · Score: 4, Funny

    Apache is old news. It's bloated and there are security advisories for it all the time. I can't believe anyone uses that anymore. I, like many other admins, start by writing a webserver using the bourne shell:
    http://sprocket.io/blog/2008/03/writing-a-web-server-in-bourne-shell/

    Then, all of the web development is done using LISP. LISP is much cleaner to write a CGI program in than the bourne shell. Here's a CGI LISP tutorial that includes a comparison of the two:
    http://cybertiggyr.com/lc/

    No need to thank me for getting you up to speed on the latest web development techniques... but you're welcome.

  17. Re:And by Anonymous Coward · · Score: 5, Funny

    Out of interest, what does the "great track record" refer to? The security has historically been consistently horrific, the performance has historically been consistently horrific, the consistency of the language has been consistently horrific, the development of the language has been consistently horrific...

    They do have a great track record at being consistently horrific...

  18. Re:You shouldn't. Nobody should. by Just+Some+Guy · · Score: 4, Informative

    Prepared statements. Even PHP supports them, although they don't emphasize that fact enough (such as by causing calls to mysql_query to segfault, or ideally make the server hosting it catch on fire).

    I say that in humor, but I'm actually dead serious about always using prepared statements - in any language - over directly executing concatenated query strings. It's one thing if you're the person writing the DB interface library that everything runs through and the database itself doesn't provide some kind of facility for helping you. In that case, you go to heroic lengths to test, test, test that your library is bulletproof. But most people aren't writing client libraries; they're writing apps that use them. Those people should never be manually building query strings. Not "well, not usually but..." or "there are some situations where...". No there aren't. Don't do that or let anyone else around you do it, either.

    --
    Dewey, what part of this looks like authorities should be involved?
  19. Re:You shouldn't. Nobody should. by MadCat · · Score: 3, Insightful

    And MD5 salts were (and if I'm not mistaken, still are) the default. So by default, you'd be insecure.

    The bigger point is that *even though the PHP core's own unit tests failed, they still shipped a release* - this is an indication that the PHP core team has no clue. You do not ship a release when your core unit tests *are failing*.

    --
    There is no sig...