Früher, da war ja noch alles gut. Da war die böse Regierung noch die böse Regierung, und man konnte prima dagegen sein, aber immerhin hatte man den Eindruck, daß sie zwar böse, aber wenigstens kompetent war.

Aber diese Zeiten scheinen ganz offensichtlich vorbei zu sein. Das ist natürlich kein Grund, aufzuatmen. Mit Inkompetenz kann man mindestens genausoviel kaputt machen wie mit Bösartigkeit, vielleicht sogar noch mehr.

Jüngstes Beispiel, das diesen Mangel an Fachkompetenz an zentraler Stelle illustriert, sind die Äußerungen von Frau Cornelia Rogall-Grothe, Staatssekretärin im Innenministerium und II-Beauftragte der Bundesregierung, vulgo "Bundes-CIO", zum neuen elektronischen Personalausweis in der FAZ. Die sagt da nämlich zum Beispiel:

Vor Schadsoftware am PC kann sich jeder wirksam schützen, indem er Virenschutzprogramme benutzt und eine Firewall installiert.

Liebe Frau Rogall-Grothe: wenn solche Programme so prima funktionieren, warum hat sich dann unsere Kanzlerin Schadsoftware aus China auf ihrem Rechner eingefangen? Wenn man nur ein paar Firewalls und Virenscanner braucht, warum dann die große Panik vor Cyberterrorismus? Oder vielleicht erklären Sie uns mal, warum zwar 99% aller Unternehmen und Behörden Firewalls und Virenscanner einsetzen, aber laut CSI Cyber Crime Survey 2009 trotzdem 64% der Unternehmen Infektionen mit Schadsoftware hatten?

Dazu kommen dann so Schoten wie

Die gesamte Technik ist sicher.

Nein, keine Technik ist "sicher". Diese pauschale Aussage ist schon ganz pauschal falsch. Als CIO sollte man sich mit Risikomanagement auskennen und wissen, daß eine Sicherheitstechnologie die Entrittswahrscheinlichkeit und/oder die Schadenshöhe eines Risikoereignisses reduziert. Reduziert, nicht beseitigt. Wirtschaftlich sinnvoll ist eine technische Sicherheitslösung genau dann, wenn die Kosten unter dem Erwartungswert des Schadensereignisses liegt (das ist die Eintrittswahrscheinlichkeit multipliziert mit Schadenshöhe). Komplementär dazu wird ein Angreifer einen Angriff nicht durchführen, wenn die für den Angriff entstehenden Kosten höher sind als der zu erzielende Gewinn. "Die gesamte Technik ist sicher" erinnert als nicht nur äußerlich an "Die Rente ist sicher" oder "Die Asse ist sicher", es steckt dieselbe, von Sachzusammenhängen ungetrübte Propagandadenkwese dahinter.

Aber es geht weiter in dem Stil. Der nächste Kracher:

Es gelten dieselben Sorgfaltspflichten, die bereits heute bei Internetanwendungen - etwa beim Online-Banking - zum Tragen kommen. Dazu gehört eine sichere Computerumgebung.

Online-Banking finde ich ein schönes Beispiel. Die Banken sind sich nämlich durchaus darüber im Klaren, daß all die schönen Firewalls und Virenscanner (was nach Frau Rogall-Grothe ja eine sichere Computerumgebung auszumachen scheint) das Risiko vielleicht verringern, aber keineswegs beseitigen. Mit zwei Konsequenzen: erstens übernimmt die Bank die Haftung, falls es trotz Erfüllung aller Sorgfaltspflichten zu Mißbrauch kommt (und ja, es kommt, massenhaft), zweitens beschäftigen die Banken Teams, die sich um solche Fälle kümmern und die das Löschen von Phishing-Seiten, egal wo sie betrieben werden, ungefähr um den Faktor 100 bis 1000 schneller hinbekommen, als das BKA das mit Kinderpornoseiten schafft.

Fast schon niedlich in der Naivität ist der zur Schau gestellte Glaube an Sicherheitsevaluation:

Emulieren kann man nur, wenn man die Geheimnisse aus dem Chip auslesen könnte. Das können Sie aber nicht, weil die Schlüssel nur in einem sicherheitsevaluierten Chip vorhanden sind.

Bei den "sicherheitsevaluierten Chips" handelt es sich um Smartcard-Security-Chips, derzeit NXP SmartMX. Dieser wurde vom BSI nach Common Criteria zertifiziert, und zwar auf dem Level EAL5+. Ganz abgesehen davon, daß man sich bei CC immer fragen muß, welches Protection Profile gemeint ist, ist EAL5 auch der Level, bei dem Schutz gegen Angreifer mit "moderate attack potential" erreicht werden soll. Insbesondere im Bereich der Chipkarten haben die Pay-TV-Hacker mehrfach gezeigt, wie "high attack potential" in der Praxis aussieht. Zu glauben, bei genau dem einen Chip, den noch niemand aufgemacht hat, würde das fundamental anders aussehen, ist schon ziemlich mutig.

Und einen habe ich noch, bevor ich die Lust verliere, da weiter jede Aussage einzeln auseinanderzupflücken. Da fragt die FAZ nämlich nach "Abstrahlung bei der Verwendung privater Schlüssel", also nach side channel attacks. Und die Antwort unserer Bundes-CIO ist doch glatt:

Wir setzen aber starke Kryptographie ein. Die Sicherheit dieser kryptographischen Verfahren ist mathematisch nachgewiesen und bestätigt. Ein Mitlesen ist also nicht möglich.

Da wünscht man sich echt mehr Gesicht zum Palmieren.

I'm currently working on migration to Windows Server 2008 and Windows 7 for a customer (don't laugh, it pays my rent). Said customer has a bunch of Solaris boxes, which are used as file servers, running Samba. Obviously, in such a setup you would want to have a single source of login credentials, the Active Directory (with UNIX support added) being a good choice. winbind, a part of Samba, does just that. Now with the existing W2k3 infrastructure, all is fine with the old 3.0 version of Samba. However, Server 2008 moved to NTLMv2, which Samba 3.0 doesn't understand. One could turn off NTLMv2, but this is equivalent to an open invitation to pwn all the boxes, so moving forward to a newer Samba is without alternative.

Ok, so I got myself the latest stable Samba source (3.5.6 at time of writing), spent a day or so installing a gazillion of packages on Solaris to have a working compilation environment, sweared a bit into the general direction of Heimdal, but ended up with a compiled samba. Another day of swearing, removing Solaris-packaged pam_winbind and nss_winbind libraries and replacing them with the freshly-compiled ones, and I was able to join the AD domain. Yay.

Just that it didn't work.

I double-checked nsswitch.conf, smb.conf, krb5.conf, pam.conf etc., but found no mistake. According to the documentation, all was well. But: no login for me.

So I thought I'd move to more familiar territory, and installed a recent Ubuntu server. Stuff actually worked a bit better there. Ok, it keeps forgetting I joined the domain once a day, but other than that, I was able to make it work.

Barely.

I could authenticate and access the smb shares. However, samba would pull a uid out of thin air, instead of using the one stored in AD (which, by the way, does so in a standard-compliant way, using the schema from rfc2307). Ok, more document reading, and I found there was a idmap plugin for AD, which was supposed to do the right thing. I followed the documentation, and lo and behold, domain user login stopped working for good.

Imagine a day of trying to make sense of the Samba logs and frantic googling here.

Finally, I found a clue in the samba.org wiki. There's a section there talking about the use of AD for idmap. And it ends with a comment:

Please note that from 3.0.25 on these values look different as one needs to use the new idmap stuff !
--Schlomo 05:59, 1 May 2007 (CDT)

WTF? This has changed three years ago, and nobody cared to update the documentation?

I finally found a link that helped me solve this issue. Deep inside the bowels of the samba.org web site, in the bug tracker, I found a bug somebody opened who ran into the very same problem I did. There also was a helpful comment by Michael Adam, who provided a working config example. Only two years after Schlomo's note in the wiki above. And more than a year later, the bug (which eventually was decided to be a case of "we should go around and document this stuff"), is still open.

But it gets worse.

After having succeeded on Ubuntu, I tried to port my results to Solaris. Unsuccessfully, as you might have guessed. The initial problem was that the build process didn't bother to compile and install the idmap ad module. That was easy to do manually. However, upon loading this module, Samba would complain about:

Error trying to resolve symbol 'init_samba_module' in /usr/local/samba/lib/idmap/ad.so: ld.so.1: winbindd: fatal: init_samba_module: can't find symbol

Rats.

Next step: I grep for this symbol in the source. Imagine my surprise to find out that this symbol is referenced exactly twice in the entire source code, both calls to dlsym(), related to loading the module. In the 30 or so modules however, not a single trace of this symbol can be found! I considered some black magic generating the symbol on the fly, but inspection of the .so with power tools ("string") confirmed the symbol is just missing.

Ok, so how did it work on Ubuntu, then?

Back to that box, and checking ad.so there. To my mild surprise, I found the symbol in the .so file, unlike on Solaris. Ok, apt-get source samba. And guess what, it downloaded an extensive patch (a whopping 136806 lines), which among other things contains code to add a #define idmap_ad_init init_samba_module line to confdefs.h. And that makes it work.

FFFFUUUUUUUU!!!

To sum it up, Samba documentation has been outdated in important parts, and the code base is in such a sorry state that it doesn't even properly build a single plugin, and all this must have been going on for years now. This implies a lot about the QA that's going on in the Samba project. My guess is somebody forgot to turn off the light at samba.org and tell us it doesn't exist anymore.

One of the classic vulnerability patterns in software is use-after-free, i.e., some pointer is accessed by the program even after the memory it points to has been returned to the memory management system. If an attacker can control the memory layout of the region pointed to, by getting the system to allocate some other object there, she gets into the position where control over program flow, and thus code execution, is feasible.

The Mozilla people have recognized this as an issue, and developed a mitigation strategy:

"Our approach is to prevent the first phase of the attack by making it impossible to overwrite fields of deallocated objects with values of the wrong type. We do this by ensuring that whenever the memory used by a deallocated frame object is reallocated to a new object, the new object must always be exactly the same type as the old object and at exactly the same address. Thus whenever code writes a value to a field of the new object, the value must be valid for the type T the program expects when it access that location through a pointer to the new object *or* the old object. Thus, dangling-frame-pointer attacks cannot get started."

This approach indeed makes it harder for an attacker to do something about a use-after-free situation. Now of course this pattern, together with its cousin, the double free, only appears in software that uses manual memory management. It would be entirely possible to use the Boehm-Demers-Weiser conservative garbage collector for automatic memory management in Mozilla, and there wouldn't be any use-after-free oder double-free problems to worry about.

I might be getting old and cynical here, but I fail to understand how people can be proud of such a kludgy workaround when real, solid solutions are available. Using a GC would also help against Mozilla's still present memory leaks...