Hanno's blog

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.

War heute mit Fabian beim CCC Stuttgart, um über OpenStreetMap zu reden.

Der Abend war recht gut besucht, aus diesem Anlaß gibt's natürlich auch wieder aktuelle Slides.

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!

Da ich mich sowieso im Umkreis befand, beteiligte ich mich heute an der Demonstration gegen die Baustelle von europas größter CO2-Schleuder, dem Kohlekraftwerk Neurath.

Nachdem ich mich mal wieder darüber geärgert hatte, zwar auf einer von der Deutschen Bahn WLAN-fähig ausgestatteten Strecke zu fahren (Mannheim-Köln), aber nicht in einem der WLAN-fähigen Züge (das vergisst die Bahn in ihrer Werbung über den WLAN-Ausbau nämlich regelmäßig zu erwähnen, dass auch auf den ausgebauten ICE-Strecken nur ein Bruchteil der Züge tatsächlich WLAN verfügbar macht), fiel mir ein Netz auf, welches sich »Free Public WiFi« nannte und wohl offen war. Da aus dem fahrenden Zug aber wohl kaum Chancen auf eine Verbindung bestand, ignorierte ich es zunächst.

Nachdem das Netz aber ca. 10 Minuten später immer noch da war, musste es sich zweifelsohne mit mir im Zug befinden. Mir fiel auch auf, dass es sich um ein Ad-Hoc-Netz handelte, was die Vermutung nährte, dass es sich um einen anderen Laptop handelt. »Free Public WiFi« empfand ich nun als Einladung, mit diesem zu kommunizieren. Bedauerlicherweise schien es mir weder DHCP noch sonst irgendwelche sinnvollen Services bieten zu wollen. Lediglich eine IP lies sich ersniffen, die jedoch nur zwei offenen Ports hatte, die auf eine Windowsfreigabe hindeuteten - wodurch ich bemerkte, dass ich gerade kein Samba installiert hatte.

Ein Weilchen später waren dann plötzlich zwei »Free Public WiFi«-Netze verfügbar, was die Sache ja noch spannender machte. Möglicherweise experimentieren da unweit von mir zwei Menschen mit irgendwelchen Mesh-Technologien - und ich hab keine Möglichkeit der Kommunikation. Kurz vor Frankfurt schienen beide Netze jedoch den Zug zu verlassen.

Abschließend durfte ich noch verärgert feststellen, dass wohl neuerdings am Frankfurter Flughafen ein Login mit T-Online nicht mehr möglich ist, ich insofern auch hier, eine sonst recht zuverlässig funktionierende Möglichkeit (relativ langer Halt, gute Netzabdeckung), kein Netz erhielt und dieser Blog-Eintrag wohl noch bis heute abend warten muss, bis er online geht.

Falls jemand sachdienliche Hinweise hat, was »Free Public WiFi« gewesen sein könnte und in welcher Form ich es mir hätte nutzbar machen können, wäre ich um Mitteilung dankbar.

Yesterday I did some maintenance of our server configuration and wondered what would be the correct way to handle unconfigured virtual hosts. E. g. what http-response should come if someone just enters the IP of our server or a domain that just isn't used for http.

At the moment, we're shipping a html-page explaining that it's an unconfigured domain, which is probably okay, but we ship it with HTTP code 200 (which means »OK«). I thought it should probably ship with some kind of error code so that search engines know there's no real webpage.
Now, reading RFC 2616 (HTTP 1.1) didn't answer the question to me. Most near is probably a 404, others we considered were 403, 503 or 204, but non of them seems to really match that situation. Maybe I should write some enhancement request to the IETF...

Comments appreciated, what would you think would be the correct status.