English

Recently, two publications raised awareness of a problem with ssl secured websites.

If a website is configured to always forward traffic to ssl, one would assume that all traffic is safe and nothing can be sniffed. Though, if one is able to sniff network traffic and also has the ability to forward the victim to a crafted site (which can, e. g., be just sending him some »hey, read this, interesting text« message), he can then force the victim to open a http-connection. If the cookie has not set the secured flag, the attacker can sniff the cookie and take over the session of the user (assuming it's using some kind of cookie-based session, which is pretty standard on today's webapps).

The solution to this is that a webapp should always check if the connection is ssl and set the secured flag accordingly. For PHP, this could be something like this:

if ($_SERVER['HTTPS']) session_set_cookie_params( 0, '/', '', true, true );

I've recently investigated all web applications I'm using myself and reported the issue (Mantis / CVE-2008-3102, Drupal / CVE-2008-3661, Gallery / CVE-2008-3662, Squirrelmail / CVE-2008-3663). I have some more pending I want to investigate further.

I call security researchers to add this issue to their list of common things one has to look after. I find the firefox-extension CookieMonster very useful for this.

The result of my reports was quite mixed. While the gallery team took the issue very serious (and even payed me a bounty for my report, many thanks for that), the drupal team thinks there is no issue and did nothing. The others have not released updates yet, but fixed the issue in their code.

And for a final word, I want to share a mail with you I got after posting the gallery issue to full disclosure:
for fuck's sake dude! half of the planet, military, government, financial sites suffer from this and the best you could come up with is a fucking photo album no one uses! do everybody a favor and die you lame fuck!

If you didn't know it, today is Software Freedom Day.

Just noticed that, when you surf to http://cgi.softwarefreedomday.org/map.shtml to look if there's something happening around you on SFD, you'll get a proprietary google map.

It seems that the organizers of the SFD can't look beyond one's own nose. I often saw this behaviour in parts of the free software movement (being ignorant about proprietary stuff if it's not software), but found this example especially frightening, as we have a well working alternative.

Today my new IBM/Lenovo Thinkpad T61 8895WFJ laptop arrived. While my P30 did a good job, it really was time to replace it.

I'm currently in the phase of installing Gentoo and getting used to the device, but I think it was a very good choice.

Beside the fact that Lenovos are probably popular for a reason, the 1400x1050-resolution, the well Linux-supported Intel-graphics and a quite acceptable weight (2,4 kg) were reasons for this model. I'm still in favour of 4:3 screens, because if you wanna have a 16:10 one with a decent resolution (e. g. > 1000 pixels height) they become either very expensive or very heavy. I still wonder why no vendor seems to produce 4:3 screens any more (from my research, not a single Montevina laptop has 4:3).

Some time soon you'll probably find some documentation about Linux on the T61 8895WFJ at http://www.int21.de/t61/.

I recently played around with the possibilities of fuzzing. It's a simple way to find bugs in applications.

What you do: You have some application that parses some kind of file format. You create lots (thousands) of files which have small errors. The simplest approach is to just change random bits. If the app crashes, you've found a bug, it's quite likely that it's a security relevant one. This is especially crucial for apps like mail scanners (antivirus), but pretty much works for every app that parses foreign input. It works especially well on uncommon file formats, because their code is often not well maintained.

My fuzzing tool of choice is zzuf.

I am impressed and a bit shocked how easy it is to find crashers and potential overflows in common, security relevant applications. My last discovery was a crasher in the chm parser of clamav.