Slashdot Log In
PHP Security Expert Resigns
Posted by
samzenpus
on Thu Dec 14, 2006 01:57 AM
from the good-day-sir dept.
from the good-day-sir dept.
juct writes "PHP security holes have a name — quite often it was Stefan Esser who found and reported them. Now Esser has quit the PHP security team. He feels that his attempt to make PHP safer "from the inside" is futile. Basic security issues are not addressed sufficiently by the developers. Zeev Suraski, Zend's CTO of course disagrees and urges Stefan to work with the PHP development team instead of working against it. But given the number of remote code execution holes in PHP apps this year, Esser might have a point. And he plans to continue his quest for security holes in PHP. Only that from now on, he will publish them after reasonable time — regardless if a patch is available or not."
Update: 10/30 12:57 GMT by KD : Zeev Suraski wrote in to protest: "I'm quoted as if I 'point fingers at inexperienced developers,' and of course, there's no link to that — because it's not true! The two issues — security problems in Web apps written in PHP, and security problems in PHP itself — are two distinct issues. Nobody, including myself, is saying that there are no security problems in PHP — not unlike pretty much any other piece of software. Nobody, I think, argues the fact that there have been many more security problems at the application level, then there were at the language level. I never replied to Stefan's accusations of security problems in PHP saying 'that's bull, it's all the developers' fault,' and I have no intention to do it in the future."
Related Stories
[+]
March To Be Month of PHP Bugs 292 comments
PHP writes "Stefan Esser is the founder of both the Hardened-PHP Project and the PHP Security Response Team (which he recently left). During an interview with SecurityFocus he announced the upcoming Month of PHP bugs initiative in March." Quoting: "We will disclose different types of bugs, mainly buffer overflows or double free (/destruction) vulnerabilities, some only local, but some remotely triggerable... Additionally there are some trivial bypass vulnerabilities in PHP's own protection features... As a vulnerability reporter you feel kinda puzzled how people among the PHP Security Response Team can claim in public that they do not know about any security vulnerability in PHP, when you disclosed about 20 holes to them in the two weeks before. At this point you stop bothering whether anyone considers the disclosure of unreported vulnerabilities unethical. Additionally a few of the reported bugs have been known for years among the PHP developers and will most probably never be fixed. In total we have more than 31 bugs to disclose, and therefore there will be days when more than one vulnerability will be disclosed."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
PHP Security Expert (Score:5, Funny)
Isn't that an oxymoron?
Re: (Score:3, Funny)
I know exactly nothing about PHP...
... I take the utmost care over security and this was the first ever breakin.
Would you call blindly installing a server side scripting language of which you know nothing 'taking utmost care over security'?
Re:Uh-huh, riiiiiiiiight... (Score:4, Interesting)
One cannot say it was PHP directly that got the machine compromised. It was an exploit in a script written in PHP.
A box isn't going to get compromised if PHP was installed alone on the box without any scripts (at least it's very very unlikely).
Is C the direct cause of your box owned when their is an exploit in say, proftpd for example?
I mean, I could also say...
"yeah, you'd have to be mad to run sendmail on a box you don't want to get owned"
"yeah, you'd have to be mad to run proftpd on a box you don't want to get owned"
"yeah, you'd have to be mad to run bind on a box you don't want to get owned"
"yeah, you'd have to be mad to run a linux kernel on a box you don't want to get owned"
These applications have all had their problems in the past, maybe some still have problems, but overall
they get fixed when new exploits/bugs are discovered.
I'm not quite sure why, but a lot of people/webmasters/admins do not check for updates to the 3rd party php scripts
they have installed, they just install them once and leave them running... Then they wonder why their box was compromised
due to them running out of date software.
You wouldn't leave your windows machine unpatched and never check for updates, would you?
Parent
Re: (Score:3, Insightful)
On second thought... (Score:5, Insightful)
just have a look [milw0rm.com]
Re:Question from a .NET developer trying to go OSS (Score:5, Insightful)
There sure are better alternatives to PHP in the OSS sector! PHP IMHO is a nice toy but nothing I would use in a commercial project.
A soon to be totally OS sollution is of course JAVA with Apache and Servlets/JSP. Just take a look at Sun's website, they have a lot of information, examples and tutorials available. Also, Java is totally plattform independent and easily installed on Windows, if that remains your development system.
Another, more recent sollution would be Ruby on Rails [rubyonrails.org], which has some realy niffty features.
And no, not a dumb question at all! One hint: If you got the time, just download the OSS you are considering ang play around with it, that's probably more usefull than my dumb answer. ;-)
Parent
Re:Question from a .NET developer trying to go OSS (Score:4, Interesting)
Rails is pretty cute. An more functional (but less "shiny") alternative is Catalyst [catalystframework.org]. It's written in Perl, which means you get the benefit of over 10,000 extension libraries from the CPAN [cpan.org] to draw upon. Perl also has some nice features that Ruby or PHP lack, like full native unicode support and automatic taint checking. It's also faster, because it's had 10 years to mature. Sadly people seem to be ignoring Perl these days, but with recent improvements it's nearly as cool as Ruby (check out "Moose").
Also, if you'd like to access a database with compound primary keys, ActiveRecord won't support that, but Catalyst's ORM (DBIx::Class) supports it fine.
Rails is good for quick apps like a wiki or a blog, but for more complicated internal applications, Catalyst is where it's at. Stop by the website, check out our advent calendar [catalystframework.org], or perhaps try the tutorial [cpan.org]. Join us in #catalyst on irc.perl.org if you have any questions!
Parent
Re:Question from a .NET developer trying to go OSS (Score:4, Insightful)
As the linked article said, this is an experimental patch + hack. With DBIC, you just do find({key1 => $val1, key2 => $val2}), which is a natural extension of the simple single-key case: find({key1 => $val1}). This all works very well in practice, as opposed to the it-might-work approach of ActiveRecord. I'm not saying you shouldn't use ActiveRecord... but I wouldn't use it.
> I am hesitant to try any framework whose partisans routinely bash other frameworks.
Bashing? I said it was good. There are some places where Catalyst is better, and some places where it's not as good. In my experience, Catalyst's good points make more complex applications easier (frontend to an HR system is what I've done), whereas Rails full-stack approach is great for CRUD applications. You're allowed to like both, ya know!
> I'm used to getting this from Python; it's refreshing to see a Perl guy screaming at the wind.
These people (I'm one of them) get upset because their languages are technically better than the alternatives, but "nobody" uses them, and they're shunned for not using PHP. "Perl is so 1996, man, use PHP or Ruby now." Irritating. use Perl;
Parent
Re: (Score:3, Funny)
Re: (Score:3, Funny)
The only Rails guy I see routinely mouthing off is DHH. Most of his invective (that I've read) is aimed at Java, though, which is a mitigating factor. J2EE is easy to bash because you'll be right most of the time.
Re:Question from a .NET developer trying to go OSS (Score:5, Insightful)
You pull java with eclipse, apache, strut/spring/hibernate/junit, then pull any database that hibernate supports, and you're in business.
There's a learning curve, but you won't feel like anything is missing from
Parent
Re: (Score:3, Insightful)
The blame for the PHP security mess should be shared between the language design, which makes it a hassle to write secure code, and the language popularity, which means that PHP i
Re: (Score:3, Insightful)
Well, maybe you should be. C is a horrible language to use for writing an entire application with. Plenty of safe, higher-level languages with simple to use FFIs exist that are much better suited to such things.
you keep telling yourself that. meanwhile, in the real world, C/C++ will remain the workhorse of the IT industry.PHP reminds me of IIS4 (Score:5, Insightful)
But even leaving all that aside - it seems like every SANS newsletter has multiple announcements either about a bug in some popular bit of PHP-based software, or else in PHP in general. Until that changes, we're sticking to Perl and Python. It's funny, in a way, since the first time I saw PHP I immediately thought of the days when I was writing Active Server Pages on IIS4, because structurally it is so similar - and now we all realize the similarities on the security side (or lack thereof) as well.
Open source is the issue (Score:3, Funny)
Re: (Score:3, Insightful)
Let's lock this person in a room with the OpenBSD developers.
Not a bad troll though.
Actual announcement (Score:5, Interesting)
Here's the announcement from the source himself, via his blog [php-security.org]. Based on that post I'd say he sounds pretty disgruntled with how his efforts towards security were received i.e. "he PHP Group will jump into your boat as soon you try to blame PHP's security problems on the user but the moment you criticize the security of PHP itself you become persona non grata"
Re: (Score:3, Interesting)
I'm not surprised. If you read the article, you come across this gem:
That's right, the PHP team think that dedicating a month to finding
XSS by default (Score:5, Funny)
As a PHP user.... (Score:5, Interesting)
In particular, the late static binding issue (if B extends A then A::staticFunc() ran as B::staticFunc() is ran under class A not B). It's like how it took MySQL took a decade to get stored procedures and views despite many people asking for it. Many people complain about the late static binding issue but last I knew it was still "it's a feature, not a bug."
Regardless, thanks for your work Mr. Esser...
Re:As a PHP user.... (Score:4, Funny)
Parent
PHP ought to be forked (Score:5, Interesting)
PHP could be turned into a decent general purpose scripting language if someone would fork it. Unfortunately that means that we'd need someone who knows the codebase, has time and is fed up with the current PHP development process. Maybe we could talk Esser into it...
Parent
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
Then a php to python coverter, and then we could start to forget about magic_quotes and safe mode.
Re:As a PHP user.... (Score:5, Informative)
I had a fun one where one of my scripts would cause a segmentationfault, after hours of debug I found that they don't check the return from malloc when you call a function, so a very deep recursive function will result in a segfault. Now I had the problem with an actual system with 1000s of lines, so I made the simplest possible:
function foo($a){
echo $a . "\n";
foo($a+1);
}
foo(1);
Now this is of course a stupid function since it will never terminate, but it illustrates the point of the segmentation fault, I don't mind that deep recursive functions can exhaust the memory available, but I do mind the way the system handles the problem.
The bug got rejected, and that was that. I don't do PHP anymore, so I don't really care about that any more.
Parent
he just left a mailing list... (Score:4, Informative)
Stefan Esser will continue to work on PHP security through maintaining the Hardened PHP project [1] which is a patchset to PHP which enables some low level security features into the language, as well as the suhosin extension [2] for PHP which can be used without patching PHP and "protects servers and users from known and unknown flaws in PHP applications and the PHP core".
I am personally of the "full disclosure" security mindset, so if there was indeed an issue with the response time of the "PHP Security Response Team" then some outside pressure would be a good thing.
More about this on Zeev's blog [3].
[1] http://www.hardened-php.net/ [hardened-php.net]
[2] http://www.hardened-php.net/suhosin.127.html [hardened-php.net]
[3] http://www.suraski.net/blog/index.php?/archives/1
Love the 'inexperienced programmers' excuse.. (Score:5, Insightful)
Personally I would wonder if Essers' 'abrasive style' is not a result rather than a reason for not being listened to and if this flags up a major problem in the way PHP is coded and maintained I'm all for this move. There is no excuse for sloppiness.
So, the reaction discloses the attitude - seems Esser made the right move..
Not up-to-date on PHP security . . . (Score:4, Interesting)
Re:Not up-to-date on PHP security . . . (Score:5, Insightful)
Then there is features like safe_mode that turns off many system functions that an attacker could use to get round the other restrictions, and register_globals which is a feature designed to work around an inherently insecure system of passing variables to php pages.
and so on, and so forth.. possibly the biggest problem is the ease of coding it, the barrier to entry is so low you will attract coders who (to be polite) don't know as much as they could about programming. So you get a lot of PHP code that is poor quality, makes too many assumptions on things that they should have tightened up (eg, not initialising variables to prevent an attacker from passing them in with their desired values), or checking input to functions from the form or url.
Its the same issue as VB - it was so easy to code VB apps, my boss could do it. So he did. And they looked, performed and crashed as if a manager had coded them
Parent
Re:Not up-to-date on PHP security . . . (Score:5, Informative)
Instead of changing concepts midway through they have added security layers and APIs that need to be *explicitly* set - meaning that like Windows (was?) they have a policy of being open per default and having to be explicitly made secure, instead of closed by default and enabling only what you need.
That's what I think Stefan Esser means when he says "safer from the inside". Many things in PHP are inherently flawed and can only be remedied through changes in concept and nothing else.
Add to that stuff like $GLOBALS overwrite (more details here [hardened-php.net]) that are/were essentially a WONTFIX. No wonder Essner is getting frustrated.
Parent
Re: (Score:3, Insightful)
It's impossible to write secure code elegantly in PHP. PHP is an inflexible language in which security features have been added using various options and functions. Any secure PHP code is going to be overly-difficult to read, and this can lead to insecurity via coding errors.
This inflexibility of the PHP code language is partially solved by the use of numerous extensions (There are gaps: For example, none of the extensions can parse HTML in a natural way). The more API functions and extensions required to
Re:Not up-to-date on PHP security . . . (Score:5, Informative)
Here are the most common security problems you run into in PHP:
Who would have thought "<?php include($var.'/include.php'); ?>" will run any PHP on any server, anyhere? (The attack in the article above leveraged entry using this, coupled with register_globals.)
The same goes for just about everything; are you checking whether some input equals some harmless number before passing it on to a SQL query or the browser? Don't forget that (5 == "5 UNION SELECT secret FROM
To check input in PHP you have to be absolutely rigorous and take no half measures, people who aren't aware of the dangers don't stand a chance.
To be honest I'm a big fan of PHP, it's very flexible and lets you develop very quickly and easily; if you have the knowledge and self discipline it's an excellent language. But allowing fast, easy development at the cost of security is insane for a server-side web scripting language!
I was hoping that PHP6 was all about doing a 180 degree turn on security, but this article doesn't bode well..
Parent
Here's an eye-catcher (Score:5, Insightful)
If that's accurate, and if there wasn't some unimaginable compelling reason, any security person would be unhappy.
No bad dogs, only bad owners (Score:3, Informative)
There's no denying that PHP has things wrong with it. It started out as a bastard son of Perl, tried to be a bit more n00b-friendly and tripped over its own cleverness. The beauty of Perl is its very inconsistency. The functions you use most have the shortest names, and there is no need to clutter things up with unnecessary brackets around arguments. Regular expressions, which you are going to use all the time, have a distinct syntax. Number and string data types can be interchanged with such wild abandon, there have to be separate operators for addition and string concatenation (JavaScript, I'm looking at you). There are constructs to populate arrays quickly. All things are subordinate to the goal of letting a programmer get a job done. Easy things are easy, hard things are possible. Perl is so broad-minded, it even has the Principle of Equivalence built in!
PHP lures you in, with obviously_named_function($par1, $par2)
Still, you've got two choices, I suppose. Learn to put up with the idiosyncracies or learn another language. And never forget the Principle of Equivalence; "All Means to the same End are equally valid", nor its corollary, "Means which are not equally valid serve different Ends".
If he returns to the PHP after discussions (Score:4, Funny)
Apologies to Douglas R. Hofstadter
If PGP... (Score:4, Funny)
Re: (Score:3, Funny)
I use a LAMP stack for the most part, many of the security holes in php aren't due to the language itself but the developers of the various webapps.
That being said, this requires a repost of the ol Adminspotting [adminspotting.org] thang.
Choose no life. Choose no career. Choose no family.
Choose a fucking big computer, choose disk arrays the
size of washing machines, modem racks, CD-ROM writers,
and electrical coffee makers. Choose no sleep, high
caffeine and mental insura
Re:Lemme guess... MySQL is also the best database? (Score:5, Insightful)
Way back when, when the Web was new, and CGI was just starting out, there was some debate as to whether C or Perl should be the language of choice for writing CGI scripts. In the end, Perl became much more widely used because it was just too damn easy to open up major security holes writing in C, because it lacked some of the features of Perl (like making it impossible to commit a buffer overrun, for example). Perl won out in early CGI precisely because a lot of the problems of CGI security were already solved because of inherent features of the language.
Now, PHP came along and billed itself (and in fact was designed) as an easy way to make secure web scripts. So, if the PHP code has bugs that impact its security in web-based applications, these things should be addressed. Otherwise, it's going to end up being supplanted by another language that is more secure and easier to use to build web apps.
Blaming the developer for security is only going to take you so far when the language the developer is using is supposed to be SPECIFICALLY DESIGNED for web applications.
Parent
Re: (Score:3, Insightful)
This reminds me a lot of the fundamental principle of politics:
In software, people with their feet so I bet this principle applies equally to this field.
Simon.
Shenanigans! (Score:5, Funny)
I call shenanigans! No way was PHP 'designed'!
Parent
Re:Lemme guess... MySQL is also the best database? (Score:4, Informative)
The classic example is the database access API (or maybe it's specific to mysql, I forgot). It doesn't support bound parameters. Use of placeholders ('?') and bound parameters is a must for secure SQL, but PHP doesn't support them, and instead requires the developer to jump through hoops escaping user-supplied data which must be passed as literals into the SQL statement.
Although it might be possible to make a secure SQL-using PHP script, the odds seem against it. Everytime I look at the changelogs of popular PHP applications, I see new fixes for SQL injection vulnerabilities. Clearly programmers don't always remember to escape those literals!
Lack of placeholders also affects the database's ability to cache prepared statements. Statements full of literals are different each time through the loop, whereas parameterised statements can be executed more quickly.
All in all, PHP strikes me as a toy language and not well suited to writing secure systems.
Parent
Re:Lemme guess... MySQL is also the best database? (Score:4, Informative)
It's obviously been a very long time since you've coded in PHP. The native PDO layer in PHP 5 supports bound parameters for all database drivers, and there are numerous other data abstraction layers that support this which have been around even longer.
Just because all these "popular PHP applications" you mention (care to cite examples?) don't follow good programming practice doesn't mean the language itself is flawed. PHP can't force someone to write good code.
Parent
Re:Lemme guess... MySQL is also the best database? (Score:5, Insightful)
Anytime the tool does something that the user doesn't want it's a bug.
This applies to applications, programming languages, heck even cars if you want.
The fact is that if the user gets something they didn't want, no matter how stupidly they tried to use it, the tool still bears some of the blame. I don't care how dumb a thing the user did, there was something there that made them think they could do that and it's a bug.
With programming languages if the language allows the user to create a security hole it's the fault of the language on some level. Sure you can get stupid programmers but blaming the programmer entirely discourages the search for a better language. Yeah if I overrun my array in C it's my fault. But can it be entirely my fault when in Java that same bug wouldn't be a security exploit? Hey, if I drive my car straight off a cliff, is that my fault? Yeah. But a car with a computer failsafe driver wouldn't of gone off the cliff (hey, if two jetliners are on a collision course the computer takes over).
You can never make the perfect tool, even a big green button that will do everything you ever wanted will still have a bunch of people who didn't think to push the button. But it forces you to realize, you can never fix users but you can always fix your code.
Parent
Re: (Score:3, Insightful)
Re:Lemme guess... MySQL is also the best database? (Score:5, Insightful)
Yes it does. It's a question of design, the design of the programming language, of its documentations and of its library can make security holes much harder to create.
When it actually becomes harder to do the wrong thing than to do the "right" thing, creating security holes becomes the fault of the user. When it's much harder to do the "right" thing than the "wrong" one, and most documentations suggest the "wrong" thing, then it's completely the fault of the language.
Most PHP issues are the latter.
Parent
In related news (Score:5, Insightful)
"All you should need is a great big red button that says 'Fire'" said Congressman Bobby Ewing "Its ridiculous that people are prevented from using these things and having to put up with safety devices it just encourages sloppying thinking"
"By letting people launch nuclear weapons with a big red button we are making sure that everyone is aware of how to properly care for their nuclear weapon and that it is their god given right and responsibility to fire it carefully" said some bloke in a hat "I'm fed up with all the ridiculous procedures I have to go through to fire a gun, let alone blow up France just because a few bleeding heart liberals feel they need to protect stupid people in New Hampshire"
In related new Iowa has banned the use of indicators, roll cages, air bags, crumple zones and seatbelts as it gives people too much sense of security. California has banned the use of door and window locks and the use of burglar alarms as they make houses "secure by design".
Secure by design is the only type of security that really counts.
Parent
Re: (Score:3, Interesting)
Oh wait, it hasn't has it. It is also why Apache had so many more security issues than IIS4 because Apache was used... oh hang on that one doesn't work either.
Maybe if you used you mouth rather than your butt for speaking you might make more sense.
As a PHP developer, I disagree (Score:3, Insightful)
Re: (Score:3, Insightful)
Quite often a quick-patch to slam a door is only a few lines. It may not be compatible with everything in the system, but it will do for some people. These patches never make it into the php right now and your ass is still uncovered for the skilled. It's interesting that you feel more comfortable wit
Re: (Score:3, Insightful)
The sorry fact is that those assholes *have* to be forced. You *have* to beat sense into them, since apparently they are not accesiible to reason.
So full disclos