Month of PHP Bugs Has Begun

An anonymous reader writes "The previously announced Month of PHP Bugs started three days ago, and already lists 8 security vulnerabilities in PHP and PHP related software. From the site: 'This initiative is an effort to improve the security of PHP. However we will not concentrate on problems in the PHP language that might result in insecure PHP applications, but on security vulnerabilities in the PHP core. During March 2007 old and new security vulnerabilities in the Zend Engine, the PHP core and the PHP extensions will be disclosed on a day by day basis. We will also point out necessary changes in the current vulnerability management process used by the PHP Security Response Team.'"

Defective by Design?

We see a lot of people use the phrase "defective by design" when talking about Vista and in that instance I'm pretty sure the use of the term is correct.

Having never used PHP but heard of its many security problems I'm wondering: Is PHP defective by design? If so, why so and how would Slashdot seek to fix it?

Simon

Re:Defective by Design?

Is PHP defective by design?

It was. A lot of work has been done in the last couple of major versions to fix this, but still a lot of installations are crippled in the name of backward compatibility.

Most of what we're seeing here though is just run-of-the-mill sloppy coding. Create a lot of references to a variable and overflow its (16-bit) reference count? Please. That should never have happened.

Fortunately, it seems most of the bugs released so far don't affect the majority of installations. We have a number of 'executing arbitrary PHP code can let somebody own your web server' -- well, most of us don't let random people run arbitrary PHP code anyway. We have some 'deserialising arbitrary data can let somebody own your web server' issues too, but then there has been a long-standing warning that PHP's deserialise function isn't secure anyway, so that shouldn't affect anyone who's been paying attention. We have some issues with the Zend Platform, but I'm not sure how many people have that installed. So far, the only issue to affect me, is the phpinfo XSS vulnerability -- and that just meant I had to delete my phpinfo.php file that I kept in the root of each domain I host.

Re:Defective by Design?

I think PHP has got beyond the stupid-design-flaws-causing-security-issues stage. Now, as you correctly point out, the major issue is endemic insecure programming practices and a lack of attention to bug reports.

How I wish we could just junk the language and start again with something else; unfortunately, market pressures being what they are, I'm afraid we're stuck with it, at least for the time being.

Re:Defective by Design?

Done. http://www.caucho.com/resin-3.1/doc/quercus.xtp [caucho.com]

Re:Defective by Design?

Actually, lots of people have abandoned PHP for Python and Ruby.

It may never completely go away, but there are alternatives to using it.

Re:Defective by Design?

> I had to delete my phpinfo.php file that I kept in the root of each domain I host.

if you left an open phpinfo() on your server (giving potential attackers access to filepaths, module version numbers, configuration options, apache server configuration options), you have a lot more to worry about than a little XSS.

unfortunatly, you're not alone [google.com].

Re:Parent isn't flamebait

So your webhost won't upgrade, and that's PHP's fault? PHP5 has been out a LONG time. Don't bother complaining about bugs in PHP4 simply because your website can't be bothered to upgrade. Find a decent webhost instead.

strpos() return FALSE when it can't find the 'needle'. http://us2.php.net/strpos [php.net] Use a proper test (===) and you'll have all you need in a single statement.

Some people really LIKE dynamically-typed variables. It's not a bug or a problem. It's a design choice.

Your flamebait at the end (vbscript) does nothing to enhance your argument. Leave it off next time.

Re:Defective by Design?

Nope. Definitely defective by lack of design.

Month of bugs, will it change things for better?

To be honest i'm glad that this month of bugs is happening, after all the previous news items about how the core php / zend team is refusing to colaberate with some ppl who are deeply concerned about php's security (and by this we do mean mistakes/faults in the php engine, not in bad php programming).

On the other hand, i bet a fair few of the released vunerabilities will be applicable for many websites that the company i work for hosts, and i know corperate policy doesn't include frequent updates to their envirioment, there's just to many sites, to many badly supported applications by/for customers, and just to damn many servers to work with easily, i can't imagine were the only such company with such problems... And it really makes me wonder if this will mean that many hundreds of our hosted websites will from now on be easily hackable by scriptkiddies

Should prove to be interesting times, and who knows maybe it will teach our admins to use yum/rpm's for their servers instead of compiling their own apache/php combinations :-)

Just in case..

To clarify, note that these bugs are related to the PHP core, not the language itself which may result in insecure applications. The statement that 8 security vulnerabilities in PHP and PHP related software is not referring to PHP software such as Wordpress. I mean seriously, I think I saw my dog hacking together a blog the other day using PHP. Everyone uses the language and not everyone has the background to know what they should and shouldn't be doing. In addition to its popularity, the language and its "libraries" make it easy for untrained coders to leave gapping holes in the code. Don't get me wrong, I love PHP (to an extend), I make a living out of it but any attempt at fixing "PHP related software" directly (ie: wordpress,phpbb,oscommerce,etc) would take more than a month.

vulnerable

Beware of the unexpected behavior of a program... it brings joy to hackers all around the world.

Typical

Stefan Esser has found some interesting yet not too surprising vulnerabilities in PHP. All those scenarios described in the various vulnerability reports are very typical for the development process of PHP and many similar ones have already been found and reported. The same goes for the fact that many of those are simply WONTFIX. A perfect example for the general attitude regarding a remote code execution vulnerability cited here [php-security.org]:

Because the PHP developers do not want to fix this anymore because it creates problems for companies providing closed source PHP extensions the only potential workaround is to manually change the size of the reference counter in your own PHP. However if you do so you have to recompile all your PHP extensions and cannot use closed source PHP extensions anymore.

I more and more get the feeling that the PHP developers themselves do not properly understand the vulnerabilities any more, which leads to improper and I even dare to say incompetent handling of reports and fixes (many of which simply get applied somewhere down the road without proper announcement or mentioning anywhere in the CHANGELOG) as well as seemingly ignorance regarding more complex vulns that are just as relevant as the glaringly obvious ones but simply not as mass-exploitable by script kiddies.

And *this* is the big problem that PHP is facing today regarding enterprise support. Maybe Jon Doe's blog installation is not as mass-exploitable by a script kiddie any more as it used to be some years ago, yet Big Company's CMS is still vulnerable to complex attacks by an experienced attacker who might use published attacks that security experts know about, yet end users do not.

Don't beleive it

Yes, but how many sites get hacked because of PHP and not because of faulty applications?

Not many.

Oh Nose!

"A deep recursion of PHP userland code will exhaust all available stack which leads to a sometimes remotely triggerable crash."

I've found a very similar bug in GLIBC!

int main(){
main();
}

This code will cause a segment violation!

Shock! Gasp! Horror!

PHP taint what it should be

We see a lot of people use the phrase "defective by design" when talking about Vista and in that instance I'm pretty sure the use of the term is correct. Having never used PHP but heard of its many security problems I'm wondering: Is PHP defective by design?

Maybe. PHP is a wonderful interpreted language that makes creating a web application easy. The biggest problem with PHP are the entry-level programmers who don't understand the beast that is web programming.

Many PHP programmers don't understand the number one rule of secure web programming: All user data is evil. Anything that comes from an HTTP request can not be trusted. Heck, I don't trust it even after it has been stored in a database table or the file system. I would love to see a Perl-ish taint mode built into PHP that tells the programmer "This data has come from an insecure source. Please don't eval() it or unserialize() it or write it to disk. Cheerio."

Re:PHP taint what it should be

Well then, you'll be happy to know that Wietse Venema from IBM Research put in a proposal for taint support in PHP a couple months ago. I'm not sure if anything has come of it as there was a fair amount of concern that it would turn into another "Safe Mode" debacle, but from what I remember his plan was to essentially start work on a proof of concept implementation early this year and then take it from there.

Be Prepared?

Since properly coded PHP is still useful in many applications, what would be the best book to use as an up to date reference manual for the most secure method of coding with it?

Why not use a lovely PHP FrameWork then?

Why not use a lovely PHP FrameWork then? Like, um, say, Drupal [drupal.org]?

- - - -

You can't be ahead of the curve, if you're stuck in a loop.

Next Month...

Month of Shooting Fish in a Barrel

Seriously, when does the Month of Oracle Bugs make its return? Or did the Month of Bugs folks simply chicken out when Larry Elison showed up at their house with a samurai sword?

Is there an alternative?

We can use Ruby on Rails.

perl is very good at text processing as well.

Are there any PHP-to-C++ translators? If the bugs are sitting in the PHP interpreter itself, it might be safer to translate and compile the code.

"Only perl can parse Perl" - but maybe there are alternative PHP parsers/interpreters?

Why MOPB Matters

I have just analysed the last month's script kiddie attacks on my web server. 71% of them were to php-related URLs. When I first went through this exercise some years ago, the overwhelming majority of attacks were URLs related to IIS. The significance of this change cannot be overestimated.

Yes, a lot of the problems are sloppy coding, but too many are in the PHP core. How many web pages use the PHP-array-specific query-string
    ?foo[]=bar
- not many, you might think. How many use a PHP nested array
    ?foo[][][][][]=bar
- quite an unusual structure, you might agree.

The real stinger is that PHP will let this array be as deep as an attacker likes - and it's the same for a POST as for a query string, so there's no practical limit. An attacker can exhaust the space available for the stack, with several adverse consequences. This bug has a lot in common with the gravest bugs in PHP's history, in that it is a mistake in PHP's input processing: in this case, PHP trusts the sanity of user input. According to MOPB, Zend's attitude to this bug is "won't fix".

The arrogance of this attitude is breathtaking. PHP is now the most insecure package on my internet server, probably surpassing the old BIND 8 in the frequency and gravity of its exploitable bugs. I sincerely hope that Zend will get its act together and make security their number one priority. The predominance of PHP on the web is not theirs as of right - if they do not act, then either their product will be forked, or an alternative will take its place.

The nested array bug is described here:
http://www.php-security.org/MOPB/MOPB-03-2007.html [php-security.org]

Programmers need to be aware

PHP is a scripting language that can be run as either a CGI application or as an integrated Web server module. Regardless of its mode of execution, the PHP interpreter has the potential to access virtually every part of the host -- the file system, network interfaces and etc. Consequently, it has the potential to cause a lot of damage. The programmer needs to be aware of everything that can go wrong at any time during the program execution,in order to prevent attacks from adversaries. And yes this is a formidable task. Software getting so complicated very fast. But somehow, ussually knowledge about the weaknesses of a system and the common modes of attack can go a long way toward increasing its security. Same goes to any other piece of software.

Re:Month of PHP Bugs Has Begun...

There are so many "Get me a portal, quick" / "I want to create a CMS that will make me rich" websites based on PHP based solutions that this exercise becomes obviously very important. It's surprising how many of such websites are severly insecure.

Re:Er...

Just one month?

lets hope someone fixes mail()

Re:die PHP die

I expect many of us have some heavy patching to do this month. PHP devs refused to take the opportunity to break BC and fix the language/runtime with PHP5.

When will OpenJDK be usable serverside? I think I'd prefer to spend the month converting a bunch of PHP apps to Java instead of applying patches.

not everything will benefit from the conversion. some objects take much time to construct in java, and generally things will perform worse. there are some things that can benefit from being a bean though. loading a huge array, of perhaps loginids statically would perhaps save some database work. it's hard to say. but for most people i would estimage 6-12 months for the conversions.

Re:In defence of PHP

the freak operators like === are a response to the lack of type safety. Not having stict types can be really usefull, and if you code well, irrelevant to the security or performance of your application.

Re:In defence of PHP

I cannot see why I should learn RoR, or Perl, when I have what works.

Because it is painfully obvious that you have no idea what you are doing, and thanks to PHP's lack of secuirty measures against inexperienced programmers, you are very likely creating tons of highly vulnerable programs.

Other languages tend to have much more secure APIs, letting you get away with not paying as much attention to security. Do yourself a favour and switch to one of them.

Re:In defence of PHP

Accessing Oracle from PHP is child's play. What's the mystery? Besides, the comment was about the extensions and capabilities. PHP is great, though perl is better. I don't know of any other languages that are as flexible in that regard.

Next, 120% slower under [undisclosed] circumstances. Browser rendering, network setup, capabilities of server/client, will impact things.

Additional, and this also relates to your 3rd point, there are are wide variety of PHP accelerators [wikipedia.org] which give PHP quite a speed boost. From Wiki: Most work by caching the compiled bytecode form of PHP scripts to avoid the overhead on every page request of parsing and compiling source code that may never even get executed. For best performance, caching is to shared memory with direct execution from the shared memory and the minimum of memory copying at runtime. A PHP accelerator typically reduces server load and increases the speed of PHP code anywhere from 2-10 times[...]

And yeah, PHP's fast and loose flexibility creates the necessity for things like === however the requirement that one is more aware of how types are handled is easily outweighed by the flexibility it gives the developer and the ease of use.

Re:In defence of PHP

Honestly? No.

The really big thing that PHP gets right - and it's so big that people often don't even see it - is that deployment is really, truly, brain-dead simple. Write some code, drop it in a folder, and it just works. You *really* can't say that about Rails, where you can about, say, CakePHP. This is mainly because Rails isn't internally thread-safe, but that's only a problem because mod_ruby uses a single instance of the interpreter for all requests. That makes mod_ruby a distinctly unpopular deployment target for Rails.

For smaller, non-Rails projects, Ruby can be a good option if simplicity of deployment is paramount, but as far as I know it's rather uncommon.

Re:Er...

Never heard of the September that never ended? [wikipedia.org].

Re:In defence of PHP

i did a lot of testing in my company that showed that creating large html forms from database content in php is 120% slower than in java.

And I did a lot of testing in my company that showed that programming large html sites with database content in java is 5000% slower than in PHP.

ever tried to access an oracle db from php? not fun

No, I don't consider it fun either. OTOH, it's very quick and trivially easy, so that makes the lack of fun doing it irrelevant.