Security Hole Found in 4.3.0

Saint Aardvark writes "The good folks at PHP.net have warned of a serious vulnerability in PHP 4.3.0: 'Anyone with access to websites hosted on a web server which employs the CGI module may exploit this vulnerability to gain access to any file readable by the user under which the webserver runs. A remote attacker could also trick PHP into executing arbitrary PHP code if attacker is able to inject the code into files accessible by the CGI. This could be for example the web server access-logs.' It's recommend that you upgrade to 4.3.1 right away."

Comments

Apache: Security Hole Found in 4.3.0

[Trak]

Damn, I just installed 2.0.44. I'm so behind the curve!

Re:Apache: Security Hole Found in 4.3.0

[Anonymous Coward]

u mean u just installed apache 2.0.44 not php 2.0.44, right?

eh?

[Anonymous Coward]

Apache 4.3.0??? WTF??

oh wait, they're talking about PHP!!

and it looks like the CGI version, NOT the Apache module, correct? Please clarify for the morons in the audience such as myself.

So the 3 guys that actually use PHP as a CGI module can upgrade and the rest of us can go back to jerking off!

Re:eh?

[anthony_dipierro]

and it looks like the CGI version, NOT the Apache module, correct? Please clarify for the morons in the audience such as myself.

Not only is it only the CGI version, but it's only version 4.3.0 of the CGI version.

Um ... misleading title?

[legLess]

One would hope it could make made clear in the title (currently: "Apache: Security Hole Found in 4.3.0") that this is in fact a PHP hole, not an Apache one.

Re:Um ... misleading title?

[Anonymous Coward]

Not only that, but it doesn't even affect you if you use the apache module, so it's primarily for people running PHP under OTHER web servers.

Is It Just Me?

[4of12]

Or does it seem like PHP has been afflicted with a lot of vulnerabilities lately?

Maybe the number of news worthy PHP vulnerabilities is a testament to how widely the language is deployed. And, MySQL has had its share, too.

But the Apache and Linux components of "LAMP" seem to have been relatively secure by comparison.

Re:Is It Just Me?

[Anonymous Coward]

Blaming security vulnerabilities on a lack of OO principles is misguided and wrong.

Java still has occasional vulnerabilities. Java was designed with a very robust security model from the very beginning, however vulnerabilities still pop up on occasion. Albeit not very often, but they exist. J2EE is every bit as vulnerable to JVM exploits as any other Java application. Ultimately, it's the implementor who is responsible for security.

I can't speak to the internals PHP, it may be spaghetti code, but simply sprinkling magic OOP pixie dust will not remove any and all security issues. You can write an insecure program, regardless of design or methodology, if you don't know what you're doing.

PHP's remote file inclusion and execution -- this is a huge mis-feature from a security standpoint. Whether PHP is written in C++, assembler, Java, or Lisp; whether that feature is done with OOP and design patterns, that feature is dangerous regardless of implementation!

Look at OpenBSD. It's definitely not OO, however very robust, and historically, very secure. The programmers know what they're doing.

Ultimately, the programming team's collective experience, intelligence, and paranoia determines how secure any application is.

Re:Is It Just Me?

[sporty]

Blaming security vulnerabilities on a lack of OO principles is misguided and wrong.

No, I'm using OO as an example of the good use of it. Php has a problem with badly written internals, based off of spaghetti code and procedural programming.

Writing stuff in OO is a little harder to make memory leaks, while possible. Especially if you don't use malloc explicitly. Deleting all your objects (or implied in the case of garbage collection) as well as a well writen API, in the case of java and ruby, will help you not write bad code. It will help you keep organized. Dismissing OO is misguided and wrong as well.

Next thing I know, i'm gonna be told to dismiss seatbelts, since if I drive perfectly, I won't ever need them!

Re:Is It Just Me?

[Anonymous Coward]

I think it'd be safer, and more appropriate, to say "badly written internals" cause problems, than the lack of OO.

I believe it's a problem with the fact that PHP doesn't follow an OO paradigm.

would be more appropriately (less inflammatory) written:

I believe it's a problem with the fact that PHP is badly written.

I suppose we can agree that well-designed languages should, in theory, promote well-written code. E.g. see the discussion of Perl6, and doing away with crappy legacy syntax that only muddies the language.

However, we all know there isn't, and most likely never will be, a "silver bullet". Saying "X is bad because it's written [with|without] design paradigm Y" is generally misguided and wrong, at least for the majority of high-level ideologies like OOP or even XP.

Solid code, secure APIs, robust runtime environments -- these are not exclusive to OOP. I would almost go so far to say that newer languages such as Java, Ruby, Python (even C#, maybe) are on average more secure because they were developed within the last decade (or so), and the language creators had 20/20 hindsight into the shortcomings of other languages and libraries.

Re:Is It Just Me?

[sporty]

Not saying it's bad because of not using OO..just not using OO makes it easier. But hey, procedural spaghetti code is up to the designer, not me :)

Re:Is It Just Me?

[meme_police]

And Linux is relatively unsecure compared to other OSes. I prefer OAPP, OpenBSD-Apache-Postgresql-PHP.

Re:Is It Just Me?

[Anonymous Coward]

Apache sucks like a homo.

Re:Is It Just Me?

[Anonymous Coward]

How familiar are you with the internals of PHP and the Zend Engine?

Re:Is It Just Me?

[sporty]

A bit. I've looked into writing modules. Nasty stuff.

cgi vulnerability

[AllMightyPaul]

And just two articles down on the homepage, in the Developers section, there is an article about the dangers of using CGI. How ... ironic?

Finally

[Almace]

<mandatory microsft bashing>
Apache can have ALL the features of IIS.
</mandatory microsft bashing>

Re:Finally

[dietz]

Actually, if you install this as an apache module, you aren't vulnerable.

Only people who use the CGI interface (which is probably very few apache users).

So posting it under "Apache" was sorta misleading.

Re:Finally

[JediTrainer]

Epeche-a cun hefe-a ELL zee feetoores ooff IIS. Bork Bork Bork!
</mandatory microsoft borking>

I could be wrong but...

[SiMac]

I could be (and very possibly am) wrong, but doesn't this only affect you if you've installed PHP in your cgi-bin? Otherwise, you can't ignoring .htaccess files by calling PHP directly.

There will always be a local vulnerability where a user could install the PHP binary, but as long as you give users CGI access you are vulnerable to the same kinds of things through a Perl script or a CGI written in C.

Simon

Thank god...

[Jellybob]

it's just the CGI version... I saw this just before I went to bed, and didn't really feel like upgrading my PHP install.

amazing how fast security holes are being found...

[dougnaka]

we now find bugs in versions years before they're ever released, or even planned.... this must have been found by that new government department that monitors everything... would have helped to mention PHP in the title....

What about older versions?

[phr2]

Anyone know if 4.0.2 or 4.1.2 are affected by this bug? Do those versions have serious security probs of their own?

so what

[KilerCris]

4.3.0 is crap anyway. I upgraded to it and had nothing but trouble. Most servers I've seen are sticking with 4.2.3

Re:so what

[Anonymous Coward]

yay mysql_pconnect! ;/

Ah well, 4.3.1 is supposed to fix that too.

Re:so what

[KilerCris]

From Interesting to Insightful to TROLL?!?! Common!

Re:so what

[KilerCris]

lol...blow me

Net everybody has to upgrade

[jakobgrimstveit]

Note! This upgrade is only relevant for those who have enabled the CLI (command line interface) of PHP. Me, Myself and I can at least relax.

Re:Net everybody has to upgrade

[jericho4.0]

What. The. Hell. Are. You. Talking. About?
It seems you might be confusing acronyms or something. CGI != CLI.

Unless you're trying to make a joke, in which case, the jokes on me.

Thank god

[scrytch]

None of my apps use the number 4.3.0, so I'm safe.

Would it be too much to ask to make headlines make a smidgen of sense in the "older articles" section by actually including something like the name of the product affected?

Oh wait, it is.

PHP >= 4.3.0 is not a great update

[ptaff]

Class methods are not working as they should in PHP >= 4.3.0; I'd suggest to anyone who does OO in PHP to stay with 4.2.3 as long as they want to keep their scripts working. See for yourself this Bug report

Patch then, don't upgrade

[Anonymous Coward]

The obvious answer is to patch. I've had to rewrite tiny, but problematic, portions of my PHP code with every upgrade. However, a patch for the same version is a better solution to fixing the security problem. I'll upgrade when I have time and can plan and test properly.