Backdoor in OpenBSD?

Athaba

Libellenliebhaber
Hallo,

zunächst mal: Don't Panic! ;)

Wie ich gerade gelesen habe hat Theo de Raadt hat scheinbar eine E-Mail bekommen in der behauptet wird, dass das FBI vor zehn Jahren eine Reihe von Open-Source-Entwicklern Geld gezahlt haben, um Backdoors in OpenBSDs IPSEC einzubauen.

Das _könnte_ sehr brisant sein, aber derzeit braucht es vor allem Nachforschungen.

Zusammenfassung auf OSNews:
http://www.osnews.com/story/24136/_quot_FBI_Added_Secret_Backdoors_to_OpenBSD_IPSEC_quot_

Theos E-Mail:
http://article.gmane.org/gmane.os.openbsd.tech/22557
 
Zuletzt bearbeitet:
Wenn sich das bewahrheiten sollte, dann können die anderen Systeme (FreeBSD, Linux, etc.) schonmal auf die Suche gehen, denke ich.
 
Wenn sich das bewahrheiten sollte, dann können die anderen Systeme (FreeBSD, Linux, etc.) schonmal auf die Suche gehen, denke ich.

Warum nur die anderen? Am wichtigsten wäre doch die Suche im OpenBSD-Code... Wenn sich da was findet, kann man leichter ähnliche Stellen bei anderen Systemen finden.
 
Wenn das wirklich zutreffen sollte, ist das mal wieder Futter für Closed-Source-Anbieter, als Beispiel, dass OpenSource überhaupt nicht vor so etwas schützt, da sich niemand den Code wirklich ansieht und einfach vertraut "es ist OpenSource, also ist es sicher und Backdoor-frei, da ihn sich ja jeder angucken >kann<"
 
*gaehn*
ich hab mal gerade einen blick auf den ipsec-code geworfen.

der ist sauber, gradlining und einfach nur schoen.
openbsd ruehmt sich damit dass der code regelmaessig geauditet wird, das glaube ich denen.

ich bin mir ZIEMLICH sicher dass wenn irgendwann mal bei der entwicklung von ipsec irgendjemand mal einen tcp dump hat mitlaufen lassen. waere da ein paket an fbi.gov mit dabei gewesen haette er/sie das bestimmt ganz schnell gemerkt.
 
wenn da was ist, dann wird es nicht so was einfaches wie ein paket an fbi.gov sein. eventuell etwas, das bei den bisherigen audits nicht aufgefallen ist. ursprünglich hatten sie ja genug bezahlte leute im audit, die das abnicken konnten. mal sehen ob da was neues rauskommt.
 
ich bin mir ZIEMLICH sicher dass wenn irgendwann mal bei der entwicklung von ipsec irgendjemand mal einen tcp dump hat mitlaufen lassen. waere da ein paket an fbi.gov mit dabei gewesen haette er/sie das bestimmt ganz schnell gemerkt.
Nja, es geht um "side channel key leaking mechanisms". Sprich: wenn das FBI die Pakete snifft hat es irgendwann genug Infos, um den Key aus den Verbindungsdaten zu extrahieren. Wenn sowas gut genug implementiert ist, dann ist es verdammt schwer zu entdecken.
Dazu kommt, dass die Auditer, die wirklich Ahnung von der Materie haben auch nicht unbegrenzt Zeit haben.
Wie üblich: alles muss man selbst machen.
 
1. Es ist überhaupt nicht klar, ob die Warnung überhaupt korrekt ist - das ist ja auch einer der Gründe, warum Theo trotz eigener Bedenken eine private Email veröffentlicht.

2. Wenn es wahr ist, dass vor 10 Jahren mal eine Backdoor existerte, ist völlig unklar, ob es die nach all den Code-Änderungen durch andere immer noch gibt (ob sie noch ausnutzbar ist).

3. Beim Code-Review muss sowas nicht unbedingt auffallen. Im E-Mail-Thread, der mit Theos Mail begann, hat Damien Miller ja einige mögliche Manipulationen aufgeführt, die denkbar seien. Seine dritte, hält er für die wahrscheinlichste für eine gezielte Backdoor zumal eine solche Manipulation hinter einem üblichen "Fehler" versteckt werden könnte:
3. Arrange for mbufs that previously contained plaintext or other
interesting material to be "accidentally" reused. This seems to me the
most likely avenue, and there have been bugs of this type found before.
It's a pretty common mistake, so it is attractive for deniability, but
it seems difficult to make this a reliable exploit. If I was doing it,
I'd try to make the reuse happen on something like ICMP errors, so I
could send error-inducing probe packets at times I thought were
interesting :)

Insgesamt muss ich sagen, bin ich überhaupt nicht überrascht über eine mögliche Backdoor in einem OS-Projekt, selbst wenn es sich um OpenBSD handelt. Es wurde über die Jahre viel spekuliert (teilweise auch bestätigt) über gezielte Backdoors in kommerzieller Software, neuerdings auch über Hardware-Backdoors (z.B. im Zusammenhang mit Chinesischen IT-Produkten). Warum sollten Sicherheitsbehörden nicht längst auch versucht haben, ähnliche Mechanismen in Freie Software einzuschleusen. Und sowas wie IPSEC und Crypto-Algorithmen kann eben nicht mehr jeder x-beliebige Entwickler überblicken. Insofern ist die Zahl der Augenpaare auf diesen Code-Teilen doch erheblich geringer.

Ich bin sicher, dass sich schnell einige ransetzen werden, die damaligen Code-Beiträge des benannten Committers anzuschauen. Dann werden wir vielleicht bald Klarheit haben, ob es eine Backdoor gab, ob die noch nutzbar ist und inwieweit andere Projekte betroffen sind, die den OpenBSD-Code übernommen haben.
 
Auf jeden Fall sollte man sich der Gefahr bewusst sein. Durch die Lizenz und die Tatsache, dass alle Welt von den BSDs abschreibt bietet tatsächlich einen lohnenden Angriffspunkt, der mit hoher Wahrscheinlichkeit dann in viele Systeme eingeht.

Auch Theo scheint das durchaus ernst zu nehmen, er hat in der mail niemanden beleidigt ;)
 
Mehr Details, also von dem Autor der Mail:

http://blogs.csoonline.com/1296/an_fbi_backdoor_in_openbsd

The OCF was a target for side channel key leaking mechanisms, as well as pf (the stateful inspection packet filter), in addition to the gigabit Ethernet driver stack for the OpenBSD operating system; all of those projects NETSEC donated engineers and equipment for, including the first revision of the OCF hardware acceleration framework based on the HiFN line of crypto accelerators.



The project involved was the GSA Technical Support Center, a circa 1999 joint research and development project between the FBI and the NSA; the technologies we developed were Multi Level Security controls for case collaboration between the NSA and the FBI due to the Posse Commitatus Act, although in reality those controls were only there for show as the intended facility did in fact host both FBI and NSA in the same building.
 
Hoi,

also ich würde ja mal auf ne ganz große Ente tippen. Abgesehen davon kann ich mir kaum vorstellen, dass die ne NDA mit 10 Jahren machen bei so Schweinereien und danach darf er das verzählen - klingt alles sehr unglaubwürdig was da grad abgeht.

*Luft aus Turnschuh ablass*

Gruß Bummibär
 
Stellt sich ja die Frage welchem System man überhaupt noch trauen kann!
Bei closed Source stellt sich die Frage nicht mal, da es hier gar keine Möglichkeit der Kontrolle gibt.

Wunderts einen da noch warum viele Länder Eigenentwicklungen in Sachen Verschlüsselung einsetzen, Algorithmen etc.
Vielleicht ists paranoid, aber wenn man das alles bedenkt - was kann man dann noch einsetzen?

PS: gabs nicht kürzlich einen Gesetzesentwurf in den USA welcher definierte Schnittstellen für Verschlüsselungssoftware vorschreibt? Naja, zumindest wirds ohnehin schon inoffiziell gemacht (Mutmaßung)

PPS: andererseits stellt sich die Frage warum dann mittels Stuxnet Würmern udgl. gearbeitet werden muss um kritische Anlagen zu infiltrieren, falls es wirklich schon Backdoors in den Systemen gäbe. Wohl keinen Zugang zur Backdoor gehabt? ;-) Mann das ist ein spannendes Thema - was wohl so alles im Integrity OS herumschwirrt, oder in Huawai Firmware, oder oder oder? :-D
 
Zuletzt bearbeitet:
... da will mal wieder jemand openbsd und im speziellen theo eins auswischen!

wie lustig das jetzt hier auch ist - generell haben natuerlich die kollegen bundestrojaner und geheimspiogenten ein starkes interesse an solchen moeglichkeiten und mit sicherheit auch schon die eine oder andere beta-applikation im einsatz.

--hawky
 
Die Situation zeigt auf jeden Fall eine Sache ganz deutlich:

Bei Code, der so komplex ist, dass ihn nur wenige Leute verstehen greift das übliche Argument von redundatem Audit durch die Community nicht. Solcher Code braucht speziellen Audit.
 
Allerdings ergibt sich damit (zumindest für alle Verschwörungstheoretiker) wieder ein Problem. Wenn nur wenige Personen solchen Code auditen können, könnte man die ja auch gleich kaufen. :)
 
Andererseits ist es ja gerade bei schwer verständlichem Code ganz gut, wenn jeder der ihn versteht auch überprüfen kann. Es ist wohl auch schwerer jeden zu kaufen, der ihn versteht und betrachten könnte, als es bei einem Closed-Source-Projekt der Fall wäre. Zunächst müsste man sie alle kennen und dann noch ausreichend Geld aufbringen.

In der konkreten Situation, wo eine Behauptung auf dem Tisch steht ist Open Source aber wohl wirklich besser dran.

Hier eine Lücke zu finden kann sich ja ganz gut auf das Image und im Zuge dessen auch auf das Einkommen auswirken. Einer von vielen Gründen an Open Source Software zu arbeiten ist ja zu zeigen, was man kann.

Ich frage mich wie so etwas im bei Closed Source gehandhabt werden würde. Würde man nach Spezialisten suchen, die sich damit auskennen und diese versuchen anzuwerben? Stelle mir das nicht allzu leicht vor. Die werden ja wohl ohnehin einen gut bezahlten Job haben.
 
Allerdings ergibt sich damit (zumindest für alle Verschwörungstheoretiker) wieder ein Problem. Wenn nur wenige Personen solchen Code auditen können, könnte man die ja auch gleich kaufen. :)

Da ergeben sich mehrerererere Probleme. Einmal das von dir Angesprochene. Dann, dass es sich um Spezialisten handelt, die genug Einfluss haben, um sich für Kreativität statt für den Ar***kartenjob zu entscheiden.

Und nicht vergessen die Gretchenfrage: Ist OSS hier wirklich sicherer, als CSS?
Der Vorsprung, dass jeder den Code einsehen kann fällt definitiv weg, wenn ihn niemand verstehen kann. Prüfen hier wirklich mehr _wohlgesonnene_ Augen den Code, als bei CSS?
Glücklicher Weise ist Verschlüsselung nur mit der Möglichkeit zur Falsifikation überzeugend, wodurch der Code schon offenliegen sollte...
 
*gaehn*
ich hab mal gerade einen blick auf den ipsec-code geworfen.

der ist sauber, gradlining und einfach nur schoen.

Puh, dann kann ich jetzt wieder ruhig schlafen. ;)

Ohne dir zu nahe treten zu wollen, ich glaube nicht, dass jemand aus dem Forum beurteilen kann, ob Backdoors im IPSEC-Code sind oder nicht. :)
 
Puh, dann kann ich jetzt wieder ruhig schlafen. ;)

Ohne dir zu nahe treten zu wollen, ich glaube nicht, dass jemand aus dem Forum beurteilen kann, ob Backdoors im IPSEC-Code sind oder nicht. :)

Ich kann mich selbst beurteilen, sprich ich kann es nicht. Aber andere in diesem Forum? Woran machst du das fest? Haben Zeitgenossen die Foren frequentieren einen niedrigeren IQ als andere?
 
Allerdings ergibt sich damit (zumindest für alle Verschwörungstheoretiker) wieder ein Problem. Wenn nur wenige Personen solchen Code auditen können, könnte man die ja auch gleich kaufen. :)
Wenn man das zuende denkt, dann kann man nur Garantie für ein OS übernehmen, das man vollständig selbst geschrieben hat. Und auch da kann man nur garantieren, dass keine gekauften/bezahlten Backdoors enthalten sind ... nicht, dass überhaupt keine Backdoors enthalten sind. :)

Ab einem Zwei-Mann-Projekt gibt es mindestens eine unkalkulierbare personelle Schwachstelle - den anderen.
 
Zurück
Oben