Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Security

Month of PHP Bugs Has Begun 165

Posted by Zonk from the quick-hide-the-furniture dept.
An anonymous reader writes "The previously announced Month of PHP Bugs started three days ago, and already lists 8 security vulnerabilities in PHP and PHP related software. From the site: 'This initiative is an effort to improve the security of PHP. However we will not concentrate on problems in the PHP language that might result in insecure PHP applications, but on security vulnerabilities in the PHP core. During March 2007 old and new security vulnerabilities in the Zend Engine, the PHP core and the PHP extensions will be disclosed on a day by day basis. We will also point out necessary changes in the current vulnerability management process used by the PHP Security Response Team.'"
This discussion has been archived. No new comments can be posted.

Month of PHP Bugs Has Begun More

Month of PHP Bugs Has Begun

Comments Filter:

  • Defective by Design? (Score:5, Interesting)

    by Ckwop ( 707653 ) * on Saturday March 03, 2007 @02:34PM (#18219132) Homepage

    We see a lot of people use the phrase "defective by design" when talking about Vista and in that instance I'm pretty sure the use of the term is correct.

    Having never used PHP but heard of its many security problems I'm wondering: Is PHP defective by design? If so, why so and how would Slashdot seek to fix it?

    Simon

    • Re: (Score:3, Interesting)

      by SCHecklerX ( 229973 )
      Use perl instead :)

      Not entirely joking. I use embedded perl for my own dynamic sites, and keep track of the lists, and can't recall any serious known flaws with that implementation.

      The vulnerabilities that keep popping up (and the fact that I already know and am comfortable with perl, have CPAN, can develop quickly especially now that I have my own base modules set up, etc) are one reason that I never really looked into PHP.

      • Use perl instead :)

        Not entirely joking. I use embedded perl for my own dynamic sites, and keep track of the lists, and can't recall any serious known flaws with that implementation.

        The vulnerabilities that keep popping up (and the fact that I already know and am comfortable with perl, have CPAN, can develop quickly especially now that I have my own base modules set up, etc) are one reason that I never really looked into PHP.

        the problem with perl is that i tend to use it for system administration purposes rather than making websites. php is just better for making sites as it is generally setup OOTB, almost a de facto for apache. the programmer should be aware of general problems, the magic_quotes implementation was designed to help programmers, but i think it introduced more code paths.

    • Re:Defective by Design? (Score:5, Informative)

      by julesh ( 229690 ) on Saturday March 03, 2007 @02:44PM (#18219228)
      Is PHP defective by design?

      It was. A lot of work has been done in the last couple of major versions to fix this, but still a lot of installations are crippled in the name of backward compatibility.

      Most of what we're seeing here though is just run-of-the-mill sloppy coding. Create a lot of references to a variable and overflow its (16-bit) reference count? Please. That should never have happened.

      Fortunately, it seems most of the bugs released so far don't affect the majority of installations. We have a number of 'executing arbitrary PHP code can let somebody own your web server' -- well, most of us don't let random people run arbitrary PHP code anyway. We have some 'deserialising arbitrary data can let somebody own your web server' issues too, but then there has been a long-standing warning that PHP's deserialise function isn't secure anyway, so that shouldn't affect anyone who's been paying attention. We have some issues with the Zend Platform, but I'm not sure how many people have that installed. So far, the only issue to affect me, is the phpinfo XSS vulnerability -- and that just meant I had to delete my phpinfo.php file that I kept in the root of each domain I host.

      • Re: (Score:3, Interesting)

        by Anonymous Coward
        Uhmm, you are aware that all the phpBB forums out there use unserialize() on cookie data?

        And phpBB is just one of many popular applications that do it...

        • Re: (Score:3, Insightful)

          by julesh ( 229690 )
          Uhmm, you are aware that all the phpBB forums out there use unserialize() on cookie data?

          No, I wasn't. One more reason not to use phpBB, I guess.
          • If you read the website, you would have seen that the unserialize bug was fixed in PHP 4.4.5

            • Re: (Score:2)

              by julesh ( 229690 )
              If you read the website, you would have seen that the unserialize bug was fixed in PHP 4.4.5

              Doesn't mean calling unserialize on untrusted data is a good idea. Unserialized data may be of any class, and code may be automatically executed in it during the unserialization process. This means an attacker may be able to execute code you were not expecting to be executed, potentially leading to any of a number of exploit scenarios. Unserializing untrusted data in PHP (and many other dynamic languages) is a bad
          • It was actually the cause of a security hole a while back. They unserialize your MD5 hash (which isn't salted by the way), and check whether it == the hash retrieved from the database.

            But they do $inputHash == $hash, and you can use the serialized syntax to make $inputHash = true;, which means that it will == any non-zero-length string. Very annoying gotchas like this can make PHP a nightmare.

            • But they do $inputHash == $hash, and you can use the serialized syntax to make $inputHash = true;, which means that it will == any non-zero-length string. Very annoying gotchas like this can make PHP a nightmare.

              Strange, I'm looking at the code for phpBB2 v2.0.22 in my editor right now, and there is no occurrence of code like you mention. That sort of problem was cleared up well over a year ago, when it was first revealed to be a problem. In every case where unserialize() is used, its output is assigned t

      • Re: (Score:1, Informative)

        by Anonymous Coward

        Is PHP defective by design?

        It was.

        It still is. Security is not a property of software, or even software design. It's a property of the development process, and it's something that the core PHP developers have failed to get time and time again.

        It's true, they've fixed some glaring problems over the past couple of major versions. But they've done it because they've been nagged and shamed into doing so. They still don't have proper processes in place, they still don't get it, and I'm pretty sure th

        • Re:Defective by Design? (Score:5, Interesting)

          by julesh ( 229690 ) on Saturday March 03, 2007 @03:03PM (#18219348)
          I think PHP has got beyond the stupid-design-flaws-causing-security-issues stage. Now, as you correctly point out, the major issue is endemic insecure programming practices and a lack of attention to bug reports.

          How I wish we could just junk the language and start again with something else; unfortunately, market pressures being what they are, I'm afraid we're stuck with it, at least for the time being.
          • ...or you could target PHP at the Java JVM and benefit from the security built into Java?

          • Re:Defective by Design? (Score:5, Insightful)

            by Dan Ost ( 415913 ) on Saturday March 03, 2007 @04:26PM (#18220070)
            Actually, lots of people have abandoned PHP for Python and Ruby.

            It may never completely go away, but there are alternatives to using it.

            • Re: (Score:3, Informative)

              by julesh ( 229690 )
              Actually, lots of people have abandoned PHP for Python and Ruby.

              It may never completely go away, but there are alternatives to using it.

              Not really. Most of us in the off-the-shelf web package software development industry are constrained to develop in whatever's available on the servers our clients are likely to choose. An informal survey suggests that of 5 popular hosting providers in my local area, only 1 offers anything other than PHP or Perl/CGI in their basic level package. With this kind of support

              • Re: (Score:2)

                by jZnat ( 793348 ) *
                Just wait for Debian Etch; that should help update a lot of hosts into using modern languages (including modern versions of PHP).

            • Re: (Score:2)

              by mangu ( 126918 )
              Actually, lots of people have abandoned PHP for Python and Ruby.


              I don't know about Ruby, but I do a lot of programming in Python. Let's see:


              #!/usr/bin/python
              a = 1
              b = 1.
              if a == b: print "they are the same"
              if (a / 3) != (b / 3): print "they are not the same"


              Oh, come on, where's that '===' operator when one needs it???!

          • Re: (Score:2)

            by jadavis ( 473492 )
            I think PHP has got beyond the stupid-design-flaws-causing-security-issues stage.

            A major problem for PHP is still it's configureware mentality. No other programming language has a configure file. PHP started with it because it's also a web framework; which is somewhat understandable. However, they then proceeded to abuse the configuration file for all sorts of semantic behaviors, and the end result is that it's very HARD to program securely and portably at the same time. Make a configuration change, and tha

          • How I wish we could just junk the language [PHP]
            At least it's better than Perl.


            *ducks*

      • Re:Defective by Design? (Score:5, Informative)

        by aaronwormus ( 716976 ) on Saturday March 03, 2007 @04:17PM (#18219964)
        > I had to delete my phpinfo.php file that I kept in the root of each domain I host.

        if you left an open phpinfo() on your server (giving potential attackers access to filepaths, module version numbers, configuration options, apache server configuration options), you have a lot more to worry about than a little XSS.

        unfortunatly, you're not alone [google.com].

      • and that just meant I had to delete my phpinfo.php file that I kept in the root of each domain I host.

        Heh... guess I'm not the only idiot that does that. :) Even though I'm running 5.x and that bug doesn't affect me, I've known it was a stupid idea for a long time but laziness prevailed. You and the PHP bugs project have just given me the motivation to fix that!

    • "Defective by Design [wikipedia.org]" usually refers to DRM, since that is what the FSF's campaign against DRM [defectivebydesign.org] is called.

    • The simplest fix (Score:1, Interesting)

      by Anonymous Coward
      One of the biggest problems with PHP is the die-hard adherance to backwards compatibility. Functions don't get deprecated, the API doesn't change, it gets overloaded with nearly-the-same but-not-quite methods so that somewhere, somebody doesn't complain about how their website "broke" with the latest release--never mind the fact that by using insecure functions, their sites are already broke.

      • Re: (Score:2)

        by epine ( 68316 )

        One of the biggest problems with PHP is the die-hard adherance to backwards compatibility. Functions don't get deprecated, the API doesn't change, it gets overloaded with nearly-the-same but-not-quite methods so that somewhere, somebody doesn't complain about how their website "broke" with the latest release--never mind the fact that by using insecure functions, their sites are already broke.

        It goes beyond that. When the new API variants are released, details the actual problem resolved are usually found d

    • It's a legitimate question.

      I just started using PHP a few months ago for a few utilities on one of my websites. There are a ton of things about the language that seem half-assed. In particular I'm thinking of:

      - The entire mysql library, which I have to use right now because mysqli apparently isn't enabled by default in PHP 4 and my current host won't turn it on or upgrade to PHP 5. Why is the default behaviour to force the use of SQL injection-vulnerable code?
      - There is no equivalent of a "contains" method

      • Re:Parent isn't flamebait (Score:5, Interesting)

        by Aladrin ( 926209 ) on Saturday March 03, 2007 @03:43PM (#18219688)
        So your webhost won't upgrade, and that's PHP's fault? PHP5 has been out a LONG time. Don't bother complaining about bugs in PHP4 simply because your website can't be bothered to upgrade. Find a decent webhost instead.

        strpos() return FALSE when it can't find the 'needle'. http://us2.php.net/strpos [php.net] Use a proper test (===) and you'll have all you need in a single statement.

        Some people really LIKE dynamically-typed variables. It's not a bug or a problem. It's a design choice.

        Your flamebait at the end (vbscript) does nothing to enhance your argument. Leave it off next time.

      • There is no equivalent of a "contains" method for the string class, with strpos() being the recommended alternative. strpos() returns 0 if a string doesn't contain the specified substring... or it contains it at position 0. So to do a true "does this string contain some substring?" check requires using both strpos() *and* a separate check between the substring and a new substring made from the original string but chopped off at the length of the substring you're checking for.

        Use === with your comparison. Yes, dynamically typed variables can be a pain but only if you don't understand how to use them. Look at the following example:

        $inputstring = "This is my PHP script";
        if(strpos($inputstring,"This") === false) echo "Not found in inputstring"; //This does NOT evaluate to true because 0 is NOT === false
        if(strpos($inputstring,"This") == false) echo "Not found in inputstring"; //This WILL evaluate to true and echo happens because 0 == false

        So your criticism of dynamically-typ

      • Just because you havent learnt about how the type system works doesnt mean its crappy.

    • Re: (Score:1)

      by mbyte ( 65875 )
      That would imply that PHP was designed .. rather than something happened by accident ;)
    • PHP its self is very good. Its the sloppy coders who give it the bad name.

      I've seen atrocious code where you can tell that just because the coder knows how to do a for loop in BASIC it means it can become the next Bill Gates.

    • Re:Defective by Design? (Score:5, Funny)

      by arodland ( 127775 ) on Saturday March 03, 2007 @05:51PM (#18220742)
      Nope. Definitely defective by lack of design.

    • Re: (Score:2)

      by cortana ( 588495 )
      That implies that PHP was designed in the first place.

    • Re: (Score:3, Informative)

      by caluml ( 551744 )
      mod_security [modsecurity.org] and Hardened PHP [hardened-php.net] can help with preventing future attacks that people don't yet know about.
      Also, using something like GRSec [grsecurity.net], or SELinux can further restrict what people could do if they did end up with a shell on your webserver. Although whether it's worth the effort to set up for everyone is another question.
    • Having never used PHP but heard of its many security problems...

      You would hear of the many security problems of any language that's widely used in the internet. It's not that PHP is so insecure as that, the problem is that it's more exposed, so it needs to be more secure than other languages.

      Part of the problem with the public image of PHP is that it's a purely "commercial" language, it lacks the nerdy appeal of Ruby or Lisp, for instance. Most of the comments you'll see here in Slashdot bemoaning PHP's sh

  • Month of bugs, will it change things for better? (Score:4, Interesting)

    by chabotc ( 22496 ) <chabotc@ g m a i l.com> on Saturday March 03, 2007 @02:35PM (#18219152) Homepage
    To be honest i'm glad that this month of bugs is happening, after all the previous news items about how the core php / zend team is refusing to colaberate with some ppl who are deeply concerned about php's security (and by this we do mean mistakes/faults in the php engine, not in bad php programming).

    On the other hand, i bet a fair few of the released vunerabilities will be applicable for many websites that the company i work for hosts, and i know corperate policy doesn't include frequent updates to their envirioment, there's just to many sites, to many badly supported applications by/for customers, and just to damn many servers to work with easily, i can't imagine were the only such company with such problems... And it really makes me wonder if this will mean that many hundreds of our hosted websites will from now on be easily hackable by scriptkiddies

    Should prove to be interesting times, and who knows maybe it will teach our admins to use yum/rpm's for their servers instead of compiling their own apache/php combinations :-)

  • Just in case.. (Score:4, Interesting)

    by loconet ( 415875 ) on Saturday March 03, 2007 @02:39PM (#18219174) Homepage
    To clarify, note that these bugs are related to the PHP core, not the language itself which may result in insecure applications. The statement that 8 security vulnerabilities in PHP and PHP related software is not referring to PHP software such as Wordpress. I mean seriously, I think I saw my dog hacking together a blog the other day using PHP. Everyone uses the language and not everyone has the background to know what they should and shouldn't be doing. In addition to its popularity, the language and its "libraries" make it easy for untrained coders to leave gapping holes in the code. Don't get me wrong, I love PHP (to an extend), I make a living out of it but any attempt at fixing "PHP related software" directly (ie: wordpress,phpbb,oscommerce,etc) would take more than a month.
    • I've used PHP5 exclusively for over a year, for well-publicized reasons.

    • these bugs are related to the PHP core...I make a living out of it
      You're the most qualified person currently available to hypothesize on an attack vector and a path to a full-fledged exploit. Will you share any thoughts?

    • Re: (Score:2)

      by Toba82 ( 871257 )
      I cannot agree more. I use PHP extensively and to be honest, none of the PHP 'exploits' have ever effected any of my scripts. In one case where a GET variable contains a base64 encoded serialize()ed structure, I included sha1 and md5 hashes in the URL that have to match for input to be accepted... I did this a year ago, because I had a feeling that unserialize could be unsafe. Evidently, I was right.

      In a shared-hosting situation, I can see why these would be a much bigger problem.
  • Beware of the unexpected behavior of a program... it brings joy to hackers all around the world.

  • Typical (Score:3, Informative)

    by dysfunct ( 940221 ) * on Saturday March 03, 2007 @03:42PM (#18219672)
    Stefan Esser has found some interesting yet not too surprising vulnerabilities in PHP. All those scenarios described in the various vulnerability reports are very typical for the development process of PHP and many similar ones have already been found and reported. The same goes for the fact that many of those are simply WONTFIX. A perfect example for the general attitude regarding a remote code execution vulnerability cited here [php-security.org]:

    Because the PHP developers do not want to fix this anymore because it creates problems for companies providing closed source PHP extensions the only potential workaround is to manually change the size of the reference counter in your own PHP. However if you do so you have to recompile all your PHP extensions and cannot use closed source PHP extensions anymore.

    I more and more get the feeling that the PHP developers themselves do not properly understand the vulnerabilities any more, which leads to improper and I even dare to say incompetent handling of reports and fixes (many of which simply get applied somewhere down the road without proper announcement or mentioning anywhere in the CHANGELOG) as well as seemingly ignorance regarding more complex vulns that are just as relevant as the glaringly obvious ones but simply not as mass-exploitable by script kiddies.

    And *this* is the big problem that PHP is facing today regarding enterprise support. Maybe Jon Doe's blog installation is not as mass-exploitable by a script kiddie any more as it used to be some years ago, yet Big Company's CMS is still vulnerable to complex attacks by an experienced attacker who might use published attacks that security experts know about, yet end users do not.

    • First of all, the issue HAS been fixed in PHP5 and above. Secondly, this is NOT a remote code execution vulnerability. The only way it can be exploited is by already having the ability to make the server run arbitrary scripts.

      Yes, in a shared host environment it potentially allows users to bypass safe mode and open basedir restrictions, however information on how to properly secure PHP for a shared environment has been around for a LONG Time. Not one person on the development team you go so far as to call

      • First of all, the issue HAS been fixed in PHP5 and above.

        Was there ever a proper back-port to PHP4 or proper announcement of this bug? I'm not exactly an expert on PHP internals but I imagine there might be possibilities to remedy this situation if desired.

        Secondly, this is NOT a remote code execution vulnerability.

        Yep, you kinda got me there. This might be very, very hard to exploit by using other attack vectors like improper input handling or decoding by PHP itself. Although one mustn't forget that this

      • I believe serialize() [php.net] preserves references -- it certainly does in PHP5 -- and (as mentioned elsewhere [slashdot.org] in the discussion) several PHP applications unserialize() remote data (notably phpBB).

        Now, since the bug is apparently PHP4 only (gigabytes worth of references notwithstanding), the Big Question is whether or not the PHP4 unserialize() restores references.

  • Yes, but how many sites get hacked because of PHP and not because of faulty applications?

    Not many.

  • Oh Nose! (Score:4, Funny)

    by FedeLebron ( 977157 ) on Saturday March 03, 2007 @04:09PM (#18219908)
    "A deep recursion of PHP userland code will exhaust all available stack which leads to a sometimes remotely triggerable crash."

    I've found a very similar bug in GLIBC!

    int main(){
    main();
    }
    This code will cause a segment violation!

    Shock! Gasp! Horror!
    • That does sound like a bug in Glibc, it should generate a stack fault.

    • Re: (Score:3, Informative)

      by julesh ( 229690 )
      You do realise the difference between PHP and GLIBC, don't you? PHP is designed to have a "safe mode", which (according to the documentation) is supposed to allow a system administrator to run arbitrary code in the knowledge that it can't do certain things -- one of these things should be crashing the web server.

    • Re: (Score:3, Informative)

      by iluvcapra ( 782887 )

      I've observed that a lot of complaints about modern PHP derive from the fact that it's a dynamic interpreted language, but that in many ways it behaves like a compiled, angry, shoot-yourself-in-the-foot language, like C.

      PHP will segfault, just like C, if you recurse too far on the stack, but almost every other scripting language has a mechanism for catching a stack overflow as an exception and then letting the programmer handle it. PHP in this case just crashes; even C allows you to register a function to

    • Re: (Score:2)

      by suv4x4 ( 956391 )
      "A deep recursion of PHP userland code will exhaust all available stack which leads to a sometimes remotely triggerable crash."

      I've found a very similar bug in GLIBC!

      int main(){
      main();
      }

      This code will cause a segment violation!

      Shock! Gasp! Horror!

      Now you know why web pages aren't generally coded in C. There's a reason people use higher level languages for such tasks, and one of them is that you can NOT crash the server via
  • We see a lot of people use the phrase "defective by design" when talking about Vista and in that instance I'm pretty sure the use of the term is correct. Having never used PHP but heard of its many security problems I'm wondering: Is PHP defective by design?

    Maybe. PHP is a wonderful interpreted language that makes creating a web application easy. The biggest problem with PHP are the entry-level programmers who don't understand the beast that is web programming.

    Many PHP programmers don't understand th

    • Re:PHP taint what it should be (Score:4, Interesting)

      by Unknown Relic ( 544714 ) on Saturday March 03, 2007 @05:42PM (#18220656) Homepage
      Well then, you'll be happy to know that Wietse Venema from IBM Research put in a proposal for taint support in PHP a couple months ago. I'm not sure if anything has come of it as there was a fair amount of concern that it would turn into another "Safe Mode" debacle, but from what I remember his plan was to essentially start work on a proof of concept implementation early this year and then take it from there.

  • Be Prepared? (Score:2, Insightful)

    by Mikenotmike ( 956042 )
    Since properly coded PHP is still useful in many applications, what would be the best book to use as an up to date reference manual for the most secure method of coding with it?
    • If you want to code well, you're best reading the Camel Book [sic].

    • Re: (Score:2)

      by aymanh ( 892834 )
      Essential PHP Security [phpsecurity.org] is what you are looking for. The book covers a wide range of attacks and how to deal with them. In addition, the website has a couple of sample chapters so you can take a look and see if you like it.

    • Re: (Score:1)

      by akamm ( 1003031 )
      Pro PHP Security (published by APress). I believe it to be more comprehensive than Essential PHP Security... it gets quite detailed.

  • Why not use a lovely PHP FrameWork then? Like, um, say, Drupal [drupal.org]?

    - - - -

    You can't be ahead of the curve, if you're stuck in a loop.

  • Month of Shooting Fish in a Barrel

    Seriously, when does the Month of Oracle Bugs make its return? Or did the Month of Bugs folks simply chicken out when Larry Elison showed up at their house with a samurai sword?
  • We can use Ruby on Rails.

    perl is very good at text processing as well.

    Are there any PHP-to-C++ translators? If the bugs are sitting in the PHP interpreter itself, it might be safer to translate and compile the code.

    "Only perl can parse Perl" - but maybe there are alternative PHP parsers/interpreters?

  • Why MOPB Matters (Score:2, Interesting)

    by gantry ( 180560 )
    I have just analysed the last month's script kiddie attacks on my web server. 71% of them were to php-related URLs. When I first went through this exercise some years ago, the overwhelming majority of attacks were URLs related to IIS. The significance of this change cannot be overestimated.

    Yes, a lot of the problems are sloppy coding, but too many are in the PHP core. How many web pages use the PHP-array-specific query-string
    ?foo[]=bar
    - not many, you might think. How many use a PHP neste

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close