Interview with Stefan Esser
Stefan Esser has worked in several different security fields over the years, and is very well-known and respected within the security arena. He has been involved in several web projects (PHP/Java/Python/Ruby) which resulted in the PHP Hardening-Patch, the Suhosin PHP Security Extension and finally in the Month of PHP Bugs. Recently, he took part in the launch of a new web application security company “SektionEins GmbH“.
Earlier this year, you found a critical SQL injection vulnerability in WordPress affecting versions <= 2.0.5. How did you go about finding this vulnerability and how easy was it to exploit?
The trackback SQL injection vulnerability was found during my research of charset problems in web applications. I was scanning several PHP applications for their usage of charset functionality and ended up in the WordPress trackback code. When I saw how WordPress accepted arbitrary charsets and decoded data just before using it in database queries I knew immediately that UTF7 could be used to get an SQL injection through. Exploiting this is not difficult, but the naive approach to exploit the trackback injection is very noisy and will result in a lot of emails being sent to admin. If you look at the code of my exploit that was shared with the WordPress authors and was later on milw0rm.com, you will see that I used some tricks to get around this problem. So the basic exploit was simple, but doing it silently was not.
WordPress is certainly busy; the latest version is WordPress v2.2.1 and 2.3-Alpha is currently being worked on. What are your general thoughts on the popular PHP blogging software?
I think the WordPress software is the best blogging software around from an end user’s perspective. Its GUI is full of eye-candy and features that are not present in other blog software. But wearing my security hat, I see past this eye-candy onto the code and see several bad design decisions. This starts with how they interface with the database. Additionally, I consider some of their features quite dangerous. I personally dislike it when software encourages its users to have writeable files within the document root. WordPress’s feature to edit files/templates on the server does exactly this. The problem with this is that when I take over the admin account of a WordPress blog, usually nothing stops me from executing any PHP code on the system. And from that it is often only a small step to control the whole server.
We know that you have been somewhat critical of WordPress in the past; what were your reasons behind this?
I was critical of the WordPress development team because it did several things that are simply not okay. When you have fixed a direct remote code execution exploit in your development tree and there is
already an exploit for this flaw publically available, you cannot wait several days to release the update. And it is totally unacceptable that a vendor tries to downplay the seriousness of the vulnerability by statements like: “We have spoken with PHP security experts and they say this is not a serious vulnerability because it requires register_globals being turned to on.” Firstly, in reality, a majority of servers still switch register_globals to on and additionally, the wordpress.org server also
had it turned to on.And when they finally released their update, I told them that the fix was broken and the exploit just needed a modification to still work. Their reaction was to hide that fact by silently changing the download tarball. They did not increase the version number, they just fixed the vulnerable code hours after the update was out. And later they publically stated that the previous tarball was only online shortly, while the timestamps inside the tarball clearly proved that shortly were several hours.
I personally believe that when it comes to security updates, a software vendor has to tell the truth and ensure that people understand the threat. (Security) mistakes do happen and so do improperly fixed security flaws, but it is far more professional to admit that a fix was not perfect than to silently change the fix.
WordPress speculates that it has 2-3 million users. If this is accurate, it means that WordPress is definitely here to stay. What would your recommendations be for the WordPress core development team?
If I recall correctly, the phpBB guys at one point used their collected money and payed a security company to audit the software. I strongly suggest that the WordPress guys do the same. I am quite sure that there are still several vulnearabilities in WordPress. The free audits that they get from people releasing advisories will never cover the whole code base. And maybe they should start thinking about a complete rewrite that uses another architecture. When I think about the WordPress way to stop SQL
injection, which is basically a homebrewn magic_quotes_gpc, I shudder. With another architecture they could ensure from the beginning that things like CSRF or even XSS cannot exist.
Considering the flaws that have been found in WordPress and its plugins, where do you see WordPress going in the future?
WordPress is a software for end users with low or no technical know how. Of course there are also admins and developers using it, but the majority of WordPress users do not read security mailing lists. They will usually not know about all the security flaws that were found. And I am sure the majority of them will just upgrade if they learn about the security update and not think much about it. The majority do not care about these vulnerabilities until their own blogs get hacked, and even
then, they might simply reinstall and start over. That said, I believe that the security holes in WordPress might scare some developers/admins away but the majority of its users will continue
to use it.
What do you think of the WordPress alternatives available?
I don’t know too many WordPress alternatives. Basically for me there is just Serendipity/S9Y. In my opinion the Serendipity code quality is better than the WordPress code quality, but Serendipity is simply not as user-friendly. Because of the smaller code base, it is easier to audit and therefore leaves a better feeling in my stomach. Additionally, I know many of its authors personally.
What one improvement would you make to WordPress?
I would actually do two things:
- Switch off the SQL error messages, because they give far too much information to potential attackers.
- Ensure that the default SQL tableprefix is not chosen during installation.
When both changes are implemented (maybe they have been since I last tested WordPress), then SQL injections in WordPress will get a lot harder to abuse.
Stefan can be reached at his blog, "http://blog.php-security.org/"
Random Posts
If you enjoyed this post, please leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Comments
Maybe one reason for playing down these security flaws is that they’re afraid of the possible loss of users, when these start to think to make suicide when using Wordpress. I for myself would enjoy to see a security revise the whole wordpress code, for flaws. This would at least grant security for the core, although it’s no guarantor that future versions will stay secure(as humans do mistakes). And it will not grant that your used plugins are secure as well, but you can avoid to turn off comments and such features to stay safe(to mention some recent post against wp).
Anyway in my eyes blogsecurity is a great way to produce even more security for WP and you can turn off some leaks you don’t need with your help.
I just realised that my last point is a bit hard to understand.
What I meant is to ensure in the installer that every blog has a not easily guessable tableprefix.
The last SQL vulnerability in serendipity demonstrated how useless many SQL injections become when the table prefix is not known. In WordPress it is however no protection at the moment, because the error message of WordPress tells the attacker the correct table prefix.
[...] BlogSecurity-Blog hat Stefan Esser interviewt (in Englisch), der sich wohl schon seit Jahren mit dem Thema Sicherheit von Web-Anwendungen [...]
David, aside from 2.2.x and the trunk let’s also not forget that the 2.0.x line is still being maintained/supported with 2.0.11 at RC5 despite being (very quietly) reported to be released shortly for a couple months now.
but the majority of WordPress users do not read security mailing lists. They will usually not know about all the security flaws that were found. And I am sure the majority of them will just upgrade if they learn about the security update and not think much about it. The majority do not care about these vulnerabilities until their own blogs get hacked
Being the organizer of a Wordpress meetup group in NYC as well as someone that tries to contribute to the online community, I’m in touch with “end-users” on a regular basis. What Steffan says here doesn’t even extend far enough. Even the end-users with the technical know-how to do upgrades properly on their own seldom do or wait a good while first often fearing “breaking something” when they upgrade. Part of it is the way releases are handled but a big part of it is the huge amount of third party plugins, themes, and customizations that people use and often depend on. Therein lies the rub. The huge base of community-supported extras are a very large part of what keeps Wordpress on top as a blogging platform but it also makes things more complex for most when it comes update time. It’s not usually as straight-forward as updating the core and being done with it as most users have some level of customizations in place. Any way you stack it, the update process is simply a hassle the majority of users won’t deal with even when they should know better.
It was really discouraging to read Matt’s recent post on security. Instead of taking the opportunity to open up constructive dialogue about how to improve security, the upgrade process, or other issues with a vast community of creative individuals that would likely come up with some good suggestions (such as Stefan’s for starters), the whole post is just an overly defensive reaction to some critical blog post riddled with immature attacks on the offending blogger and featuring a plug for two of their affiliate hosting services as the answer for the best way to do updates. The whole thing downplays the importance of the issue of security at a time when people need to be woken up from their false sense of it more than ever (for the web in general, not just WP). To the average user it’s equivalent to reassurance that security concerns are unwarranted as evidenced by the supportive and unquestioning tone of most of the 100+ comments left.
David, you’re doing a great job with this site and making even part of the vast WP community more security-aware would be a wonderful thing and a goal I could definitely get on board with. The question becomes how to do so if the devs and community leaders don’t want to be co-operative without having their hands forced? I’m not saying that’s the case, but rather the feeling I get given past experience and capped off with the above post.
Thanks to both of you!
Regards,
Jason
Seguridad en WordPress: ¿podríamos vivir sin plugins?…
Vía el Planet Webdev acabo de leer a Alex que comenta dos noticias relacionadas a la seguridad en WordPress. Un tema candente. Copio (corrigiendo un “propuesta” de más) los dos puntos de la entrada de Alex:
Existe una propuesta par…
Del, Phil, Jason: its a pleasure, thanks for your guys feedback.
wonderful thing and a goal I could definitely get on board with
Jason I may hold you to that :)
Drat, hehe. ;)
Actually please do try to hold me to that. About to head out at the moment, but I have a couple ideas and a couple questions that I’ll contact you with later.
Cheers,
Jason
[...] Interview with Stefan Esser on Wordpress security. Very interesting read, and Stefan has some very valid points in regard to how issues are being adressed. [...]
@Jason and others about upgrading: The reason it takes so long for people to upgrade WP is because it’s such a MAJOR pain in the arse to upgrade:
1) Download new wordpress
2) backup
3) turn off all plugins one by one
4) copy files a & b over c & d, but DON’T copy over files e through f, unless you’ve done g. If you’ve still got a file h, then replace it with i.
5) run update script
6) turn on plugins one by one.
If this could be streamlined in some way, then people would upgrade a LOT quicker.
–Simon
wordpress needs to go away. the admin section alone is deplorable, static spaghetti code. try turning it into a cms.
Simon:
Well stated.
Plus many times the upgrades cause incompatibility with the plugins you mentioned but you won’t know till you try making upgrading right away a risky proposition. Even so you just end up spending more time looking for newer versions of the plugins or fixes mentioned here or there. It can be a nightmare.
There’s a good post about the structural problems with Wordpress, upgrading, plugins, lack of documentation, etc. over here that I feel does an excellent job of highlighting one of the major challenges/issues when it comes to keeping up to date and secure.
Hino: Oddly enough I feel the same way most days, but then I think about the entire web that way. The fact of the matter is we have to work with what we have. Adoption is very slow for any sort of changes in standards let alone technology so we have to work at improving what we’ve got…. and right now what we have is a huge installed base of Wordpress users. At this point telling them to use something different would be fairly thoughtless. It’s bad enough people are constantly having to keep up with constant changes in software they don’t want new versions of in the first place (ahem, Microsoft).
Jason
I’m not saying that’s the case
Jason, I’m afraid this IS the case, and probably so at least in the short future. This is Matt’s standard. I still remember when there is a modified tarball on wordpress server (2.1.1 days), what Matt told in wp-hacker list is “get the new tarball, it’s important.” He doesn’t even whisper the word ’security’ in public, and of course, not to mention nowhere can I determine whether my installation is vulnerable. Finally, I only found the information badly needed via digg.
[...] interviju ar Stefan Esser (drošības eksperts, kas ir strādājis pie dažādiem lieliem projektiem, tostarp [...]
[...] Heinze developed WP Prefix Table Changer for the BlogSecurity toolbox. The idea came from Stefan Essar BlogSecurity Interview recently, where he suggested changing the WordPress table prefix from the default "wp_" [...]
[...] php und Security auseinandergesetzt hat (hardened-php Project), beklagt dies in einem Interview mit BlogSecurity. Auf ebendieser Seite, BlogSecurity, findet sich auch ein Tool, mit dem man seine [...]
[...] aktualiert und auch ein wenig in den Wordpress-Datenbanktabellen aufgeräumt, sowie, wie in dem BlogSecurity.net-Interview empfohlen, die default Wordpress-Tabellen-Prefixe abgeändert. Scheint alles soweit zu [...]
[...] Esser, of “Month of PHP Bugs” fame, is particularly critical — a week or so back he gave an interview on BlogSecurity.net about the problems with WordPress, citing architectural problems that make it [...]
[...] ^ http://blogsecurity.net/wordpress/interview-280607/ [...]
Interesting interview that certainly makes me ask some questions for myself. Thanks for information.
i was wondering if anyone knew of a wordpress security mailing list/rss feed that pretty much just covered that. because mostly i dont want to sift through a bunch of bugtraq looking for wordpress stuff that’s relavent.
[...] security by Stefan Esser Interview with Stefan Esser on Wordpress security. Very interesting read, and Stefan has some very valid points in regard to [...]
[...] security overhaul. You want to read something frightening? Read this interview with PHP security expert Steffan Esser about the serious problems with WordPress security. In [...]
[...] Esser, un experto en seguridad PHP, ha concedido una entrevista a BlogSecurity donde disecciona los mecanismos de seguridad de [...]
[...] security overhaul. You want to read something frightening? Read this interview with PHP security expert Steffan Esser about the serious problems with WordPress security. In [...]
You can find a new interview with Stefan Esser here: http://www.phphatesme.com/archives/780
[...] Remarkable. It’s been two weeks since the WordPress 2.7 release, and of the 67 bugs posted for 2.7.1, none of them are security related. That doesn’t mean they’re absent, but it’s notable considering its security track record. [...]
Thanks for your comments Stefan, made very interesting reading and brought out some nice ideas.