Fragen? Antworten! Siehe auch: Alternativlos
Auf der einen Seite ist das natürlich erstmal eine gute Nachricht. Auf der anderen Seite muss man halt immer auch auf das Preisschild gucken. In diesem Fall ist das Preisschild, dass er sich als Ersatz für Chiasmus (proprietärer Geheim-Cipher der deutschen Behörden) an die staatliche Zitze begeben hat, und jetzt existenziell vom Wohlwollen des deutschen Staates abhängig ist. Also genau derer, vor denen uns GnuPG schützen sollte. Die, die gerne Krypto umgehen wollen. Die Backdoors in Endgeräten einbauen wollen, damit sie besser abhören können.
Konkret:
In particular, our now smooth integration into Active Directory makes working with OpenPGP under Windows really nice. We were also able to partner with Rohde & Schwarz Cybersecurity GmbH for a smooth integration of GnuPG VS-Desktop with their smartcard administration system.
Rohde & Schwarz sind Deutschlands bekanntester Geheimdienst-Lieferant, die auch die ganzen IMSI-Catcher gebaut und geliefert haben.Den Kunden noch einen Grund zu geben, nicht von Active Directory wegzumigrieren, würde ich auch als ethisch fragwürdig bezeichnen.
Abgesehen davon trübt der Kontext meinen Blick etwas. Es wird mir immer schwer fallen, positive Aspekte bei GnuPG zu finden, solange Werner Koch das in Geiselhaft hat. Und jetzt, wo er offen mit Geheimdienst-Zulieferern kollaboriert, wird das noch schwieriger.
Update: Einen positiven Aspekt hat das aber auf jeden Fall: Für Unterhaltung ist gesorgt.
A minor drawback is that for a quick start and easy migration from Chiasmus, many sites will use symmetric-only encryption (i.e. based on "gpg -c").
Richtig gelesen! Die verwenden da den symmetrischen Modus! HAHAHAHAHA OMG. Die 1970er haben angerufen! Public Key Krypto ist erfunden worden!
Naja, werdet ihr euch jetzt denken, das ist bestimmt alter Gammelcode. Heute würde sowas in neuem Code nicht mehr passieren.
Doch, würde es. Das ist brandneuer Code.
m(
Diesmal war wirklich GnuPG Schuld.
Also so langsam hab ich echt keinen Bock mehr auf diese ständige Terrorpanikmache bei Securitybugs. Heise besteht ja gefühlt auch nur noch aus Spectre-Geraune. Kommt mal bitte alle wieder runter. Unglaublich.
Das hätte natürlich so nie durch den Primzahlgenerator kommen dürfen. Und in der Tat, wenn man das mal in GMP durch den Miller-Rabin-Test jagt, ist das Ergebnis "keine Primzahl".
#include <gmp.h>Gibt es diesen Key wirklich? Ja, man findet ihn auf den Keyservern. Was zur Hölle ist hier passiert?! Hat der den Key mit einem Hexeditor generiert statt mit gnupg?!
#include <stdio.h>int main() {
mpz_t a;
mpz_init(a);
mpz_set_str(a,"817023023960376946633975507110154649249407598806798730414849884461776172171921668594148071323527016137506405823108520062504849249423700259406905313281403901410082762097159560221463048924336192384026777502177262731045200322200149773127502888545234973139480887644585192600631058962876114156934248895171959246969597637127280010272143593885240940877456234662196130491400738438731832514335353824697930453078426722191105157568392826870043655708008545411143367763836566011740499383456592129662585004880376777597714978023542434421914201119537685489173509942329090631662014650033142642110914360849421856179611226450806562235534802516081595259914768497444702718749402330070488028751073730349460752771915484847399385631524708487646079936572410398967582895983187640798072309362094727654167628620105981459021548290415800096769214437425690934372015628796027498219902441288189398386359846661623243493534897411417685435424010451956954083531228374002591372549525280610594684910812811287436481207089763125424247793044043309737269468709710679872269272855389945385386467765509880648929743498214329578288874987193768439353382305260108425688024147656806932474058888992099083804597481699305852902662863062054067183925164590726103552998367994727700722491707",10);
printf("%d\n",mpz_probab_prime_p(a,10));
}
Update: Bei Hacker News gibt es ein paar Kommentare, die Licht ins Dunkel scheinen.
The factored keypair in question is actually a subkey on HPA's public key. However, it appears that the self signature (which is a signature on the hash of the main public key and the subkey) does not match the hash_check. The issuer of this self signature has the same key_id as HPA's main key, which is why this subkey is listed under HPA's public key.
[…]
EDIT: It's the EXACT SAME subkey self-signature packet as HPA's real subkey self-signature packet! Someone (by malice or mistake) manually added a subkey to HPA's public key and copied the signature from the other subkey directly onto the new subkey.
Und weiter unten jemand anderes:
When I try to import HPA's key from the public key servers, I get an "invalid subkey binding" error and the weak sub key isn't imported. That error means that the sub key isn't properly signed by HPA's master key, so there is no cryptographic proof that this weak sub key actually belongs to HPA. This looks more like a fake sub key that someone tried to pollute the public key servers with, which isn't really an issue because PGP implementations will just ignore it.
Update: Jetzt ist mir in der Aufregung die Formulierung entglitten. Der Modulus ist bei RSA keine Primzahl, sondern das Produkt zweier Primzahlen. Allerdings zweier großer Primzahlen. Herauszufinden, welche zwei Primzahlen das im konkreten Einzelfall sind, ist so schwer, dass das die Sicherheit von RSA darauf beruht.
Wenn man einen Schlüssel generiert, generiert man u.a. diese zwei Primzahlen. Primzahlen generiert man, indem man Zufallszahlen nimmt, und die mit einem probabilistischen Primzahltest prüft, wie z.B. dem Miller-Rabin-Test. Der soll mit an Sicherheit grenzender Wahrscheinlichkeit ausschließen, dass es sich bei den beiden großen Faktoren nicht um eine Primzahl handelt, und der sollte daher fehlschlagen, wenn er einen so kleinen Faktor findet.
Auf einer gewissen Ebene hat er natürlich Recht. Auf der anderen Seite hat Snowden seinen Scheiß halt nicht mit Moxies Scheiß vor der NSA gerettet sondern mit GPG. Und am Ende kommt er dann mit:
GPG isn’t the thing that’s going to take us to ubiquitous end to end encryption, and if it were, it’d be kind of a shame to finally get there with 1990’s cryptography.
Damit wären wir wieder bei den Ansprüchen. GPG hat nicht den Anspruch, universelle Ende-zu-Ende-Verschlüsselung zu machen. GPG ist für Email. Nicht für Webseiten, nicht für Chat (obwohl man es in XMPP verwenden kann), nicht für Telefonieverschlüsselung. Die Kritik ist unwürdig.Ich will da jetzt nicht groß ins Detail gehen, aber so richtig vollständig überzeugend ist auch Moxies Software bisher nicht. Die andere Sache, die sich durchgesetzt hat, ist OTR. Auch das ist nicht von Moxie. Ich finde das nicht angemessen, wenn er sich da so aus dem Fenster lehnt. GPG ist nicht schlecht, weil es alt ist. OTR nicht gut, weil es neue Krypto benutzt. Moxie macht sich das hier viel zu einfach.
Ich will dem mal entgegen halten, dass praktisch alle Linux-Distributionen, die überhaupt Krypto zum Validieren der Paketintegrität einsetzen, dafür GPG benutzen. Das muss man erst mal schaffen, so eine Marktdurchdringung.
It's encouraging to see the GnuPG project benefitting from similar largess. But it also raises the question: how is the money best spent? Matt Green, a professor specializing in cryptography at Johns Hopkins University, said he has looked at the GnuPG source code and found it in such rough shape that he regularly assigns chunks of it to his students for review."At the end I ask how they felt about it and they all basically say: 'God, please I never want to do something like this again,'" Green told Ars.
Soweit würde ich jetzt nicht gehen. Immerhin benutzt Werner Koch seit Jahren size_t für Längen und Offsets. Ich habe schon viel schlimmeren Code gelesen. Ich glaube ja, die Jugend von heute ist verweichlicht. Was sollen die denn erst sagen, wenn sie mal OpenSSL erben und warten sollen eines Tages?Übrigens, einen noch:
Given the ramshackle state of massive GnuPG code base, it's not clear what's the best path forward. A code audit is one possibility, but such reviews typically cost a minimum of $100,000 for complex crypto programs, and it's not unheard of for the price to be double that.
Stimmt. Oder man hat halt Glück und der Fefe macht das kostenlos in seiner Freizeit. Und dann schmeißt Werner Koch Das liegt daran, dass Werner Koch das Problem ist, nicht die Lösung. Werner Koch macht mit dem Code keine Wartung, eher eine Geiselnahme. Denn wer will schon gnupg forken. Wir kriegen ja schon ohne Fork die Leute nicht in signifikanter Größenordnung dazu, das zu benutzen. Das wäre noch übler, wenn es da auch noch Marktfragmentierung gäbe. Deshalb hat noch niemand gnupg geforkt. Nötig gewesen wäre es seit Jahren. Ich persönlich hoffe seit Jahren, dass Werner endlich hinwirft, und dann jemand die Wartung übernehmen kann, der auch ein Interesse daran hat, daraus ein ordentliches Projekt zu machen. Aber das wird ja jetzt nicht mehr stattfinden. Jetzt wo nicht mehr nur sein Ego sondern auch sein Lebensunterhalt direkt davon abhängt, dass er weiterhin Diktator von gnupg bleibt.
Übrigens hat Werner seine BSI-Kohle über die Jahre nicht gekriegt, weil er dafür gearbeitet hätte, sondern weil Leute mit Beziehungen beim BSI Klinken geputzt haben. Diese Leute haben zwar gesehen, dass Werner Koch das Problem ist, aber sie haben sich gedacht, wenn man dem Geld gibt, vielleicht wird das dann besser. Wurde es leider nicht. Ein bisschen Mitleid war glaube ich auch dabei. Und ein bisschen "das ist das eine erwähnenswerte Kryptoprojekt aus Deutschland, das sollte gefördert werden, um ein Signal zu setzen".
Weil mir schon die ersten Twitter-Experten Neid vorwerfen: Ich habe den Aufwand für den Patch geleistet, weil ich vorher eine Finanzierung für meine Zeit klargemacht hatte. Ich brauche keine Spenden, schon gar nicht von Facebook. Das werde ich zu vermeiden wissen, dass Facebook sich mit einer Spende für eines meiner Projekte, die ich dann aus einer Notlage heraus annehmen muss, gutes Karma kauft. Das Geld, das ich bei Kunden für ehrliche Arbeit nehme, ist Bezahlung, keine Spende. Damit finanziere ich zwar meine Open Source Arbeit, aber keiner meiner Kunden kann damit Werbung machen, über mich Open Source finanziert zu haben. Außer der Kunde hat mich explizit für die Entwicklung von Open-Source-Software bezahlt, versteht sich. Das hat es auch mal gegeben.
Ich finde übrigens nach wie vor, am besten wäre es, wenn wir einfach ein bedingungsloses Grundeinkommen hätten. Dann hätten wir das Finanzierungsproblem für Kunst und Open-Source-Softwareentwicklung gelöst und niemand müsste so entwürdigende Winselnummern bringen. Wir hätten aber immer noch das Code-Geiselnahme-Problem. Dafür kenne ich auch keine gute Lösung.
Update: Ich sollte der Sicherheit halber dazu sagen, dass das nicht bloß meine Eintschätzung ist, dass Werner Koch das Problem ist, sondern ziemlich breiter Konsens. Ich habe diverse Mails von anderen Leuten gekriegt, die mit Werner vergeblich zu kooperieren versucht haben. Ich werde die hier aber nicht zitieren. Das sind die Geschichten der jeweiligen Leute, nicht meine. Sollen die sie erzählen. Mir persönlich war das 8 Jahre lang egal. Ich hatte meinen Patch. Mein persönlicher Moment, ab dem ich der Meinung war, dass da jetzt mal was geschehen muss, war als ich auf dem 31C3 Citizen Four sah.
Sorry, aber so läuft das nicht. Richard Stallman hat auch sein Leben der guten Sache gewidmet. Linus Torvalds auch. Was ist mit den OpenBSD-Leuten? Den OpenSSL-Leuten?
Wer sein Produkt kostenlos verteilt, der kann nicht nachher herumheulen, dass sich nicht aus magischen Quellen Geld auf seinem Tisch manifestiert hat. Das muss man vorher durchfinanziert haben, dass man die Entwicklung durchführen kann. Sonst sucht man sich einen Mäzen oder einen Sponsor oder macht Crowdfunding, vielleicht ein Regierungsprojekt. Man kann gucken, ob man eine Gemeinnützigkeit anerkannt kriegt. Ist das mit Aufwand verbunden? Klar! Wer das nicht macht, hat mein Mitleid nicht verdient, sorry.
Ich schreibe auch seit 20 Jahren freie Software. Sieht mich jemand herumheulen, dass ich mir kein Abendbrot leisten kann? Nein. So läuft das nicht.
Werner Koch ist im Übrigen in der ausgesprochen privilegierten Position, dass er sogar mehrfach von der Bundesregierung Förderkohle eingesackt hat. Und dann hat er auch noch ein erfolgreiches Crowdfunding durchgezogen. Was sollen denn bitte die ganzen anderen Leute sagen?! Die, denen die Regierung keine Kohle nachwirft? Die, deren Crowdfunding in der Obskurität verlischt?
Sorry, Werner. Du schläfst in dem Bett, das du dir gebettet hast. Wenn du da jahrzehntelang dein Lebens-Management verkackst, dann stelle dich bitte nicht am Ende hin und winsel herum, dass dir die Welt ein bedingungsloses Grundeinkommen schuldet. Sowas kriegt man nicht durch geduldig Warten.
Ich persönlich bin ein Freund des bedingungslosen Grundeinkommens, unter anderem gerade damit auch Leute wie Werner Koch Software wie gnupg schreiben können, ohne sich Sorgen um ihre Abendbrot machen zu müssen. Aber soweit sind wir noch nicht. Die Realität geht nicht weg, wenn wir sie lange genug leugnen.
Im Übrigen, aber das ist nicht mein Hauptpunkt hier, finde ich die Wartung von gnupg auch keinen Vollzeitjob. Sorry, nein, ist es nicht. Seit wann macht er das jetzt? 20 Jahre? Gelegentlich kommt mal ein Feature dazu, das will ich nicht leugnen. Features, die 90% der gnupg-Benutzer nicht betrifft, sowas wie Smartcards. Aktuell wohl auch elliptische Kurven, das betrifft schon eher jemanden. Aber elliptische Kurven haben die finanziell noch schlechter aufgestellten OpenSSL-Leute ganz ohne murren mal eben nachgerüstet.
Liebe Geeks. Wir haben hier ein strukturelles Problem. Freie Software finanziert sich nicht von selbst. Auf göttliche Intervention warten ist keine Lösung. Sucht euch einen Job, der euch Spaß macht. Am besten nichts, was mit Softwareentwicklung zu tun hat. Sonst habt ihr nämlich abends nach der Arbeit auch keinen Bock mehr auf Softwareentwicklung.
Und dann entwickelt ihr in eurer Freizeit freie Software. Und dann geht ihr in eurem Bett schlafen, unter dem Dach, das ihr euch mit dem anderen Job finanziert habt. So wird ein Schuh draus.
Noch was: Geschenken wirft man keinen Guilt Trip hinterher. Entweder es ist ein Geschenk, dann erwartet man nichts dafür, oder es ist kein Geschenk. Freie Software ist ein Geschenk. Klar darf man sich über Spenden freuen. Aber meckern, wenn sie ausbleiben, darf man nicht.
Update: Oh und einen Punkt möchte ich noch machen. Es wird häufig geheult, dass so viel Open Source Software angeblich in so einem schlechten Zustand ist, angeblich weil die Leute das nicht als Vollzeitjob machen. Das stimmt so nicht. Ich zum Beispiel schreibe Software nicht als Selbstzweck, sondern weil ich was lernen will. Aspekte, bei denen ich nichts lerne, oder die mich nicht interessieren, mache ich dann auch nicht. Die Ausgabe von Fließkommazahlen im printf der dietlibc ist seit Tag 1 kaputt. Dass das nicht gefixt wird, liegt nicht daran, dass ich nen Job habe, der mich ablenkt. Sondern das liegt daran, dass mir andere Sachen wichtiger sind. Das ist eine Frage der Prioritäten, nicht der Ressourcen. Jeder von uns hat genug Freizeit um alles zu schaffen, was er wirklich schaffen will.
Update: Oder aber natürlich man macht das zum Beruf. Gründet eine Firma, die Open Source macht. In einigen Fällen hat das sogar funktioniert. Wenn das gelingt, ist es natürlich der heilige Gral. Aber ich habe zwei Befürchtungen. Erstens ist es nicht mehr das Gleiche, wenn man dafür bezahlt wird. Es macht irgendwann weniger Spaß, wenn es ein Beruf ist und nicht etwas, das man aus freien Stücken tut. Zweitens muss man ja trotzdem irgendwoher Einnahmen generieren. Support für das Produkt ist hier eine populäre Option, aber das kann man nur bringen, wenn das Open-Source-Produkt soweit fertig und stabil ist und eine wichtige Sache löst und breit eingesetzt wird. Das ist eine verschwindende Minderheit der Projekte. Und dann ist die Arbeit, die man tut, auch eher Wartung als Entwicklung. Die Frage also, wie man die Entwicklung von freier Software finanziert kriegt, ist damit weiterhin nicht geklärt.
Als letzte Option bezahlen auch manche große Firmen wie IBM oder Oracle oder Linux-Distributoren ein paar Leute für ihre Arbeit an Open Source-Projekten. Das halte ich für nicht realistisch genug, um das generell als Lebensmodell zu empfehlen. Ein paar Leute können sich das so drehen. Der Rest — fast alle! — nicht.
Update: Es haben sich $50k/Jahr-Sponsoren gefunden. Und genau die Art von Leuten, von denen man Geld annehmen möchte!1!! Na seht ihr, ist doch noch alles gut ausgegangen. Wenn ihr Werner Koch wäret, wäret ihr jetzt zufrieden?
Update: Oh und die Linux Foundation wirft auch nochmal $60k hinterher.
Update: Ich mache mir Sorgen, dass jetzt lauter Kids glauben, das könnte für sie auch funktionieren. Leute, niemand von euch hat den Hauch einer Chance, das als Finanzierungsmodell für das Leben zu replizieren. Das ist wie auf einen Lottogewinn zu hoffen. Holt euch lieber einen richtigen Job und entwickelt nebenher freie Software. Das ist das realistische Modell. Ich finde nach wie vor, dass man Leute, die sich wie Werner ohne Fallschirm aus dem Flugzeug stürzen, nicht auffangen sollte. Sonst validiert man damit das Modell, dass man so seinen Lebensunterhalt verdienen kann. Und dann machen lauter Andere das nach.
Über die Jahre habe ich dann beim Anpassen von meinem diff auf neuere Versionen von gnupg gesehen, dass inzwischen knapp die Hälfte der Bugs in meinem Patch insgeheim upstream gefixt wurden. Es bleiben natürlich immer Restzweifel, aber die Bugs, die relativ sicher zu Problemen hätten führen können, sind in der Zwischenzeit verschwunden. Meine Ansage von damals, dass gnupg ein unsicherer Haufen Mist ist, gilt daher heute nicht mehr. Hintertüren habe ich damals übrigens keine gefunden, das sah alles aus wie ganz normale Schludrigkeit und Inkompetenz. Restzweifel bestehen natürlich immer. Und ich kann natürlich auch was übersehen haben. Insofern: Im Zweifelsfall selber nochmal gucken.
Update: Ich sollte dazu sagen, dass ich von den Sourcen von gnupg selbst rede, und auch nur von der 1.x-Version. Den ganzen Smartcard-Kram und etwaige Frontends habe ich nicht geprüft und habe es auch nicht vor. Und in den verwendeten Libraries können natürlich auch noch Fehler sein. Von "ist sicher" kann ja eh nie die Rede sein, so auch nicht in diesem Fall. Aber ich für schätze für mich das Risiko überschaubar genug ein, von einem Einsatz nicht mehr pauschal abzuraten.
An erster Stelle Julian, der hat dem Guardian die Cables mit gnupg verschlüsselt gegeben, indem er sie auf den öffentlichen wikileaks.org-Server hochlud, unter einem "geheimen" (nicht verlinkten) Pfad. Und dann hat er vergessen, diese Datei wieder zu löschen, als der Guardian sich die gezogen hatte.
Der Schutz dieser Daten bestand a) aus dem Passwort und b) daraus, dass der Pfad "geheim" und nicht verlinkt war.
Später haben dann die Daten die Runde gemacht, weil es auch einen Torrent mit den Daten vom Webserver gab. Und da gehörten eben auch diese verschlüsselten Dateien dazu. Die hießen sowas wie "/xyz/z.gpg".
Wikileaks hatte Regeln für den Umgang mit der Presse. U.a. stand da drin, dass es nicht ein Master-Passwort gibt, sondern eines pro Medienpartner. Dagegen hat Julian in diesem Fall verstoßen.
Die nächste Figur ist David Leigh, ein Guardian-Reporter. Der hat damals von Julian die Daten und die Passphrase gekriegt. David Leigh schreibt daraufhin ein "Enthüllungsbuch" und wählt die Passphrase als Überschrift für das Kapitel 11. Der Kontext in dem Buch zeigt, dass er nicht annahm, dass die Passphrase noch gültig ist bzw noch irgendwas öffnen würde.
Die dritte Figur ist Daniel, der die Passphrase wiedererkannt und dann offenbar Medienpartnern erzählt hat, dass man damit die unredigierten Cables öffnen kann. Auf ihm lastete die Beweislast für seine Ansage, dass Wikileaks ja keinen ordentlichen Quellenschutz garantieren könne. Und die Medien machten ihm Druck deswegen. Wann er da wem was gesagt hat, das kann ich von außen auch nur spekulieren, aber dass der Freitag (Daniels Openleaks-Medienpartner) plötzlich aus blauem Himmel in der Lage ist, da die Puzzlestücke zusammenzusetzen, und diesen katastrophalen Dammbruch-Artikel zu veröffentlichen, das halte ich für keinen Zufall. Dort beschreiben sie, dass es eine Datei im Internet gibt, dass es ein Assange-Passwort im Internet gibt, und dass man mit dem Passwort die Datei entschlüsseln kann. Damit war dann auch dem letzten Idioten klar, dass er nach "wikileaks torrent" und nach "assange password" googeln muss und dann die Passphrase auf alle Dateien im Torrent ausprobieren muss und dann fallen da die Cables raus.
Das Problem ist, dass man da beim Schuldzuweisen Interpretationsspielraum hat, und Stellen, an denen Aussage gegen Aussage steht.
Julian wirft dem Leigh vor, dass er die Passphrase veröffentlicht hat. Der sagt nun, Julian habe ihm damals angesagt, dass die Passphrase nur temporär und danach wertlos sei. In seinem Buch ergibt sich tatsächlich nicht der Eindruck, dass ihm bewusst war, dass die Passphrase noch irgendwas öffnen kann. Aber dass die nur temporär war, schreibt er halt auch nicht explizit. Insofern könnte das eine Schutzbehauptung sein. Ich kenne den Leigh nicht, aber würde da im Zweifelsfall auf Verpeilen tippen, nicht Bösartigkeit. Bei mir hat der jetzt verkackt, weil er eine Passphrase veröffentlicht hat. Sowas tut man niemals nie nicht unter gar keinen Umständen, schon gar nicht wenn die von jemand anderem ist.
Auf der anderen Seite muss Julian im Umgang mit Journalisten soweit Erfahrung haben, dass er davon ausgeht, dass Journalisten im Umgang mit Technik inkompetent sind und für eine gute Schlagzeile auch gerne mal Zusagen ignorieren. Dass er da keine Temp-Passphrase genommen hat, und die Datei auf dem Webserver gelassen hat, das hat er verkackt und kann das auch niemandem sonst anlasten.
Oh übrigens, falls ihr euch gefragt habt, wieso Julian eigentlich überhaupt von Daniel ein Backup der Daten brauchte und nicht selber eines hatte: die Antwort steht in dem Spiegel-Wikileaks-Buch ab Seite 267. Julian flog mit der SAS von Schweden nach Berlin und hatte einen Koffer aufgegeben. In dem Koffer waren seine drei Laptops. Mit den verschlüsselten Daten. Überraschenderweise kam der Koffer nicht an. Also DAMIT konnte ja wohl NIEMAND rechnen!1!!
Wer hat jetzt also Schuld? Daniel? Dem kann man bisher wenig anlasten in der Richtung, zumindest in den Teilen, mit denen er sich tatsächlich zitieren ließ. Meine Vermutung ist ja, dass der von seinen Kumpels beim Freitag gesäckelt wurde, wie denn das jetzt ist mit Wikileaks und dem Quellenschutz, weil Julian ja immer wieder darauf hinwies, dass da ja nie jemand zu Schaden gekommen sei. Und da hat Daniel dann, vermute ich mal, sich mit denen hingesetzt und denen gezeigt, wie man mit dem Passwort aus dem Guardian-Buch und den Dateien aus dem Torrent und gnupg die unredigierten Cables aus dem Hut zaubert.
Ich schätze Daniel übrigens nicht als Marodeur ein. Der wird denen das gesagt haben, damit sie eine Antwort haben, nicht damit sie es publizieren. Aber so ist das halt bei der Presse. Auf "off-the-record" kann man sich da nicht verlassen. Manchen Medien ist da die schnelle Schlagzeile wichtiger als Absprachen oder Menschenleben. Immerhin ist es mir eine Genugtuung, dass der Freitag sich damit auch alle zukünftigen Chancen zerschossen hat, dass ihnen jemals jemand was leaken will. Der Vollständigkeit halber sei erwähnt, dass ich von mehreren Seiten die gegenteilige Einschätzung gehört habe, dass die Fragen so klingen, als habe Daniel sie dem Freitag diktiert und überhaupt sei das eine Agenda von Daniel gewesen, um Wikileaks anzupinkeln. Kann ich nicht beurteilen, ist Hörensagen, im Zweifelsfall für den Angeklagten.
Objektiv liegt die Hauptschuld hier bei der Presse, in Form von Leigh vom Guardian und Krafft vom Freitag, die die wichtigen Details veröffentlicht haben. Das Veröffentlichen einer verschlüsselten Datei ist kein Grund für Kritik, denn dafür ist sie ja verschlüsselt, damit man sie veröffentlichen kann.
Ebenso objektiv liegt die Hauptschuld aber dann doch bei Julian und Daniel. Julian, weil er hätte wissen müssen, wie man Presse handled, weil seine OpSec Scheiße ist, weil er die Datei da hat liegen lassen, und weil er die Passphrase wiederbenutzt hat. Hätte Julian sich an die OpSec-Regeln von Wikileaks gehalten, hätte die Datei für den Guardian eine eigene Passphrase gekriegt, Leigh hätte sie abdrucken können, Daniel hätte sie nicht wiedererkannt, und all die Scheiße jetzt wäre uns erspart geblieben. Daniel, weil er das nicht hätte rausplappern müssen. Dadurch hat er das große Fass erst aufgemacht. Ja, das Fass hatte vorher schon ein Leck. Aber das erteilt ihm keine Absolution.
Man sieht aber ganz gut, wie sich da aus lauter kleineren Fehlern eine Scheiße-Lawine ergab, in denen die Leute die Lage mit Folgefehlern nur schlimmer gemacht haben, aus dem Bedürfnis heraus, ihren Hintern bezüglich der früheren Fehler abzudecken.
Soweit zu meiner Bewertung der Lage. Dementis von Leigh, Krafft, Julian oder Daniel nehme ich unter der bekannten Adresse gerne entgegen :-)
Update: Ich muss mich korrigieren. Ich schrieb, wenn das ein Einmal-Passwort gewesen wäre, dann hätte Leigh das veröffentlichen können. Hätte er natürlich trotzdem nicht, weil ein Geheimdienst, der das mitgeschnitten hat, dann auch die Cables entschlüsseln könnte. Das war so gemeint, dass Daniel dann die Passphrase nicht wiedererkannt hätte. Das wäre immer noch lausige OpSec gewesen, aber der Shitstorm wäre uns erspart geblieben.
assert(len+100 > len);len ist ein int. Hier sind zwei Beispielprogramme: int.c (signed) und unsignedint.c (unsigned). Nicht zu fassen. Das betrifft konkret den gnupg-Patch. FINSTER. Probiert das mal bei euch aus. Ich habe hier amd64 und x86 und kann das mit gcc 4.1.1 bei beiden nachvollziehen. Sehr gruselig. Was jetzt? Ich werde mal einen Bug bei gcc einreichen, aber ich fürchte ja, daß da wieder irgendein Language Lawyer kommt und mir sagt, daß man das formaljuristisch so auslegen kann in C.
Update: Hier ist der Bug, und wie ihr sehen könnt, findet der gcc-Typ, der an dem Problem Schuld ist (das gibt er in dem anderen Code-Stück zu), daß das in Ordnung ist, wenn Leute geownt werden, weil er eine Optimierung formaljuristisch rechtfertigen kann. Krank. Da fragt man sich ja schon, für was man eigentlich Audits macht, wenn man dann so torpediert wird. Oh, übrigens: mit icc (dem Intel-Compiler) kriegt man korrekt eine Assertion.
Update: Der Kracher: das macht so viel Software kaputt, daß die autoconf-Leute darüber nachdenken, -fwrapv zu den Default-Optimierungen zu tun, was das alte Verhalten wieder anschalten. Way to go, GNU! Macht ja nichts, wenn euer Schweinecompiler anderer Leute Software kaputt macht, solange ihr einen Workaround für eure eigene Software habt!1!!
Update 2: Offenbar optimieren auch gewisse gcc 2.95.* und gcc 3 Versionen (3.4.6 auf MirBSD und 3.4.3 auf Dragonfly BSD) diesen Code weg, aber der offizielle Workaround (-fwrapv) existiert nicht bei diesen gcc-Version. Die Antwort des gcc-Typen, der an dem ganzen Problem Schuld ist (Andrew Pinski) ist: gcc 2 und 3 sind nicht mehr supported und im Übrigen "why should we support older GCC when we can barrely support the current ones".
Update 3: Und Florian Weimer hat schon 2002 gesagt, daß das mal passieren würde. (Danke, Sebastian)
Bitte beachtet:
Update: Und schon hat jemand (Fabian Keil, danke!) einen Fuckup gefunden. Neues Diff (Jan 15 17:20) geuploaded.
The man who does not read good books has no advantage over the man who cannot read them.
Klar könnt ihr euch jetzt hinsetzen, denken, der Fefe hat geguckt, der wird da schon alles Wichtige gefunden haben. Aber ihr seid dann genau so weit wie vorher, ihr vertraut immer noch anderer Leute Urteil, und gelernt habt ihr auch nichts dabei. Lernt mal Code lesen, und lest dann auch Code. Das ist der wichtigste Schritt zur Emanzipierung und Aufklärung im Digitalzeitalter. Das wird alles immer nur noch komplizierter! Je länger ihr wartet, desto größer die Hürden.
Was tut man in solchen Fällen? Man spricht den Autor an. Habe ich gemacht. Erst mal als Testballon eine Frage zu seinem ASN.1-Code, den Funktionsnamen ins Subject.
Schreibt er mir zurück, ich müsse schon sagen, wo ich diese Codefragmente genau gefunden hätte. Ich schreib also zurück, äh, Funktionsname == Subject. Gut, übersehen, danke ich mir, kann schon mal vorkommen. Was kommt zurück?
Wenn Du nicht in der Lage bist halbwegs anständige Informationen zu liefern, kann ich Dich wohl kaum unterstützen.Diese komplette Fehleinschätzung der Dinge ist mir bisher nur einmal unter gekommen: bei Jörg Schilling. Leute, wenn ich in eurem Code Bugs finde und euch das mitteile, dann bin ICH der Unterstützende, und zwar unterstütze ich euch. Nicht umgekehrt. Wer da der Illusion erliegt, daß er als Autor mir Support zukommen läßt, der vertreibt seine einzige Chance auf kostenloses Bugfinden, und — er hat es auch nicht anders verdient. Aber wartet, geht noch weiter.
Was glaubst Du wohl, wie oft ich so eine Funktion hier rumfliegen habe.
Ich habe geguckt. Einmal in gnupg 1.4.6 und einmal in gnupg 2.0.1, und zwar der identische Code, cut&paste. Soviel dazu, Werner. Was soll ich sagen, auf solche Spirenzchen habe ich überhaupt gar keinen Bock. Dann kann gnupg halt von mir aus schlecht bleiben. Ich habe mal ein paar Vorträge auf Sicherheitskonferenzen angemeldet, "Auditing GnuPG", da werde ich dann halt die Details erzählen, und demnächst taucht dann hier ein Patch auf, den könnt ihr dann alle haben. Das war jedenfalls mit Sicherheit das letzte Mal, daß ich ihm zu helfen versucht habe.Im Übrigen fände ich das alles nur halb so erbärmlich, wenn Werner nicht öffentliche Förderkohle abgegriffen hätte, um seine Softwareentwicklung zu finanzieren. Damit ist er jetzt bei mir persönlich auf einer Ansehensstufe mit Steuerhinterziehern.
2002-03-12 Werner Koch <wk@gnupg.org&bt;Seit dem gab es da noch andere Probleme, allerdings sieht der Code völlig anders aus in gnupg. Das scheint tatsächlich von zlib 1.1.4 zu sein. GRUSEL!!!Merged changes from zlib 1.1.4.
Das wird offenbar nur reingelinkt, wenn es im System keine zlib gibt. Noch mal Schwein gehabt.
if ( !initialized ) {Ich habe da genau so viel Kontext wie ihr, aber ich würde das so interpretieren, daß Herr Koch hier ein Protokoll mit in-band signalling gebaut hat, und ein Angreifer hier Pakete einfügen kann, und er will das jetzt "reparieren", indem er "Zufallswerte" einfügt, die der Angreifer nicht raten können soll.
volatile ulong aa, bb; /* we really want the uninitialized value */
ulong a, b;initialized = 1;
/* also this marker is guessable it is not easy to use this
* for a faked control packet because an attacker does not
* have enough control about the time the verification does
* take place. Of course, we can add just more random but
* than we need the random generator even for verification
* tasks - which does not make sense. */
a = aa ^ (ulong)getpid();
b = bb ^ (ulong)time(NULL);
memcpy( marker, &a, SIZEOF_UNSIGNED_LONG );
memcpy( marker+SIZEOF_UNSIGNED_LONG, &b, SIZEOF_UNSIGNED_LONG );
}
Also ich könnte euch jetzt erzählen, daß Werte auf dem Stack alles andere als zufällig sind, daß PID und Uhrzeit auch eher gut ratbar sind, aber die eigentliche Nachricht ist: gnupg hat einen "control channel", der in-band signalling benutzt, und auf dem Angreifer Daten einschleusen können. Mehr muss man nicht sagen. Und diesen Müll-Code habe ich seit Jahren eingesetzt! OMFG! Ich glaube nicht, daß das mit einem Patch fixbar ist. Wegschmeißen, neu machen. Im Übrigen schreibt man das "although", nicht "also".
if (*p == '*')Sieht ja an sich OK aus, außer man beschäftigt sich mal mit der Zahlendarstellung in Computern. Im Zweierkomplement gibt es eine negative Zahl (0x80000000 auf 32-bit Systemen), für die es keine Positiv-Darstellung gibt. Wenn man diese Zahl negiert, kommt sie wieder selbst raus. Für abs() bedeutet das:
{
++p;
total_width += abs (va_arg (ap, int));
}
abs(0x80000000) == 0x80000000 == -2147483648Für diesen Code heißt das, daß die offensichtlich unterliegende Annahme falsch ist, daß dieser Code immer nur Zahlen drauf addiert. Insbesondere kann man so den Code dazu kriegen, weniger Platz zu allozieren, als dann am Ende reingeschrieben wird.
Was mich ja besonders irritiert: dieser Code kommt von libiberty, das ist Teil von gcc/binutils/gdb. Das ist noch keinem aufgefallen?
Und als ich gerade dabei war, dachte ich mir, mhh, printf liefert die Anzahl der Zeichen zurück, die er hätte schreiben wollen. Als int. Was, wenn das so groß wird, daß es negativ wird? Sollte printf das abfangen? -1 zurück geben? Mal gucken, was die glibc macht:
#include <stdio.h>Wenn man das Programm aufruft, frißt er ein Gig RAM, läuft 17 Sekunden (auf meinem fetten Athlon 64), und schreibt dann -2147483647.int main() {
printf("%d\n",snprintf(0,0,"%*d %*d",0x40000000,1,0x40000000,1));
}
Ich hab das jetzt für die dietlibc so gemacht, daß *printf dann -1 zurück gibt. Offenbar ist das unter Solaris jetzt schon so, und wenn ich nicht der erste bin, der das so macht, dann trifft mich auch keine Schuld wegen der Kompatibilitätshölle :-)
Ich habe auch gerade eine Mail vom mirBSD-Projekt gekriegt, da hat jemand den Eintrag hier gesehen und nen Patch eingespielt, die liefern jetzt auch -1 zurück. Das war fix, keine zwei Stunden Turnaround!
Was mich daran am meisten schockiert: das hat keiner gemerkt. Niemand. Avahi gibt es nen Jahr? Länger? Und niemand außer mir hat offenbar mal unabhängig mdns implementiert. Der Effekt ist, daß wenn man mit dem dietlibc Resolver nach einem von avahi beantworteten Host fragt, die Antwort gefressen wird. Ich habe mal einen Workaround in die dietlibc eingebaut, aber hey, ist das zum Kotzen oder was?
Update: Jemand hat dem avahi-Autor Bescheid gesagt, und der hat mich jetzt per Email angepinkelt. Die Situation stellt sich tatsächlich etwas differenzierter dar als bisher dargestellt. avahi implementiert die aktuelle Spec, ich eine ältere. Meine Schuld, hätte ich vor dem Meckern mal gucken können. In der aktuellen Spec steht, daß das RD Bit Null sein soll beim Senden, und daß man es beim Reinkommen ignorieren muss. Das stand früher nicht in der Spec, aber man muss die Wayback Machine bemühen, um auf frühere Versionen zugreifen zu können; offenbar sind den zeroconf-Leuten die früheren Versionen peinlich. Anyway, ich habe mir avahi bei der Gelegenheit noch mal kurz angesehen, und muss sagen, ist nicht so schlimm wie gnupg, aber leider auch nicht so richtig toll. Ich hab da jetzt keinen kompletten Audit gemacht, aber schon mal direkt nen (nicht exploitbaren) off-by-one buffer overflow gefunden, und eine Endlosschleife in der DNS Dekompression. Ich denke mal, für avahi wird es demnächst ein Update geben. Der CVS-Code bei der dietlibc akzeptiert jetzt konform zur aktuellen Spec auch mDNS-Pakete, die das Bit anders setzen als es bei ihnen ankam. Ich möchte an dieser Stelle übrigens die mDNS-Specschreiber aufrufen, diesen Blödsinn zu lassen, und die Regeln von DNS bezüglich dieser Bits weiter bestehen zu lassen — Eingabe == Ausgabe. Dann kann man mehr Code wieder verwenden und ihr ganzes Gefasel von wegen Code-Wiederverwerten und Protokoll-Beibehalten stimmt dann auch tatsächlich. Eines ihrer Argumente ist ja gerade, daß man die APIs beibehalten kann, und daraus folgt, daß res_query das Paket nicht selber baut, sondern res_mkquery tut das, und daher ist es auch nicht kosher, wenn res_query dann im Paket rumdoktorn soll, um das RD Bit zu löschen (immerhin sagt die mDNS-Spec dafür nur SHOULD, daher spare ich mir das). Leider sagt die aktuelle mDNS-Spec auch, daß bei rausgehenden Antworten das RD-Bit Null sein soll, und die DNS-Spec sagt, daß bei Antworten dieses Bit übernommen werden soll. Wenn die das Gefasel mit API-Beibehalten also ernst nehmen, dann sollte hier ganz klar Eingabe == Ausgabe gelten.
Also ich mache sowas ja beruflich, und habe mir mal überlegt, ob ich nicht gnupg auditieren will. Aber das Ding ist ja so derartig am Explodieren von Release zu Release, das ist völlig unakzeptabel. gnupg ist einmal komplett Teil der TCB, solchen Code muss man minimieren. Was macht Herr Koch stattdessen? Baut da Grafik-Anzeigen rein, einen Agent, eine nicht abschaltbare Smartcard-Library, das (binäre!) Dateiformat ist zum Göbeln, der Footprint bei gnupg 2 beinhaltet auch noch libusb (WTF!?), pth (pthread-Abstraktion von GNU), hat LDAP drin (!?!?), … hier ist mal ein Codezeilen-Vergleich:
while(fgets(line,MAX_LINE,input))Irgendwie schon schade, daß es dieses Jahr kein Codequartett auf dem Congress gibt. MAX_LINE ist so definiert:
[…]
if(strlen(line)+keylen>keymax)
{
keymax+=200;
tmp=realloc(key,keymax+1);
[…]
key=tmp;
}
strcpy(&key[keylen],line);
keylen+=strlen(line);
#define MAX_LINE (6+1+1024+1)und keylen und keymax starten als 0. WTF?!