PHP Vulnerabilities Announced 387
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."
Upgrade. (Score:4, Insightful)
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).
double standards (Score:4, Insightful)
Of course... (Score:5, Insightful)
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.
Re:I've said it before, and I'll say it again (Score:2, Insightful)
Apache: 85% of the internet can't be wrong.
Please sir, dismount yourself from that high horse you are riding on.
Re:I've said it before, and I'll say it again (Score:2, Insightful)
Java/J2EE/JSP
You can mess up security policies and implementations with Java, but it is much harder to shoot yourself in the foot. The JVM may have bugs, but because it is used for all Java applications, it is likely well-debugged and secure
Language features eliminate security problems. For example, the Java JVM does something incredibly advanced: bounds checking!
Re:Can't compile 5.0.3 (Score:1, Insightful)
urpmi libgcrypt11 libgcrypt11-devel libcryptopp5-devel libcryptopp5-static-devel
Re:I've said it before, and I'll say it again (Score:2, Insightful)
But scripting languages are what applications are made of! Right?
I don't think it matters what you use. (compiled or script) There will be an exploit/flaw.
You can shuck all of your PHP and write mts components in VB or even compile your server side stuff as ANSI C, but nothing is going to be perfect.
IMHO what matters s how fast vulnerbility information is published after found and how quickly it is fixed.
Hypocrisy of slashot (Score:2, Insightful)
Re:double standards (Score:5, Insightful)
Check your inputs!!!! But not an impressive record (Score:5, Insightful)
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.
Re:Third-party modules? (Score:3, Insightful)
Re:double standards (Score:5, Insightful)
Re:I've said it before, and I'll say it again (Score:3, Insightful)
Er. Download tomcat. gunzip and untar. place JAVA_HOME into catalina.sh. Set a manager account in the config file. Start it up. It's one of the easiest installs I have ever done.
Installing, starting, and stopping individual web apps is all done with a simple web interface. It's one of the easiest systems to administrate I have used.
Compare to PHP, where on some Linux distros the only way to get it working is to compile it yourself, along with specific versions of apache.
Tomcat also has the advantage that its trivially simple to run everything as non-root, for security: You just untar it into a user account and start it there!
Re:So sad ... (Score:2, Insightful)
Re:I've said it before, and I'll say it again (Score:4, Insightful)
"p.s. I know squat"
We have a winner!
Installing a JVM and an application server is about 99% less time consuming, and easier, than a comparable PHP installation.
Check Resin Quickstart [caucho.com]
Re:Check your inputs!!!! But not an impressive rec (Score:3, Insightful)
It like what my DB prof said about Oracle v. MySQL (Score:5, Insightful)
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?
Re:PHP is to Perl as Java is to C++ (Score:5, Insightful)
I've programmed in PHP for 5 years and have successfully used it to feed my family the entire time.
I haven't had any problem with security vulnerabilities since day 1 (I write all of my own software rather than using any particular package).
It has scaled easily to meet my needs, including an e-commerce site that does $3,000,000+ a year in orders. Granted that is small potatoes for some, but that is irrelevant.
What is relevant is that PHP is fast and easy to develop in, easy to debug, and easy to deploy. It does what I need it to do, and it does so successfully.
In my mind it is well designed for it's intended purpose.
There is no sense picking apart a screw driver and saying what a bad hammer it is. It isn't a hammer. It wasn't designed to be a hammer. It will never be a hammer.
For my purposes PHP is well designed and is the best tool for the job I've found. I've looked into many other tools, but hands down the winner for my needs is PHP. Trust me, if there were another tool that offered the same power AND ease AND was more profitable for me to use overall, I'd be using it. If it exists, I haven't found it. This isn't a religous pursuit for me. I don't care what the "best" programming language is. I'm here to feed my family and PHP serves that purpose well.
Re:Third-party modules? (Score:2, Insightful)
Stored procedures work kind of like SUID scripts for a database -- they let the database user execute code with the procedure owner's permissions. For example in an E-Commerce application, a user might legitimately need to get his own credit card number out of the database, but he has no business getting anyone else's database.
Let's assume we have the CC table keyed by UserID, and the webapp provides the UserID when it wants to get that user's CC number. We'll assume the user has already logged in and the application knows the user's userid. The naieve approach taken by most programmers is to construct the SQL statement on the client-side using the (previously validated) UserID, and then submit this to the SQL Server using a webuser account:
User xj9-4t-7070, using the system as intended, would result in the intended SQL statement being submitted to the SQL Server: However This kind of construct is flawed because it's vulnerable to SQL injection. If a hacker is able to put an arbitrary value into $UserId, he can run ANY sql statement the webuser has permission to execute. Let's say he manages to set $UserID to xj9-4t-7070';\nselect * from CCTable where UserID != ', now the SQL being submitted is Because the webuser account must have select permission on CCTable to work for a legitimate user, it can run ANY arbitrary query on that table. Using stored procedures, the legitmate user would submit a query like: And the attacker would submit Using the stored procedure, the webuser only needs to be granted execute permission on the GetUserCCInfo stored procedure, and would not have any permissions to access CCInfo table directly. Therefore, all the attacker would get is a "permission denied" message instead of a dump of all entire CCInfo table.We're still vulnerable to the attacker brute-forcing the CC numbers out one at a time, which is why we need to use a reasonably large random value for the UserID instead of something trivially guessed (like a monotonically increasing sequence of integers).
Re:double standards (Score:1, Insightful)
Re:Third-party modules? (Score:2, Insightful)
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).
About time (Score:3, Insightful)
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.
Re:I've said it before, and I'll say it again (Score:3, Insightful)