Slashdot Mirror
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."
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!
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.
This isn't as much "normalization" as it is "don't take so many drugs when you're designing tables."
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.
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.
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?
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