Slashdot Mirror
PHP Vulnerabilities Announced
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."
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).
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.
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.
Perhaps you've been asleep when every other software package releases updates/bug-fixes/security patched.
Apache: 85% of the internet can't be wrong.
Please sir, dismount yourself from that high horse you are riding on.
What would you recommend instead?
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!
urpmi libgcrypt11 libgcrypt11-devel libcryptopp5-devel libcryptopp5-static-devel
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.
http://request-header.info
If this was an asp.net exploit people would be saying XP, or Server2003 was insecure. Even though IIS isn't installed by default.
Have you ever been to a turkish prison?
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. 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.
- David A. Wheeler (see my Secure Programming HOWTO)
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 this regard.
Yup, because it is a *LOT* harder to install, and administer. It's all scary black magic, and down right confusing.
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!
This tagline brought to you by 1500 monkeys in just under 17 years.
"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
PHP needs taint.
evil is as evil does
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?
Click here or a puppy gets stomped!
I would disagree.
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.
Lose Weight and Feel Great with Isagenix
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 isBecause 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 submitUsing 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).
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
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).
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.
http://saveie6.com/
Yeah, then spend 6 hours wrestling with mod_jk so it will play nice behind Apache. Its either that or use Tomcat to serve your static files, which is silly, if you have any traffic.
SpyDock: Scientific Python in a Docker container