Re: Technomagie ... oder so
Verfasst: 3. November 2010, 19:07
So dann machen wir mal weiter ....
Bei übernahme in den Guide werde ich allerdings deinen Namen einschwärzen.
Übrigens danke Bwana für deine Anmerkungen und Kommentare zu den jeweiligen ähhhm ZaubersprüchenMail-Bombe
Eine Mail-Bombe ist eine Zip-Bombe (s. o.) als Anhang einer E-Mail.
Schlampig programmierte Virenscanner, die beim Scannen von E-Mails komprimierte Dateien ohne
Überprüfungen und Limitierungen ganz gnadenlos entpacken, können damit zum Absturz oder
Hängenbleiben gebracht werden oder den verfügbaren Platz auf Festplatte und vielleicht auch im
RAM komplett belegen. Solche unlimitierten Aktionen sind typische Anfänger-Fehler beim
Programmieren, die man am (C-)Sourcode daran erkennt, das fget, malloc, strcat, strcpy, sprintf,
strcmp, strdup, strlen oder vprintf verwendet werden, denn die sicheren äquivalenten Funktionen
sind fgets, calloc, strncat, strncpy, strnprintf, strncmp, strndup, strnlen und vsnprintf.
Zum Auffinden der genannten unsicheren Funktionen gibt es Programme wie Flawfinder.
Genauer und auch für andere Programmiersprachen beschrieben findet man dies unter der Rubrik
Secure Coding bei CERT: http://www.cert.org/secure-coding/.
Siehe auch SPSA: The Secure Programming Skills Assessment und 24C3-Vortrag: Grundlagen der
sicheren Programmierung sowie der kurze Artikel vom April 2010 Die Woche: Die Sünden der
Programmierer.
Für zuverlässige Programme ist zusätzlich fachmännische Programmierung erforderlich. Hierzu
gehört beispielsweise Rückgabewerte zumindest generell und meistens auszuwerten und Daten aus
gepufferten Schnittstellen wie der seriellen Schnittstelle mit select und nicht mit read einzulesen
sowie Schnittstellen wie die serielle nur exklusiv zu öffnen um auszuschließen, das mehrere
Programme sie gleichzeitig verwenden und sich gegenseitig Daten überschreiben/wegnehmen:
...
if (-1 == ioctl (fd, TIOCEXCL, &modelines)) // Put the tty into exclusive mode. Schnittstelle
exklusiv öffnen.
{
(void)fprintf (stderr, "ERROR at ioctl TIOCEXCL on port %s, exiting! Schnittstelle %s konnte
nicht exklusiv geöffnet werden; Exitus!\n", a_device, a_device);
perror ("ioctl()");
return (-1);
}
...
Siehe auch: Die 25 gefährlichsten Programmierfehler, Stand Januar 2009.
Die wichtigsten Vorgaben sicherer Programmierung sind - unabhängig von der
Programmiersprache - folgende fünf Punkte:
1. Prüfung von Ein- und Ausgaben (inkl. Rückgabewerten)
2. Authentisierung und Zugriffskontrollen
3. korrektes Handhaben und Schutz von sensitiven Informationen und Daten
4. Befolgen des "Least Privilege"-Prinzips, das die tiefstmöglichen Privilegien vergibt
5. Verhindern von Informationspreisgaben (Geheimnisprinzip/Datenkapselung)
Bei vielen Programmen ist dies aber ignoriert worden, so das beispielsweise ntpd und apcupsd
problemlos die gleiche serielle Schnittstelle öffnen können und sich damit gegenseitig die Daten
überschreiben und kryptische Fehlermeldungen produzieren.
Neben solchen Anfänger- und Flüchtigkeits-Fehlern beliebt sind auch Fehler schon in der
Spezifikation bzw. das Fehlen der Spezifikation sowie falsche Vereinfachungen wie das eine
Minute 60 Sekunden hat (Weglassen der Schaltsekunden), das ein Jahr 365 Tage hat (Weglassen
des 29. Februar und der Schaltjahre generell; ein Beispiel ist Zune am 366. Tag des Jahres 2008)
und auch das falsche Berechnen von Schaltjahren.
Ähnliche Klassiker sind das Jahr-2000-Problem und das Jahr-2010-Problem.
Solche Fehler finden sich in sehr vielen Programmen und sind die Ursachen, weshalb Hersteller wie
Apple und Microsoft regelmäßig als Updates bezeichnete Bugfixes veröffentlichen. Allerdings sind
solche Fehler nicht selten beabsichtigt um beispielsweise a) in den Nachrichten präsent zu sein
(kostenlose Werbung, "All Publicity Is Good Publicity") und b) um die Kunden zum Kauf einer
neueren Version zu animieren. Ein Beispiel ist Excel von Microsoft: Von Anfang an verwendete es
eine falsche Berechnung der Schaltjahre und Mitte der 1990er Jahre machte es mehrmals durch
mehrere grobe Fehler von sich Reden: http://www.heise.de/newsticker/Excel-Bugs-nehmen-kein-
Ende--/meldung/2407 . Wie sich 10 Jahre später zeigt sind nicht nur immer noch reichlich Fehler
enthalten ( http://www.spiegel.de/netzwelt/web/0,15 ... 37,00.html ) sondern es werden auch
mit Updates gelegentlich neue Fehler eingebaut, wohl damit sich die Benutzer nicht an fehlerfreie
Software gewöhnen:
http://www.pctipp.ch/news/sicherheit/42 ... h_day.html.
Im Gegensatz dazu haben sich andere Hersteller weniger Mühe beim Einbauen von Fehlern
gegeben; beispielsweise zeigt Googles kostenlose, webbasierte Tabellenkalkulation Google
Spreadsheets keinen der Fehler von Microsoft Excel, wie man in dem oben genannten Artikel vom
Spiegel nachlesen kann.
Das Problem unsicherer Programmierung betrifft paradoxerweise auch Sicherheits-Software wie
Virenscanner und Firewalls, zumindest wenn sie closed-source sind und daher die Nutzer den meist
mieserablen Sourcecode nicht einsehen können:
http://www.businessweek.com/technology/ ... _tc024.htm.
Und dieses Thema ist ein Dauerbrenner; auch Ende 2008 ist es noch aktuell:
http://www.heise.de/newsticker/Schwachs ... ung/120826.
Hinzu kommt, das viele Sicherheitslücken ungepatcht bleiben, auch um so einen Zwang zum
Kaufen von neuer Software zu schaffen: http://www.heise.de/security/Studie-Viele-
Sicherheitsluecken-bleiben-ungepatcht--/news/meldung/126785.
Und es ist nicht anzunehmen, das sich dies ändern wird, denn Sicherheitsprodukte bestehen schon
seit Ende der 80er Jahre eine Zertifizierung im ersten Anlauf in 96 % aller Fälle nicht und in den
meisten Fällen entspricht nicht einmal die Kernfunktion des Produkts den gewünschten
Anforderungen: http://www.heise.de/security/meldung/Nu ... -bestehen-
Zertifizierung-im-ersten-Anlauf-861036.html.
Da gelten halt Grundsätze wie "Wer testet oder auch nur überprüft ist feige." und
"Testen/Überprüfen kostet Geld und braucht Zeit, aber dafür sind wir zu geizig.". Schließlich gibt
es ja die Bananenstrategie, nach der das Produkt bei Kunden reift, weil der mit unreifer Software als
Tester mißbraucht wird und notgedrungen Fehlermeldungen an den Hersteller schickt um die
Software überhaupt richtig benutzen zu können. Dieser Mißbrauch wird von den betreffenden
Firmen verharmlosend "Service" genannt, ist aber nur ein den Kunden aufgebürdetes Testen oder
nur eine Beruhigung der Kunden ohne eine Auswertung der Fehlermeldungen.
Das lange bekannte Mail-Bomben-Problem mit schlampig programmierten Virenscannern gibt es
immer noch, beispielsweise bei der Web-Mail von web.de (Stand Mitte 2007): Versucht man die
42.zip anzuhängen, bekommt man die Fehlermeldung "Dateiname: 42.zip gefundener Virus: ZIPCrash",
was schlicht falsch ist und zeigt, dass immer noch ein schlampig programmierter
Virenscanner verwendet wird: Die Datei enthält keinerlei Code und kann daher überhaupt keinen
Virus enthalten!
Andere Dateien wie klein.bz2 werden von web.de sogar kommentarlos entfernt, so dass wenn man
nicht extra kontrolliert, das Löschen der Datei überhaupt nicht mitbekommt!
Dies sind schwerwiegende Bugs, denn sie bedeuten, das man über web.de praktisch keine einfach
komprimierten Festplatten-Images verschicken kann (Stand 2007 bis mind. 2009)!
Als Workaround bleibt nur ein Verschlüsseln der Dateien, z. B. von *.img-Dateien, mittels "zip -P
PaSsWoRt -r images *.img", oder in ein Steganogramm packen oder den Mail-Provider zu
wechseln (oder Aufkaufen und diesen Unfug per Dienstanweisung abstellen lassen).
Allerdings gibt es auch DAPs, dümmste anzunehmende Provider, die das Problem auf die Kunden
verlagern, indem sie in ihre AGBs schreiben, das Mail-Bomben unzulässig sind. Ein Beispiel findet
man in §5 der AGBs der ANTACOM Online Services (Stand 2008-05-31):
http://antacom.com/wsp/wagb.htm. Weil dies eine überraschende Vertragsklausel ist, ist sie aber
unwirksam (§ 305c BGB). Hinzu kommt, das ohne die Präzisierung, ab welchen Werten genau eine
Mail auch eine Mail-Bombe ist, diese Vertragsklausel unklar und auch deswegen unwirksam ist.
Bei übernahme in den Guide werde ich allerdings deinen Namen einschwärzen.