Security

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!