Das R aus K&R ist gestorben

Jeder, der beim Lernen einer Programmiersprache sich mal an C rangetraut hat, wird „The C Programming Language“ in der Hand gehabt haben und es bestimmt bis zum Ende durch gearbeitet haben. Das ist nur einer der Meilensteine, die er und auch die anderen aus den Bell/AT&T-Labs gesetzt haben. Eigentlich würde es keins der gegenwärtigen Betriebssysteme so geben. Auch viele neuere Programmiersprachen haben ihren Ursprung in den Unzulänglichkeiten von C. Ach was schreib ich… hier geht’s weiter:  economist.com

Verschmähe die Trailer!

Immer wieder passiert es, obwohl ich mir schon hundert Mal (völlig übertriebene Zahl) vorgenommen hab, dass ich mir keine Trailer zu Filmen ansehen will. In der Regel sind es Filme, die erst mal überhaupt eine gewisse Aufmerksamkeitsschwelle überschreiten müssen (Titel, Schauspieler,Regisseur,Thema,…). Es ist auch viel einfacher geworden, seit ich keinen Verblödungsstrahler (vulgo: TV) mehr habe. Trotzdem lässt es sich auch im Netz, oder vielleicht gerade dort, nicht vermeiden. Und dann hat man doch mal auf den Link geklickt. Das endet dann bei mir damit, dass ich den Film nicht mehr sehen will. (Was zumindest für die Qualität des Trailers spricht) Aber die Vorfreude auf den Film, die Unvoreingenommenheit ist futsch. Die meisten Trailer (US-Streifen/Hollywood), die ich mal gesehen habe, erzählen eigentlich innerhalb von 2, 3 Minuten den kompletten Film. Bei schlechteren Streifen fassen sie auch die einzigen, wirklich sehenswerten Szenen zusammen. Ob das gewollt ist? Erscheint mir eher als eine selten dumme Idee.

Gib mir Werkzeuge

Als nächstes hätte ich gerne digitale Gegenmaßnahmen aus vertrauenswürdiger Quelle, die auch DAUs wie ich anwenden können #bundestrojaner (@holgi)

Das dem Trojaner innewohnende ist ja gerade der Versuch des sich Versteckens und unentdeckt zu bleiben. Wenn also nicht gerade Stümper am Werk sind, ist das Wissen der Notwendigkeit von Gegenmaßnahmen der Knackpunkt der Geschichte. Und das ganze auch noch DAU-gerecht zu schaffen, erscheint (fast) unmöglich. Ein IDS auf Basis einer whitelist hätte vermutlich viel zu viele Nebenwirkungen und ist letztlich auch nicht DAU-gerecht, weil ja das Wissen über gewünschte und unerwünschte Verbindungen auch von außen, vom Anwender kommen muss. Und das betrifft ja auch erst mal nur den Netzwerkverkehr des Trojaners. Vermutlich würde der schlaue Trojaner-Konstrukteur den Informationsab-/zufluss auch weitestgehend übersehbar machen, also zB. nur zulassen, wenn der Rechner gerade größere Mengen Pakete in’s Netz bläst oder lädt. Oder gar gleich in harmlos ausschauenden Paketen anderer Programme verstecken.

Und im System selbst? Eine spannende Frage, die die Analyse des CCC aufwirft, war die nach 64Bit-Windows-Systemen. Auf dem 32Bit-System konnte sich der Trojaner an beliebige Programme klemmen, bei den neueren 64Bit-Kisten sind ausführbare Programme signiert, dadurch kann eine Manipulierung sichtbar gemacht werden. Allerdings weiß ich an der Stelle zu wenig über 64Bit-Windozen, um sagen zu können, ob das auch für gerade laufende Anwendungen zutrifft (imo: schwer vorstellbar). Es gibt andererseits Software (zumindest kenn ich es von linux), die die Adressen und die Verwendung von Systemaufrufen überwacht und gegebenenfalls Alarm schlagen kann, aber die ist auch nicht als DAU-freundlich anzusehen.

Was bleibt denn dann noch? Hmm, eine gut bedienbare und bereits Expertenwissen verwendende Software, die gegen Trojaner  hilft, erscheint mir derzeit nicht in Sicht. Ich kenne jedenfalls keine, aber dass muss ja nicht heißen, dass es die nicht gibt.

kaputter flash-sound… und was das mit der glibc zu tun hat

Manch einer wird das vermutlich schon bei fefe gelesen haben, aus fedora-Kreisen gibt es Beschwerden über defektes Audio beim Abspielen von youtube-Videos. Betrifft mich jetzt erstmal nicht direkt, hier funktioniert das gut und stabil. Aber den Bugreport sollte jeder, der weiß, was memcpy und memmove sind, mal lesen.

Kurzabriss (aus meiner Sicht; alle Details versteh ich [noch] nicht): Von Intel-Leuten wird bei der glibc-Entwicklung ein Patch eingereicht, der die oben angesprochenen Speicherfunktionen für diverse Intel-CPUs (bei 64Bit-Systemen)  beschleunigt, teilweise erheblich (fefe ist der Meinung, dass die erhebliche Beschleunigung auf einen möglichen Fehler in der Atom-CPU zurückzuführen ist). Einzige Begründung ist eben diese Beschleunigung. Und diese Änderung krempelt die interne Arbeitsweise der Befehle um, was aber bedeutet, dass bestimmte Annahmen bei der Nutzung über den Haufen geworfen werden. Für memcpy(3) ist zB. eine Annahme, dass die Speicherbereiche von Quelle und Ziel nicht überlappen dürfen. Hat man diese Situation im Programm, ist memmove(3) zu nutzen. Bei Adobe wiederum hat man sich für diese Annahmen offensichtlich nicht interessiert, was bisher nicht negativ aufgefallen sein dürfte. In neueren Linux-manpages von memcpy fehlt da ein interessanter Nebensatz, der den Spezialfall der überlappenden Speicherbereiche als undefiniert bezeichnet. Und jetzt (tatsächlich wurde der Fehler schon im September/Oktober letzten Jahres diskutiert) führt diese Situation eben dazu, dass der bestehende Code im flashplayer mit der alten glibc-Version (Fedora 13) funktioniert, aber in der neuen Fedora-Version 14 nicht mehr. Kein großes Ding, möchte man meinen, es wurden auch verschiedene Würgarounds gefunden – der Fehler in der glibc existiert aber eben weiter. Wenig überraschend tauchen nach und nach weitere Programme auf, die plötzlich Probleme haben.

Was dann am stärksten in dieser Situation nervt, ist die Tatsache, dass die Verantwortung gegenseitig hin- und hergeschoben wird. Die Fedora-Leute (die imo keine Schuld trifft) meinen, dass das nur upstream (also bei den glibc-Leuten) zu behandeln sei; die glibc-Entwickler sagen, dass Adobe schuld ist, weil sie eben den Code nicht so einsetzen, wie das zu machen ist; und Adobe kommt nicht aus dem Arsch, um einen Fix bereitzustellen. Öhm, und was ist jetzt mit dem Fehler in der glibc? Die Entwickler meinen, dass Verhalten der Funktion ist ok und bedarf keiner Änderung. Linus Torvalds, der von dem Fehler eben auch betroffen ist, hat aber einige Argumente aufgezählt, warum es eben nicht ok ist (Stichwort: prefetch-Logik einer CPU). Es ist nicht das erste Mal, dass die glibc-Entwickler eine gewisse Sturheit an den Tag legen und sinnvolle Argumente vom Tisch wischen. Bis dato bleiben die Änderungen bestehen.

In einem Post, der in der weiter fortgeschrittenen Diskussion (in dem bug-report) auftaucht, macht ein Kommentator einen weiteren, imo schwerwiegenden Aspekt deutlich. Wenn das Verhalten vom memcpy zu falschen Speicherzugriffen führt und vielleicht auch Speicherbereiche überschreibt, ist das ein Sicherheitsproblem. Da die glibc auch noch ein elementarer Bestandteil jedes Std-Linux-Systems ist, kann das auch als schwerwiegendes Problem bezeichnet werden, denn falls ein Malware-Schreiber einen Weg finden sollte, wie dieses Problem für ihn nutzbar ist, dann sind da recht schnell alle Distributionen betroffen, sprich die Wirkung wäre verheerend.

update: ich war gerade fertig mit schreiben und hab auf der glibc-Mailingliste nachgesehen, ob es nicht vielleicht Neuigkeiten in der Angelegenheit gibt. Entgegen meiner Befürchtung, dass nichts zu finden ist, war tatsächlich ein neuer Patch da, der zumindest einen der vorgeschlagenen workarounds implementiert und sicheres Verhalten bewirkt.

Ein feiner Winter

Gimpel
Mal von den ganzen Widrigkeiten (Probleme der Bahn, der Flieger, gefährliche Straßen….) der letzten Wochen abgesehen, finde ich den Winter schön. Wenn man sich mal daran gewöhnt hat, ist es auch nicht mehr bäh. Bei den Schneemengen und den Temperaturen haben allerdings die tierischen Freunde zu kämpfen. Um es denen etwas leichter zu machen, gibts es vor der Wohnung ein Vogelhaus. Und das ist in der letzten Zeit stark frequentiert. Neben Gimpel und Kleiber lassen sich auch Eichelhäher hier blicken und versuchen an das Futter zu kommen. Allerdings müssen sie sich vor den Katzen in Acht nehmen.

Veröffentlicht unter foobar | Verschlagwortet mit

Doch nicht alles schlecht in DE?

In den Kommentaren zu einem Artikel bei heise, der sich mit dem „Verbiegen“ von DNS-Antworten durch den eigenen Provider befasst, schildert ein Leser die aktuelle Situation in Kanada. Da gibts nur zwei große Provider, die sich den Markt mehr oder weniger teilen (mit allen negativen Konsequenzen). Da wird (zumindest bei einem der Beiden) ohne Bedenken eine Anfrage nach www.tagesschau.de auf einen eigenen Server umgeleitet. Pfui deibel, fällt mir da nur ein. Die Details zu weiteren Schandtaten werden noch finsterer.