Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
PHP Programming Security

PHP Vulnerabilities Announced 387

Posted by michael from the rated-o-for-overtime dept.
Simone Klassen writes "The Hardened-PHP Project has announced several serious and according to them, easy-to-exploit vulnerabilities within PHP. A flaw within the function unserialize() is rated as very critical for millions of PHP servers, because it is exposed to remote attackers through lots of very popular webapplications. The list includes forum software like phpBB2, WBB2, Invision Board and vBulletin. It is time to upgrade now."
This discussion has been archived. No new comments can be posted.

PHP Vulnerabilities Announced More

PHP Vulnerabilities Announced

Comments Filter:

  • No comment? (Score:3, Funny)

    by jardin ( 778043 ) * on Friday December 17, 2004 @01:21PM (#11117162)
    They must be all busy upgrading :)

  • Kewl (Score:3, Funny)

    by mordors9 ( 665662 ) on Friday December 17, 2004 @01:23PM (#11117188)
    I can't wait for someone to release a script that I can use to show what a leet haxor I am.
  • PHP: 10 million newbies can't be wrong.

  • Third-party modules? (Score:5, Interesting)

    by flatface ( 611167 ) * on Friday December 17, 2004 @01:23PM (#11117196)
    I read about this [secunia.com] yesterday and couldn't find out if mod_security [modsecurity.org] and suPHP [suphp.org] are vulnerable to these attacks. With mod_security blocking buffer overflows, "bad" characters, etc. and mod_suphp forcing PHP to run as the user, I don't think that it gives people who run these modules (that) much to worry about.
    • mod_suphp might prevent you from attaining root, but more often than not root is not required. If you manage to upload files, insert some SQL, read files as the user PHP is running as (eg. nobody) then you have access to the whole web application (user accounts, credit card databases, everything). Getting root is very often not required. That is why these web apps must be as tight (security and access wise) as operating systems themselves. Developers (esp. PHP and ASP developers) are often very slack in thi

      • If you manage to upload files, insert some SQL, read files as the user PHP is running as (eg. nobody) then you have access to the whole web application (user accounts, credit card databases, everything)

        This is exactly why it's foolish to use a so-called "database" (*cough* mysql *cough*) which does not support stored procedures. Stored procedures are a vital means of defense against SQL injection attacks, and any RDBMS which is used as a back-end to a publicly-accessable application must use them to be

        • What you described is definitely a good idea to prevent SQL injection, but it doesn't have to be done using stored procedures. You can do the same thing on the web server with a custom function or by using prepared statements (using the PEAR library, etc).

        • I think this is why you don't store user information in a cookie, url param, or hidden field. You use a session ID, and get the user id from the session db based on session ID. The session ID is your "reasonably large random value".

          Using good coding practices is one way to keep yourself safe from these types of attacks. Even with a "database" like MySQL.

        • ...it's foolish to use a so-called "database" (*cough* mysql *cough*) which does not support stored procedures


          agreed.
          at least they're getting there w mysql 5.0:
          http://dev.mysql.com/doc/mysql/en/Stored_Pro cedure s.html

  • Upgrade. (Score:4, Insightful)

    by Anonymous Coward on Friday December 17, 2004 @01:24PM (#11117207)
    I think it's about time someone came up with an easier way to upgrade php.
    It's so god damned time-consuming to rebuild the entire thing over and over again, especially because you keep having to rebuild all the additional modules (mysql support, gd support, mcrypt support, pdf, the list goes on).
    • yeah, nightmare

      % cat /www/bin/php_install

      #!/usr/local/bin/rc

      # run this after cvsup

      echo 'got root ?'

      cd /usr/ports/lang/php4
      make

      cd /usr/ports/lang/php4/work/php-* || exec echo php dir not found ./configure \
      --with-apxs \
      --disable-cgi \
      --enable-mbstring \
      --with-openssl \
      --with-pcre-regex \
      --with-pgsql

      make && make install
    • If it causes such a hassle, and has so many security problems, why still use it? Mod_perl with embedded perl seems like a good option.
      • No thanks. I'd rather have a headache once per quarter when I have to upgrade then daily as I use it.

        I started out doing web applications in perl and switched to PHP then PHP / Smarty now and love it.

    • What are you doing that prevents you from apt-get or yumming it? Most distributions come with pre-packaged versions of Apache and PHP. What is it about those pre-packaged versions that you find unnacceptable?

      Bryan
    • You should check out http://www.dotdeb.org [dotdeb.org] if you use Debian. The maintainer does an excellent job of keeping up-to-date php(4&5) and mysql packages. You can install the base package (apt-get install php5) and then any additional modules you need (apt-get install php5-gd php5-mcrypt etc). It's a great way to keep things updated smoothly.
    • Using FreeBSD 5.3-STABLE, I did:

      # cvsup /etc/cvsupfile
      # portupgrade php5-cgi
      # portupgrade -f php5-extensions

      The latter -f causes all extensions to be rebuilt, which is what I wanted. Voila, upgraded in about 20 minutes on an Athlon XP 2000+.

  • double standards (Score:4, Insightful)

    by Anonymous Coward on Friday December 17, 2004 @01:26PM (#11117225)
    I love how you guys take this all seriously when there is an error in OSS software but when there is 1 little error in ASP.net you call it inherently insecure and a piece of garbage.
    • While this is true for some, on the whole the major difference is the time between the bug was discovered and when it was patched. MS does tend to take their sweet time.

    • Re:double standards (Score:5, Insightful)

      by ricotest ( 807136 ) on Friday December 17, 2004 @02:14PM (#11117852)
      You do realise it's a SUBSET of the slashdot population complaining about ASP being garbage, and a perhaps different SUBSET taking OSS software bugs without complaint. There are NO double standards if you stop looking at Slashdot as one person with one brain and a million voices.
    • How in the world did such a generic blanket statement get modded up?

      you guys...
      you call it...

      Who exactly is "you"? Don't stereotype a group of unique individuals as if they are some kind of collective borg.

    • It like what my DB prof said about Oracle v. MySQL (Score:5, Insightful)

      by ShatteredDream ( 636520 ) on Friday December 17, 2004 @02:46PM (#11118322) Homepage
      The prof I had for my DB class largely hates MySQL with a passion and is an Oracle partisan, but he looked one of the students in the eye and told them to basically shut up when they complained about MySQL versus Oracle. He told the whiner that they should be glad that it worked at all and that they have no right to expect any quality for something they didn't pay for. For some it was a profound statement: MySQL kinda works for you, well guess what, you haven't spent any money on it so who are you to bitch at the guys who work on it... they owe you nothing.

      Products from Zend can be expected to perform very well, but not something that is free for public use. The fact that PHP is so high quality, open and free, gives it some leeway that Microsoft's ASP.NET implementation doesn't deserve. People don't have to spend several thousand dollars to setup an environment capable of hosting PHP because it's free, and all of the tools needed to run it are free.

      None of this of course negates the fact that security holes in PHP are just as serious in practice as those in ASP.NET and need to be fixed ASAP. The difference is how we should perceive free software bugs versus commercial software bugs. When we actually buy a license for a commercial product, we should be able to expect something reasonably akin to top notch quality. Microsoft is getting better in that regard, but the level of quality they have delivered in the past is abysmal compared to what a commercial entity should be delivering.

      By all reasonable expectations, a company like Microsoft should be delivering extremely secure products. They pay very large sums of money to hire some of the brightest minds, and they charge accordingly. Therefore the public has a right to expect extremely comprehensive testing, including OpenBSD-style line-by-line code audits for things like buffer overflows. Does it not surprise anyone that a small project like OpenBSD can find the time and manpower to do that on such a large code base for the manpower present, but Microsoft, a company with probably at least ten times the manpower for just the Windows team cannot?
    • I love how you guys take this all seriously when there is an error in OSS software but when there is 1 little error in ASP.net you call it inherently insecure and a piece of garbage.

      FYI, the vulnerabilities were announced on "2004/12/15" (hardened-php). The fix was available since "15 Dec 2004".

      Conclusion: Zend took AT MOST 23:59:59 to release a fix for said vulnerabilities.

      Compare with Microsoft bugs, where it takes an AVERAGE of 6 months to get a vulnerability bug fixed.

      In comparison, Microsoft's sof
    • I _realize_ I'm kind of being an asshole for saying this, but I'm a J2EE developer, and I don't have to worry about bugs in ASP _or_ PHP. Comparatively, J2EE's just nice like that.
  • Almost every forum / message board out there utilize these scripts... I think a lot of backup-reloading (for those who have them) will take place if a script kiddie toolbox exploiting these vulnerabilites hit the scene...

    Forum defacing excepted, is there anything else someone could do using these vulnerabilities?
    • And that's why they decided not to release any POCs. I know it's just a matter of time, though. Guess it's a good thing for them (forum owners, etc), but a bad thing for me because I don't know if my machine is vulnerable yet.

    • Re:OMG (Score:4, Informative)

      by vluther ( 5638 ) <vid@OOOluther.io minus threevowels> on Friday December 17, 2004 @01:38PM (#11117395) Homepage Journal
      Forum defacing is for the script kiddies, I've seen variations of the unserialized exploit used, to upload files into paths writeable by the apache user, and reading files accessible by the apache user, you can do mysqldumps, upload zombie scripts etc, one of my clients was made part of a zombie network as the user nobody, and redirect scripts were added to many posts, as the posts are stored in the db, and the kid found the mysql user/pass to access the forum.

      Hurrah for Nightly MySQL dumps.

  • I have a few legacy servers just around for my use and i don't want to pay for the upgrade and downtime..

    anyone know of any ensim pro updates or packages someone has continued to build for this setup?

    (or possibly redhat 7.3 updates..??)

    thanks!

  • Of course... (Score:5, Insightful)

    by Nos. ( 179609 ) <andrewNO@SPAMthekerrs.ca> on Friday December 17, 2004 @01:27PM (#11117246) Homepage
    Most of these vulnerabilites come down to checking user input. If you are properly checking user input against a set of known good values and rejecting any input that is not a match, your chances of being vulnerable decrease dramatically.
    Yes, I'm a big fan of php, but like any language out there, there are vulnerabilites. PHP had a bigger problem with register_globals being defaulted to on. Not to make light of these vulnerabilities, but if you are checking user input (assuming you're not using a downloaded package) you should be pretty safe.
    • "Most of these vulnerabilites come down to checking user input."

      While many programming languages have "tainting" mode, are there any IDEs which use syntax-highlighting to display tainted variables in red, up until the line where they're sanitized (for various configurable definitions of sane)?

      (p.s. don't bother patenting it, this comment is prior art)

  • Question/Comment (Score:4, Informative)

    by realdpk ( 116490 ) on Friday December 17, 2004 @01:31PM (#11117293) Homepage Journal
    Question:

    "Note: Due to a problem with earlier versions of Zend Optimizer, its users are urged to upgrade to the latest version."

    I can't seem to find any information on what this problem may be. No release notes or anything. Any clues?

    Comment:

    PHP.net's download scheme is worse than Sourceforge's if you can believe that. Therefore, here are some unPHP.net-ized URLs:

    US2 [php.net]
    Belgium [php.net]
    Finland2 [php.net]

    You'll find you can actually right-click and save these and they won't prompt you for a filename "mirror" or something useless like the rest of PHP's download links.

    • Advisory: Multiple vulnerabilities within PHP 4/5
      Release Date: 2004/12/15
      Last Modified: 2004/12/15
      Author: Stefan Esser [sesser@php.net]

      Application: PHP4
      Severity: Several vulnerabilities within PHP allow
      local and remote execution of arbitrary code
      Risk: Critical
      Vendor Status: Vendor has released bugfixed versions.
      References: http://www.hardened-php.net/advisories/012004.txt


      4.3.10 contains the fix.
  • I've currently tried installing a version of PHP 5.0.3 over the current version of 5.0.2, but it ends failing on make:

    http://bugs.php.net/bug.php?id=31104 [php.net]

    Has anyone else run into this problem? If so, please vote on this so that it's fixed for 5.0.4 ;)

  • Why isn't hardened-PHP merged with PHP? (Score:5, Interesting)

    by DarkHelmet ( 120004 ) * <mark&seventhcycle,net> on Friday December 17, 2004 @01:37PM (#11117380) Homepage
    I know this is just a thought, but why aren't the changes within Hardened-PHP within the actual version of PHP that's on the site.

    Their implementation of memory checking seems to be sane and valid for all installs. So why are most of us running vanilla like this?

    Just a thought.

  • Upgraded to 4.3.10... (Score:2, Informative)

    by Bravid98 ( 171307 )
    And it seems to have compatibility issues. It ended up breaking custom code of mine, as well as Invision Power Board. This was compiled from scratch. Hopefully they'll quickly release a .11.
  • Why can't it be Monday? I mean, do the people that make these announcements think we _like_ working weekends?

  • Check your inputs!!!! But not an impressive record (Score:5, Insightful)

    by dwheeler ( 321049 ) on Friday December 17, 2004 @01:59PM (#11117637) Homepage Journal
    Thankfully, most of these problems are easily countered by what you always have to do anyway: you MUST check and severely limit what you allow as input. Letting users provide arbitrary-length data that's then used in realpath is a bug in the first place!

    The unserialize() bug issue is rather serious, though.

    It's true that all systems have vulnerabilities, but that does not mean that all systems are equally secure. What you want is a track record that shows good things. Frankly, I'm not all that impressed with PHP's track record so far. The good news is that the PHP developers have been willing to change critical pieces (like turning off globals) to deal with security issues, and it looks like at least some of them are taking security more seriously. But I'd really like to see evidence of serious steps to not just provide a niftier OO model, but provide a programming language where programs are more likely to actually withstand attack. PHP has a lot going for it, but an implementation that can't handle harsh attacks is simply not appropriate for today's network.

    I'd like to see Hardened-PHP, or something like it, merged into the mainline PHP. Why is it that only some users will get a PHP that tries to defend against attacks? Does this mean that other PHP users never get attacked? Does this mean that PHP programmers have stopped making common mistakes? Nonsense. There's no reason that there has to be a separate project to modify PHP to be secure against attack; that should be part and parcel of PHP itself. The performance impact is tiny, and much less important than keeping control over your own machine. Why should anyone be impressed at the speed of a system that's about to be controlled by an attacker?

    One of the best ways to get a secure setup is to find out what product has the better security track record with evidence of a secure design (modular parts, etc.), and switch to one of them. That's true whether it's OSS or proprietary; OSS is no guarantee of security, it simply makes some kinds of worldwide review possible. Using Internet Explorer or Outlook? Switch to Firefox and Thunderbird [dwheeler.com]. Using Sendmail? Switch to Postfix. That doesn't guarantee perfection, but you're generally better off in the long run. I think you could make a very good case for switching from PHP to Perl or Python or Java. If the PHP folks want to keep their large user base, they need to get on the stick.

  • If (Score:2, Funny)

    by Alioth ( 221270 )
    If PGP stands for Pretty Good Privacy, does PHP stand for Pretty Hopeless Privacy?
  • Just when I had *FINISHED* upgrading our system to 4.3.9. Seriously, couldn't they choose a more appropriate timing?

    Oh well... here goes another one. :-/

  • About time (Score:3, Insightful)

    by Billly Gates ( 198444 ) on Friday December 17, 2004 @03:46PM (#11119000) Journal
    These bugs and many many others have been known for a long time.

    Not to sound trollish but the FBI and computer security groups label PHP with more holes than ASP. No joke.

    Its nice to see the php team begin to take security seriously. Especially if they want lamp to ever replace Java or ASP on many corporate webservers and intranets.

  • warning! 5.0.1 - 5.0.3 "breaks" EMPTY() function (Score:3, Informative)

    by phpsucks ( 841320 ) on Friday December 17, 2004 @04:13PM (#11119294)

    Watch out when upgrading!

    <?
    $a = 'foobar';
    print empty($a->nothere) ? 'empty' : 'not empty';
    ?>

    This code prints 'empty' with 5.0.1, but 'not empty' with 5.0.3.

    You must check all your code for the use of empty() with a string!

    I wish PHP would warn everyone about this sort of thing.

    Here is the man page...nothing said about it: http://www.php.net/empty [php.net]

  • Not just for script kiddies this time (Score:5, Informative)

    by Anonymous Coward on Friday December 17, 2004 @05:43PM (#11120182)
    I don't have an account, so chances are no one will ever read this. However, if you are reading this, then I thank you.

    This exploit has been known about in select hacker groups since late October. The first script for the kiddies was released last weekend (December 11 - 12) and it most certainly originated in Brazil. The group responsible for the initial wave of terror call themselves "H4ck3rsBr", and most of the defacements were done by none other than the infamous "S8ldier". No doubt he wrote a proof of concept for phpBB right away, seeing as how he's always first to the scene with new phpBB exploits involving PHP.

    If you're running forum software that sits on top of PHP, upgrade PHP before it's too late. These guys took out a friend's Linux server because he caught them right in the middle of defacing his clients' websites (just index.html's). They had a rootkit installed and made sure to cause as much damage as possible before being booted off. After backing up the filesystem, re-booting the machine failed, as the partition table was toast and most of the important data sectors had been trashed as well.

    I'm glad that the PHP team decided to fix this, but I'm also hopeful that the phpBB, vBulletin, etc. teams will start validating their input a little more carefully.

Slashdot Top Deals

What is research but a blind date with knowledge? -- Will Harvey

Close