Backdoor in OpenBSD?

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.

Das ist mir zu Schwarzweiss. Ohne dich angreifen zu wollen - Marketingsprüche.
Sicherheit ist nicht etwas, was man hat, oder nicht hat.
Es gilt Risiken zu minimieren. Garantien abgeben kann niemand.
 
Naja, ich kann für mich selbst garantieren, dass ich nicht gekauft bin. Bei allen anderen muss man im Notfall davon ausgehen, dass sie käuflich sind und muss dann halt mit Audits nachlegen. Das Risiko lässt sich sicher minimieren, aber wie im Thread schon angesprochen ... solche Backdoors sind sicher nichts, was einem ad hoc ins Auge springt.

Dein Punkt ist mir aber schon klar.
 
Es stellt sich die unangenehme Frage, ob bei solchem Code nicht ein Audit der Persönlichkeit sinnvoll wäre... :-(
Für mich persönlich ist die Antwort "ausgeschlossen, sowas darf nicht sein."
 
Natürlich fallen von Personen eingeschleuste Sicherheitslücken grundsätzlich auf die Persönlichkeit zurück. Aber schlussendlich kommt das Sprichtwort "jeder ist käuflich, es ist lediglich eine Frage des Preises" nicht von ungefähr.

Das ist natürlich nichts, was man bzgl. der Leute, denen man vertraut, hören möchte ....

Je größer ein Projekt wird, desto mehr potentielle personelle Schwachstellen gibt es. Und natürlich gibt es auch bestimmte Projekte/Programme, in denen Backdoors sinnvoller sind, als in anderen (wie z.B. OpenSSH, das hier essentiell sein dürfte).
 
Für Dich nicht oder allgemein nicht?

Ich bin ein extrem misstrauischer alter Strassenköter. Ich glaub das merkt man auch hier im Thread. Ich stelle sofort in Frage, ob OSS in so einem Fall wirklich CSS überlegen ist usw.
Ich glaube aber, dass es sehr viele sehr gute Leute gibt, die nicht bestechlich sind. Das gilt insbesondere dann, wenn es um ihre Hobbys, um ihre Interessen und ihre Freizeit geht. Und auch das ist bei mir ne logische Schlussfolgerung. Das was einem Spass macht, was einem wichtig ist, das verteidigt man. Wenn sich jemandem im OSS-Bereich also zu ner Backdoor bestechen lässt, ist er in meinen Augen nicht nur ein Ar***loch, sondern ein kompletter Vollidiot, der gegen seine eigenen Interessen handelt. Warum sollte er das tun?

Bestechen kann man jemanden nur dann effektiv, wenn er eine Schwelle, oder eine Angst überwinden muss, sich ansonsten aber mit dem Vergehen arrangieren kann.

EDIT:
Ein Beispiel. Eine fiktive Situation ein Streit zwischen einer Regierung und ihrer Bevölkerung eskaliert, es kommt zu Grossdemonstrationen mit illegalen Handlungen. Die Leute sind so sauer, dass sie Sanktionen und Strafen auf sich nehmen. Die Regierung entschliesst sich einen Maulwurf einzuschleusen, der einen ihrer eigenen Leute erschiessen soll, damit sie einen Grund zur Waffengewalt haben.
Wen würden Sie versuchen zu bestechen: Einen der Aktivisten, der mit vollem Einsatz bereits eine Menge riskiert, oder einen jungen Mann, der von der Szene her zu den Demonstranten passt, aber daheim geblieben ist?
"Du bekommst die Baccardiinsel, nen neuen Pass und Straffreiheit"
 
Zuletzt bearbeitet:
Weder noch.
Sie würden wahrscheinlich alle Infrage Kommenden durchleuchten, und mit Sicherheit bei dem einem oder anderen eine Schwachstelle finden, mit der er sich erpressen läßt. Materiell versüßen kann man es ja extra noch. Ohne "Druckmöglichkeit" dürfte das Risiko, dass derjenige nur zum Schein drauf eingeht, zu groß sein.
Von der Stasi lernen......
Es ist kaum anzunehmen, daß "westliche" Geheimdienste (und das FBI würde ich in diesem Fall als solchen betrachten) moralisch sauberer sind als die Stasi es war.
 
Weder noch.
Sie würden wahrscheinlich alle Infrage Kommenden durchleuchten, und mit Sicherheit bei dem einem oder anderen eine Schwachstelle finden, mit der er sich erpressen läßt. Materiell versüßen kann man es ja extra noch. Ohne "Druckmöglichkeit" dürfte das Risiko, dass derjenige nur zum Schein drauf eingeht, zu groß sein.

Und auch der Druck könnte die falsche Person zerbrechen lassen.

Von der Stasi lernen......
Es ist kaum anzunehmen, daß "westliche" Geheimdienste (und das FBI würde ich in diesem Fall als solchen betrachten) moralisch sauberer sind als die Stasi es war.

Ja. in der Realität haben sie den richtigen Mann scharweinlich schon seit 15 Jahren in Lohn und Brot und geben ihm einfach seinen Einsatzbefehl.
Aber mir geht es um die Bestechlichkeit. Ich glaube nicht, dass Jeder bestechlich ist. Im Gegentum - das wozu er bestochen werden soll - das darf er nicht als so schlimm ansehen. Da muss Rechtsbewusstsein fehlen.
 
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?

Das natürlich nicht, aber die Anzahl der BSD-Entwickler hier im Forum ist doch eher gering, die sind auf den Mailinglisten zu finden. :)
 
Naja es wäre doch wohl ziemlich naiv anzunehmen das die Dienste nicht versuchen Backdoors in Software einzubauen. Und OpenBSD bietet sich da doch geradezu an.

Und obs nun in diesem einen Fall stimmt oder nicht ist doch bei dieser Betrachtungsweise eher zweitrangig.

Zu denken das der OpenBSD Code vor derartigen Bestrebungen sicher ist wäre ja nun der Gipfel der Blauäugigkeit. Es gibt immer einen grösseren Fisch.
 
Hallo,

zuerst finde ich das gut das Theo de Raadt das bekannt gemacht hat, er geht das somit offensiv an und hat E..r in der Hose. Dann zudem ist es auch eine Frage vielleicht die entscheidende in diesem Kontext das man sich nie zu einem Werkzeug staatlicher Einflussnahme als freier Open Source Entwickler machen sollte denn damit gibt man seine Unabhängigkeit ab!

Dann, ist man einmal diesen Weg gegangen das man sich hat einspannen lassen wird man erst recht erpressbar.

Geld ist nicht alles
 
moin,

also wenn es denn mal ein backdoor von vor 10 jahren gab ( wird
wohl obsd 3.0 oder so gewesen sein ) dann ist davon nix mehr uebrig oder funktional
da sich zuviel drum herum und am ipsec stack veraendert hat.


von daher heisse luft und ggf das projekt in ein schlechtes licht stellen.

holger
 
>dann ist davon nix mehr uebrig oder funktional
da sich zuviel drum herum und am ipsec stack veraendert hat.

In der Praxis gibt es Code, der nicht unbedingt fortwährend geändert werden muß. Auch muß man nicht eine Routine vermuten, die lustig Daten gen FBI sendet, sonder beabsichtigte Bugs, die einen Bruch nach sich ziehen. Macht man dies an diversen Stellen, dann ist es relativ unauffällig.

Aber insgesamt sehe ich es auch eher so wie Bruce Schneier:

I doubt this is true. One, it's a very risky thing to do. And two, there are more than enough exploitable security vulnerabilities in a piece of code that large. Finding and exploiting them is a much better strategy than planting them. But maybe someone at the FBI is that dumb.

http://www.schneier.com/blog/archives/2010/12/did_the_fbi_pla.html
 
@ olhe

man sollte allerdings nie den fehler machen der unterschätzung, mal am rande da ich ein freund von wettbewerben bin >

# http://notanumber.net/archives/54/underhanded-c-the-leaky-redaction

also wenn man es drauf anlegt das nötige potenzial dazu in der birne hat, so wie der gewinner dieses wettbewerbs aus dem jahre 2008 der so gut war das selbst die veranstalter größte probleme hatten das zu replizieren ;-)

auch bruce schneier macht hier doch einen denkfehler nach meinen dafürhalten und unterschätzt, denke der theo de raadt macht diesen fehler nicht was ich ihm sehr hoch anrechne!

also auditen was das zeug hält wenn man das nötige wissen hat und dem projekt helfen von dem soviel profitieren das sollte man theo de raadt und seinen jungs/mädels doch schuldig sein!

die opensource gemeinde ist hier gefordert, nun etwas zurück zu geben...

mfg rudy

update > und das macht sie auch > meldung von gestern

# http://www.linuxtoday.com/security/2010121701435NWBD
 
Zuletzt bearbeitet:
Noch kurz zur Fähigkeit von Forenteilnehmern den IPSec Stack zu auditieren: geht meines Erachtens nur zum Teil, da nicht jeder n gelernter Kryptograph ist und die Zusammenhänge eines Verschlüsselungsalghoritmus komplett versteht.

Wenn da ne Kleinigkeit im Code für Zufallszahlen oä. steckt, wird das wohl recht schwer nachzuvollziehen sein?

Oder aber ich stelle mir das viiiieeeel zu kompliziert vor. :ugly:

Aber was bleibt? Irgendjemandem oder etwas muss man einfach vertrauen, sonst kann man gleich alles runterfahren...
 
Ich nehme nicht an, dass Implementierungen von Kryptoalgorithmen und Zufallszahlen Teil der IPsec-Implementierung sind. Wozu das Rad neu erfinden? Für IPsec braucht man AES und 3DES, die man ja wohl in jedem System hat.

Für's Implementieren muss man auch nicht zwingend ein Meister der Kryptographie sein. Kommt aber auch darauf an, um was es sich handelt. Ein schönes Beispiel ist der Vergleich von symmetrischer und asymmetrischer Kryptographie. Letztere ist meist einfacher zu verstehen und zu implementieren.

Um IPsec korrekt und sicher zu implementieren muss man schon Ahnung von seinem Fach haben. Vor allem, wenn man fiesen Backdoors auf die Schliche kommen will. rudy hat ja mit seinem Link ein nettes Beispiel gebracht und bei IPsec ist das wohl ein Kräfte messen von Giganten.

Ich kenne jemanden, der jemanden kennt, der bei IPsec (dem Protokoll, nicht bei der Implementierung) mitentwickelt hat. Angeblich hat der so wenig Vertrauen in das Protokoll, dass er in seiner Firma verboten hat es für wichtige Dinge zu nutzen. Vielleicht wäre es also ohnehin besser auf andere Protokolle zu vertrauen.

Bin aber weder ein Kryptograph und ein grauenhafter Programmierer, also alles als gefährliches Halbwissen betrachten.
 
Zuletzt bearbeitet:
@ worel,

deshalb schrieb ich ja wenn man das nötige wissen hat also denke schon das hier im forum einige sind die dazu durchaus in der lage sind....

think positive.. :D

dann, da lesen auch jede menge gäste mit, ist hier ja kein geschlossener zirkel sondern ein öffentliches forum...

stelle auch mal frech wie ich nun einmal bin, einfach die behauptung auf das es dann überwiegend leser sind die sich für technik interessieren und bestrimmt auch ne menge entwickler...

wenn du zum beispiel auf online benutzer klickst und dir anschaust was gäste so alles lesen fühle ich mich da doch bestätigt in der aussage...

dann möchte ich noch anfügen das die opensource gemeinde sehr groß ist, angefangen bei betriebssystemen, wie zum beispiel haiku und vielen anderen, bis hin zu software projekten, aber auch projekte wie wikipedia etc.pp also ein mächtiges potential und geballte wisssenspower...

auch wird oftmals vergessen das es bei opensource große informationspools gibt und auch firmen die im opensourcebereich tätig sind und davon partizipieren geben gerne wissen weiter....

ein beispiel wäre hier ibm siehe angehängtes pdf-dokument in dem es um code audit geht...

sehr lesenswertes dokument das auch wenn man nicht der fachmann ist doch einblicke ermöglicht..

mfg rudy
 

Anhänge

  • RAW14201USEN.PDF
    651,7 KB · Aufrufe: 451
Zuletzt bearbeitet:
deshalb schrieb ich ja wenn man das nötige wissen hat also denke schon das hier im forum einige sind die dazu durchaus in der lage sind....
Du kannst das als Einzelperson eh vergessen.
Du brauchst 1. enorme Ahnung in der verwendeten Entwicklungssprache und 2. enorme Ahnung in Kryptographie.
Beides zusammen haben nur eine Hand von Menschen auf diesem Planeten und es ist auch nicht so, als würde eine "Backdoor" im Code mit

Code:
/* Secret backdoor - do not read as it's secret */

beginnen. Teilweise ist es einfacher in fertigen binaries Lücken zu finden, als im Code selbst...

Im übrigen ist es auch wurscht, ob diese Lücke in den 10 Jahren durch Code-Änderungen zerstört wurde... Es scheint so, als würden Leute explizit angeworben um Sicherheitsprobleme in offenen Code einzuschleusen... Dh eigentlich darfst Du keinem commit mehr trauen...
 
Im übrigen ist es auch wurscht, ob diese Lücke in den 10 Jahren durch Code-Änderungen zerstört wurde... Es scheint so, als würden Leute explizit angeworben um Sicherheitsprobleme in offenen Code einzuschleusen... Dh eigentlich darfst Du keinem commit mehr trauen...

Nein, das ist falsch, da dieser Verdacht keine Möglichkeit zur Falsifikation bieten kann, was auf sämtliche Sicherheitsbereiche zutrifft. Software ist bis zur _Verifikation_ eines Problems nutzbar.
Der Verdacht eines Problems erzwingt nur die genaue Beobachtung.
 
Was mich jetzt natürlich schon weiterführend interessieren würde, ist die Aussage, dass IPSec für kritische Anwendungen nicht verwendet werden darf - Aussage des "Freundes vom Freund". :D
Vielleicht gibts ja da mal ein bisl Einblick. (bezieht er sich da auf IKEv1 oder auch auf IKEv2?)
Alternative? OpenVPN?

Mist, wir setzen zur Kommunikation mit den Kundennetzen seit jeher IPSec über die jeweiligen Appliances ein (was mich ohnehin stört, weil dort nur 3DES oder AES zur Auswahl stehen - Amiprodukt - bäh)
Naja, ganz früher warns mal PPTP Tunnel...

:)
 
Zuletzt bearbeitet:
Ist schon eine Weile her das Gespräch. Wenn ich mich recht erinnere ging es um IKEv2. Ich muss bei Gelegenheit mal nach dem Namen fragen, dann kann ich nachschauen wo der überall mitgearbeitet hat. Es handelte sich jedenfalls um den Chef des Freundes.

Ich bin mir ja auch nicht sicher wie ernst man das nehmen soll. Es gibt ja beispielsweise auch eine Reihe von Leuten, die sich auskennen und AES kritisieren.[1] In der Praxis kann man trotzdem davon ausgehen, dass es für die meisten Anwendungen gut genug ist.

Ob OpenVPN eine Option ist habe ich natürlich auch als erstes gefragt und das ist es, was sie in dem Unternehmen verwenden. Da hast du auch standardmäßig Blowfish und eine größere Auswahl, wenn du kein AES magst. Ich find's nur schade, dass openssl und damit die meisten Projekte keinen Support für Twofish, Serpent oder auch XXTEA hat, wohl aber für CAMELLIA oder SEED, welche ja deutlich unbekannter sind.

Hier geht es aber weniger um Kryptoalgorithmen, sondern um IPsec bzw. dessen Implementierung. Klar kann es sein, dass man sich da etwas zu nutze gemacht hat und man braucht dafür dementsprechendes Wissen, aber es befindet sich dann trotzdem in der Implementierung von IPsec, welche im Code getrennt von den Algorithmen für Kryptographie, Zufallszahlen, etc. existiert.

[1] http://www.cryptosystem.net/aes/
 
Zurück
Oben