Security - 6

I want to give some thoughts about some more advanced XSS-issues based on two vulnerability announcements I recently made.

First is backend XSS. I think this hasn't been adressed very much, most probably all CMS have this issue. If you have a CMS-System (a blog is also a CMS system in this case) with multiple users, there are various ways where users can XSS each other. The most obvious one is that it's common practice that a CMS gives you some way to publish raw html content.

Assuming you have a blog where multiple users are allowed to write articles. Alice writes an article, Eve doesn't like the content of that article. Eve can now write another article with some JavaScript adjusted to steal Alice's cookie. As soon as Alice is logged in and watches the frontpage with Eve's article, her cookie get's stolen, Eve can hijack her account and manipulate her articles.

Solution is not that simple. To prevent the XSS, you'd have to make sure that there's absolutely no way to put raw html code on the page. Serendipity for example has a plugin called trustxss which should do exactly that, though there are many ways to circumvent that (at least all I found should be fixed in 1.3-beta1, see advisory here: CVE-2008-0124). All fields like username, user-information etc. need to be escaped and it should be the default that users aren't allowed to post html. If a superuser enables html-posting for another user, he should be warned about the security implications.

A quite different way would be separating front- and backend on different domains. I don't know of any popular CMS currently doing that, but it would prevent a lot of vulnerabilities: The website content is, e.g., located on www.mydomain.com, while the backend is on edit.mydomain.com. It would add complexity to the application setup, especially on shared hosting environments.


Second issue is XSS/CSRF in the installer. I'm not really sure how I should classify these, as an open installer most probably has more security implications than just XSS. I recently discovered an XSS in the installer of moodle (CVE-2008-0123) which made me think about this.

I thought of a (real) scenario where I was sitting in a room with a group, discussing that we need a webpage, we would take Domain somedomain.de and install some webapp (in this case MediaWiki, but there I found no such issues) there. I suddenly started implementing that with my laptop. Other people in the room hearing the discussion could send me links to trigger some kind of XSS/CSRF there. This probably isn't a very likely scenario, but still, I'd suggest to prevent XSS/CSRF also in the installer of web applications.

Over two years ago, it was announced that the security scanner nessus will no longer be free software starting with version 3.0. Soon after that, several forks were announced. For a long time, none of these fork-projekts produced any output.

openvas was one of that forks and from my knowledge the only one that ever produced any releases. It recently had 1.0-releases for all packages, I just added ebuilds to gentoo.

While openvas isn't perfect yet (many of the old plugins fail, because some files had to be removed due to unclear licensing), it's nice to see that we have a free, maintained security scanner again that will fill the gap left by nessus.

About one year ago, Sam Hocevar posted some results on tests with his fuzzing tool zzuf, which showed a large number of crashes in various applications, especially multimedia apps.
Crash bugs on invalid input very often lead to security issues, thus this should be taken seriously.

Now, I took the freedom to have a look how many of the issues found back then were fixed. I used the most current versions in gentoo linux (testing/~x86-system), which tend to be quite up-to-date. I also cross-checked the crashes for other apps, as they often use the same or similar code.
Seems only vlc devs did their homework (Sam Hocevar is part of the vlc team). Interesting enough, even firefox seems to have a gif-crasher since a year.

gstreamer crash by lol-ffplay.mpg lol-gstreamer.m2v lol-mplayer.m2v lol-mplayer.mpg lol-vlc.m2v lol-vlc.mpg
endless loop by lol-ffplay.m2v lol-xine.mpg

mplayer hang by lol-mplayer.wmv,
crash by lol-ffplay.flac lol-mplayer.aac lol-mplayer.mpg lol-mplayer.ogg lol-ogg123.flac lol-vlc.aac lol-xine.aac

xine crash by lol-mplayer.wmv lol-ffplay.m2v lol-ffplay.ogg lol-ffplay.wmv lol-gstreamer.avi lol-ogg123.flac lol-vlc.aac lol-xine.mpg

firefox crash by lol-firefox.gif

Ich hatte in jüngster Zeit eine Kundenanfrage, die sich mit dem Betrieb eines Flash Media Streaming Servers außeinandersetzte. Nun finde ich ein Produkt ja schon dubios, wenn ich keinen Wikipedia-Eintrag dafür finde (wobei es verziehen sei, dass das möglicherweise an der Löschwut mancher Wikipedia-Admins in den vergangenen Monaten liegt).

Aber die Produktbeschreibung (von Adobe) ist echt göttlich, deswegen möchte ich Euch das nicht vorenthalten:

Flash Media Streaming Server 3 unterstützt RTMPE, eine erweiterte Version des RTMP-Protokolls (Real Time Messaging Protocol) von Adobe. Mit verbesserter Leistung und 128-Bit-Verschlüsselung bietet das neue Protokoll effektiven Schutz für per Streaming übertragene Medieninhalte. Eine neue Verifizierungsfunktion verhindert, dass SWF-Dateien von unbefugten Anwendern wiederverwendet, geändert oder gehostet werden.

Ich glaube für sowas wurde mal der Begriff Snakeoil oder Schlangenöl erfunden.

Recently I had a discussion with someone about the security of various linux distributions where he claimed Debian stable to be very secure and that they use old versions where they backport all occurances of security issues. This is a common assumption, too bad that it's wrong.
I want to document this to demonstrate the dangerousness of opinions like »stay with the old software«, »never touch a running system« and alike that are not limited but often found in the Debian community.

I had a look at the security policy on a package recently very popular for it's vast number of issues, namely php. Their last php-update on php5 was in july. They have a heavily patched version of php 5.2.0 and according to their changelog the last thing they patched was CVE-2007-1864.

Now that probably means that CVE-2007-3996, CVE-2007-3378, CVE-2007-3997, CVE-2007-4652, CVE-2007-4658, CVE-2007-4659, CVE-2007-4670, CVE-2007-4657, CVE-2007-4662, CVE-2007-3998, CVE-2007-5898, CVE-2007-5899, CVE-2007-5900 are unfixed. Oh, and before you ask: This list certainly is incomplete, it's just what I found without much hassle.

Not only looking at php5, php4 is still officially distributed by many vendors, some hosters still use it. You can't really blame them, as php.net announced it to be supported until 2007-12-31. But that's theory, in fact, nobody looks if the various recent issues also apply to php 4, most recent advisories don't mention it. Fact is, at least CVE-2007-3378, CVE-2007-3997, CVE-2007-4657, CVE-2007-3998 also apply to php 4 and are unfixed in their latest release 4.4.7 (not neccessary to mention that they're not fixed in the debian stable php4 package).

If someone prefers to stay with old software, it's up to them. But be serious. It's probably a hell-job to get all the recent security issues in an app like php backported to some ancient version. A quick check showed me that debian isn't able to do that. If you can't do that, don't claim it's in any way »supported«. Because doing that put's other people in dangerous situations.

I recently stepped upon some XSS issues in Serendipity.

The first is in the remoterss-plugin, which can be used to display the content of an RSS feed in the sidebar of a blog. It didn't escape links, so JavaScript-Code could be injected by malicious RSS feeds. This plugin is shipped with the base version of S9Y. They've released 1.2.1 this weekend which has the fix.
If you're using the remoterss plugin, you should upgrade to 1.2.1 as soon as possible. This issue is named CVE-2007-6205.

The other one is in the external mycalendar-plugin. It also allows unescaped content inside links. This wouldn't be a real issue, as this form should only be accessible by the blog administrator. But the form had no CSRF (Cross-Site-Request-Forgery) protection, so an attacker could trigger this form and thus inject javascript on the blog-page. This has been fixed within version 0.13 of the plugin, so if you're using it, please upgrade. CVE-2007-6390 now assigned.

Beside I'd like to note that I got fast replies to my reports and the s9y devs fixed them quite quickly. Thanks for that!

Gestern war wieder Webmontag in Karlsruhe. Ich hielt einen Vortrag über Datenschutz und Datensparsamkeit bei Webservern, im Kontext von Wir speichern nicht und dem kürzlichen Urteil gegen das Justizministerium, welches IP-Speicherung untersagte.
Die Diskussion war lebhaft, wobei es sehr schnell in Richtung juristische und politische Fragen ging, während der Vortrag sich eher auf die Technik bezog.
Slides Datenschutz und Datensparsamkeit als OpenDocument

Desweiteren gab es einen Vortrag zu OpenSocial, Bilder vom Barcamp und der Web 2.0 Expo Berlin und Lästereien über den neuen Kalender vom Karlsruher Stadtmarketing.

A big problem with web security in the past was that it was impossible to have https-hosts with more than one certificate per IP. This is due to the protocol design of https, which needs to establish an ssl-connection with the certificate before the hostname is transferred.

There is a solution though, called Server Name Indication (SNI) and part of TLS. Strange enough, client compatibility isn't that much of a problem. Firefox, Opera and IE already support it in their current versions, konqueror will with kde4, I've no information when it'll hit safari. Oh, and I haven't testet w3m, lynx, links and wget yet, but if you want, feel free to add your experiences to the comments :-)

The problem was that until some weeks ago, openssl didn't support SNI, apachen mod_ssl didn't, lighttpd didn't. Only GnuTLS, but mod_gnutls is considered unstable by it's authors. With OpenSSL 0.9.8f, TLS Extensions and with them SNI landet in openssl, apache still needs patches.

We've now implemented SNI on schokokeks.org, which you can test:
https://www.schokokeks.org/
https://www.hboeck.de/
https://www.fabian-fingerle.de/

If your browser supports SNI, you should see different certificates, all on the same IP. All certs are cacert-signed, they also have a Wiki page from the VhostTaskForce for SNI and alternative solutions.

One of the biggest threats in computer security today are web applications. There's a vast number of issues found in popular web apps, mostly cross site scripting, cross site request forgery and sql injection. For a long time I had the idea of a tool scanning through webroots and looking for popular web applications, comparing them with a database of their latest security issues. In the past weeks, I finaly managed to get some code done.

It's a quite simple python-script (don't cry about the source quality, I haven't done real coding for ages), together with a database of some popular applications. I'm looking forward to hear feedback. The usage is simple, just do something like this:
freewvs /home/joe/websites/foo /home/guest/websites/bar
Typical output looks like this:
WebsiteBaker 2.4.3 (2.6.5) CVE-2007-0527 /home/hanno/freewvs/test/websitebaker
Drupal 5.1 (5.3) CVE-2007-5416 /home/hanno/freewvs/test/drupal
PhpWebGallery 1.5.1 () CVE-2007-5012 /home/hanno/freewvs/test/phpwebgallery
Mostly self explaining. The found app at the beginning, the version where the issue was fixed in brackets, the CVE-ID (or some other vulnerability id, in doubt an URL) and the path.

The biggest work to do is probably to get more applications added to the database and to keep the database updated. It's format is pretty self-explaining, so I'm waiting for your patches.

Get it here: https://freewvs.schokokeks.org/

Wolfgang Schäuble versucht sich wohl neuerdings als Komiker. Anders kann ich mir kaum die Meldung erklären, dass sich das Innenministerium bemüht, ein Prüfsiegel für Datenschutz in Unternehmen voranzutreiben.

Ich versuche mir das gerade vorzustellen. Man stelle sich vor, ein derartiges Prüfsiegel, nebst einem Newseintrag »Werte Kunden, aufgrund der neuen Verschärfungen im Bereich der Vorratsdatenspeicherung sind wir leider gezwungen, unsere bisherigen hohen Standards betreffend die Privatsphäre unserer Kunden aufzugeben".

Liest man weiter, erfährt man, dass es in Schleswig-Holstein bereits ein ähnliches Verfahren gibt - welches unter anderem Microsoft für sein Lizenzprüfungsverfahren erhielt. Naja, ich denke das sagt dann auch alles.

Für mein eigenes kleines Unternehmen kann ich versichern, dass wir weiterhin nach Kräften um den Datenschutz und die Sicherheit unserer Kunden bemüht sein werden - wir uns allerdings sehr ernsthafte Sorgen machen, wie lange wir das noch dürfen.

Kleine Lehre von heute: Es ist prinzipiell keine gute Idee, wenn die Fehlermeldungen eines Web-Frameworks die Zugangsdaten zur Datenbank enthalten. Wenn sich dann gleichzeitig noch unter leicht auffindbarer URL ein phpMyAdmin befindet, ist das eher noch schlechter.
(URL und Projektname gibt's erstmal nicht, weil das bislang nur teilweise gefixt wurde)

Desweiteren soll es jetzt ein neues, aktiveres Stadtblog für Karlsruhe geben. Vielleicht schreib ich bei Gelegenheit auch mal das ein oder andere.

Ansonsten gab es einige Ideen in Richtung Barcamp auf Wasser (Bodensee oder Rhein). Hört sich erstmal ziemlich cool an, bin gespannt was daraus wird.

Links: Webmontag Karlsruhe

I thought I'd give you some more (all have been informed months ago):

http://thepiratebay.org/search/"><script>alert(1)</script>
http://www.gruene.de/cms/default/dok/144/144640.dokumentsuche.htm?execute=1&suche_voll_starten=1&volltext_suchbegriff="><script>alert(1)</script>
http://www.terions.de/index_whois.php?ddomain="><script>alert(1)</script>
http://www.eselfilme.com/newsletter/newsletter.php?action=sign&email="><script>alert(1)</script>
http://www.region-stuttgart.de/sixcms/rs_suche/?_suche="><script>alert(1)</script>
http://reports.internic.net/cgi/whois?whois_nic="><script>alert(1)</script>&type=domain

I still have some unresolved xss vulnerabilities around. It seems to be common practice by many web application developers and web designers to ignore such information.

This time we have gobi, a cms system based on the quite popular javascript application server helma.

http://int21.de/cve/CVE-2007-3693-gobi.txt

More to come. As this xss stuff is far too easy (try some common strings in web forms, inform the author, publish some weeks later), I think about doing some kind of automated mechanism to search and report those vulnerabilities.

Der Bundesrat hat heute das obskure Verbot von »Hacktools« abgesegnet. Wohl ohne großen Widerstand, wiewohl praktisch jeder, der sich auch nur ansatzweise damit auskennt, das ganze für völlig absurd halten muss. In seltener Einigkeit warnen vom CCC über die GI bis zur Bitkom alle vor dem Gesetzeswerk.

Aber weswegen ich das hier schreibe: Die tagesschau erklärt das ganze sehr brauchbar, was ich dachte, dass ich doch mal lobend erwähnen kann. Vielleicht ein kleiner Beitrag, dass auch nicht-Techies derartiges besser verstehen.

I recently wrote that I'm sometimes a bit unhappy how security issues are handled in free software project.

Now, to have some contrast, today I'll talk about an example how to do it right. Serendipity, the software I'm using to host this blog, had an SQL injection vulnerability. On the same day, they announced it and provide updated packages. The finder of the vulnerability is also mentioned. Now, it is only able to get password-hashes, many other projects probably would've treated this vulnerability as »low-impact« or something like that.
But beside that, they also provide some tipps how to check if the vulnerability has already been exploitet and suggest to change user passwords.

A while back, there was another vulnerability reported in serendipity. The authors said they don't think that it's really a vulnerability and it probably can't be used for anything evil. But anyway, an update was released and announced just to be sure.

Now, that's good security-work. The fact that serendipity has very few vulnerabilities at all already is very good. The fact they treat the few ones proper is even better. Some other projects should have a look at that.