Security Hole Found in 4.3.0 34
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."
Apache: Security Hole Found in 4.3.0 (Score:5, Funny)
eh? (Score:2, Insightful)
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? (Score:2, Informative)
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? (Score:5, Insightful)
Is It Just Me? (Score:2, Interesting)
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? (Score:1, Insightful)
Java still has occasional vulnerabilities. Java was designed with a very robust security model from the very beginning, however vulnerabilities still pop up [securityfocus.com] 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? (Score:2)
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? (Score:1, Insightful)
would be more appropriately (less inflammatory) 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? (Score:2)
Re:Is It Just Me? (Score:2)
Re:Is It Just Me? (Score:1)
cgi vulnerability (Score:3, Interesting)
Finally (Score:3, Funny)
Apache can have ALL the features of IIS.
</mandatory microsft bashing>
Re:Finally (Score:5, Informative)
Only people who use the CGI interface (which is probably very few apache users).
So posting it under "Apache" was sorta misleading.
Re:Finally (Score:2, Offtopic)
Epeche-a cun hefe-a ELL zee feetoores ooff IIS. Bork Bork Bork!
</mandatory microsoft borking>
I could be wrong but... (Score:2)
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... (Score:1)
amazing how fast security holes are being found... (Score:1)
What about older versions? (Score:3, Insightful)
so what (Score:1, Flamebait)
Re:so what (Score:1)
Re:so what (Score:1)
Net everybody has to upgrade (Score:1)
Re:Net everybody has to upgrade (Score:2)
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 (Score:2)
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 (Score:3, Insightful)