Erst App­les go­to-fail-Bug, dann der Zer­ti­fi­kats-Bug in GnuTLS, und jetzt der Heart­bleed-Bug in OpenS­SL – in den letz­ten Wo­chen hat fak­tisch jede SSL-Im­ple­men­tie­rung ihr Fett weg­be­kom­men. Die Schwe­re der Feh­ler sind oben­drein in auf­stei­gen­der Rei­hen­fol­ge: Sorg­ten die ers­ten bei­den „nur“ dafür, daß Zer­ti­fi­ka­te fälsch­li­cher­wei­se als gül­tig an­er­kannt wur­den, er­laubt Heart­bleed es, Spei­cher­be­rei­che aus­zu­le­sen.

Das wie

Wie der Heart­bleed-Bug aus­ge­nutzt wer­den kann be­schreibt xkcd schön in einem Comic:

(Bild CC by-nc Ran­dall Mun­roe)

Wer’s gerne etwas tech­ni­scher mag, dem emp­feh­le ich diese Be­schrei­bung des Hearbleed-Bugs. Fest­zu­hal­ten ist:

• Der An­grei­fer kann ca. 64 kB Spei­cher aus­le­sen, der „Da­ten­müll“ von vor­he­ri­ger Ver­wen­dung ent­hält
• Der An­grei­fer hat kei­nen Ein­fluß dar­auf, wo sich die­ser Spei­cher be­fin­det
• Der An­griff ist tri­vi­al durch­zu­füh­ren, hin­ter­lä­ßt keine Spu­ren, führt zu kei­nen Cras­hes und kann so in kur­zer Folge zig-fach an­ge­wandt wer­den
• Der An­griff funk­tio­niert in beide Rich­tun­gen – nicht nur ein bös­wil­li­ger Cli­ent kann so Daten vom Ser­ver ab­grei­fen, auch um­ge­kehrt kann ein bös­wil­li­ger Ser­ver einen arg­lo­sen Cli­ent an­grei­fen.

Das was und wer

An­griffs­zie­le sind na­he­lie­gen­der­wei­se Web­sei­ten, aber auch di­ver­se VPN-Lö­sun­gen nut­zen opens­sl als un­ter­lie­gen­de Tech­no­lo­gie. Brow­ser­sei­tig scheint die Welt noch­mal Glück ge­habt zu haben, aber ser­ver­sei­tig sieht es düs­ter aus: Äu­ßerst viele Web­ser­ver sind be­trof­fen, über Heart­bleed las­sen sich ver­schie­dens­te Daten sam­meln – be­gon­nen bei Daten an­de­rer Leute (bei Web­ser­vern mög­li­cher­wei­se das be­gehr­te Ses­sioncoo­kie) bis hin zu den SSL-Schlüs­seln des Ser­vers. Di­ver­se Leute, u.a. Cloud­Fla­re [spe­ku­lier­ten dar­auf, daß das Aus­le­sen der „Kron­ju­we­len“, näm­lich der SSL-Schlüs­sel nicht so ein­fach sei] (http://​blog.​cloudflare.​com/​answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed), al­ler­dings muß diese Aus­a­ge in­zwi­schen als wi­der­legt be­trach­tet wer­den.

Gru­se­lig ist die Über­le­gung, wer da alles Daten sam­melt – und seit wann. Be­rich­ten zu­fol­ge sam­mel­ten „In­ter­es­sier­te“ nach Be­kannt­wer­den des Bugs wild gi­ga­byte­wei­se Heart­bleed-Dumps. Fo­ren­si­ker ent­deck­ten bald Spu­ren, die be­leg­ten, daß der Bug seit min­des­tens letz­tem No­vem­ber aktiv ge­nutzt wird (siehe auch die­ser Be­richt der EFF). Eine na­he­lie­gen­de Ver­mu­tung ist es, ent­spre­chen­de Ak­ti­vi­tä­ten sei­tens Diens­ten wie der NSA an­zu­neh­men, die de­men­tiert dies je­doch. Die Ge­schich­te wird mög­li­cher­wei­se zei­gen, ob das der Wahr­heit ent­spricht.

Kon­se­quen­zen

Alle An­wen­dun­gen, die die be­trof­fe­nen opens­sl-Ver­sio­nen in den letz­ten zwei Jah­ren ver­wen­det haben, müs­sen kon­se­quen­ter­wei­se ihr Schlüs­sel­ma­te­ri­al als kom­pro­mit­tiert be­trach­ten. Das be­deu­tet neue Zer­ti­fi­ka­te für Web­ser­ver, VPN-Ser­ver und -Cli­ents, etc.

Be­nut­zer soll­ten auf bet­of­fe­nen Web­sei­ten ihre Kenn­wör­ter än­dern und ggfs. dort hin­ter­leg­te Zah­lungs­mit­tel auf un­ge­wöhn­li­che Ak­ti­vi­tä­ten hin be­ob­ach­ten. Das ist be­son­ders hart, da kaum ab­zu­se­hen ist, wel­che Web­sei­ten alles be­trof­fen waren. Ich bin bis dato von exakt einer(!) Seite be­nach­rich­tigt wor­den, wegen des Bugs zur Si­cher­heit mein Kenn­wort zu än­dern. Das kann bei wei­tem nicht alles sein.

Auch eine ein­fa­che Zwei-Fak­tor-Au­then­ti­sie­rung (wie z.B. Goog­le Au­then­ti­ca­tor) ist in die­sem Fall keine Si­cher­heit, denn es ist nicht aus­zu­schlie­ßen, daß das zu­ge­hö­ri­ge Ge­heim­nis nicht auch durch den Heart­bleed-Bug aus­ge­le­sen wer­den konn­te. Bes­ser sieht es bei der SSL-Cli­ent-Au­then­ti­sie­rung aus, hier wird auf dem Ser­ver kein (po­ten­ti­ell aus­les­ba­res) Ge­heim­nis, son­dern nur ein Zer­ti­fi­kat be­nö­tigt, wel­ches keine ge­hei­men Daten be­inhal­tet.

Für Ent­wick­ler sind die mit­tel­fris­ti­gen Kon­se­quen­zen fol­gen­de Fra­gen:

• Wie kann ins­be­son­de­re bei solch ver­brei­te­ten und si­cher­heits­kri­ti­schen Bi­blio­the­ken ver­hin­dert wer­den, daß sich sol­che Feh­ler ein­schlei­chen? Das Code-Re­view-Netz bei opens­sl war in die­sem Fall wohl nicht fein genug.
• Wie schüt­ze ich meine Nut­zer in sol­chen Worst-Ca­se-Sze­na­ri­en? Die klas­si­sche Na­me-Pass­wort-An­mel­dung hat be­reits aus an­de­rer Rich­tung schon Schram­men und Del­len, mit­tel­fris­tig wer­den hier an­de­re Lö­sun­gen be­nö­tigt. Die Ver­wen­dung von Per­fect For­ward Se­crecy beim Über­tra­gen von ver­schlüs­sel­ten Daten soll­te ei­gent­lich schon seit den ent­spre­chen­den Snow­den-Ent­hül­lun­gen zum Gold-Stan­dard ge­wor­den sein.
• Wie weit soll­ten Stan­dards ohne ei­ge­ne Über­le­gun­gen 1:1 um­ge­setzt wer­den? Die Heart­beat-Er­wei­te­rung ist in ver­schie­de­ner­lei Hin­sicht un­sin­nig. Sie macht nur Sinn bei SSL über UDP, und selbst hier gibt es keine ver­nünf­ti­ge Be­grün­dung für eine (oben­drein va­ria­ble) Pay­load bei einem Heart­beat-Pa­ket. Die hart­nä­cki­ge Frage, ob das viel­leicht doch der Ver­such einer sub­ti­len Back­door war, wird sich die IETF und das opens­sl-Team si­cher noch eine Weile ge­fal­len las­sen müs­sen.
• Wel­che Pro­gram­mier­spra­che ist die ge­eig­ne­te? Soll­te man ins­be­son­de­re bei neuen Pro­jek­ten über­haupt noch zu C/C++ grei­fen? Al­ter­na­ti­ven wie Go oder bes­ser noch Rust zei­gen, daß Low-Le­vel-Spra­chen heute auch ganz an­ders aus­se­hen kön­nen.