Diese Warnung kam gerade über die CAcert.org-Liste rein: ein Bug in OpenSSL (eingeführt mit Version 1.0.1, repariert in 1.0.1g) kann zu komplett unbemerktem Identitätsdiebstahl führen. http://www.golem.de/news/sicherheitsluecke-keys-auslesen-mit-openssl-1404-105685.html Wer eigene TLS-fähige Server betreibt, sollte sich also genau ansehen, ob er davon ggf. betroffen ist.
Jörg Wunsch schrieb: > Diese Warnung kam gerade über die CAcert.org-Liste rein: Das fällt denen ja früh auf... Andere haben das schon am 07.04. gemerkt und z.B. in Ubuntu & Debian Stable wurde es dann auch schon gefixt (schön "apt-get update && apt-get upgrade" laufen lassen).
Gestern kam's auf Bayern 3 in den Nachrichten :)
Der Patch wurde bereits 7.4.2014 um 19:21 (UTC) reingestellt. Das ist kein so grosses Ding, die meisten sind noch auf 0.9.8 Aber stimmt, der Bug ist übel.
Na sind ja einige betroffen, u.a. HypoVereinsbank, AfterBuy, Sparkasse.at, Adobe, Web.de, VeriSign ... "Die Liste lässt sich beliebig fortsetzen" http://www.heise.de/newsticker/meldung/Der-GAU-fuer-Verschluesselung-im-Web-Horror-Bug-in-OpenSSL-2165517.html http://www.heise.de/newsticker/meldung/Passwort-Zugriff-Heartbleed-Luecke-mit-katastrophalen-Folgen-2166861.html
Gleich mal ein Konto bei der Sparkasse (er)öffnen gehen. :)
Hatte heute eine Menge Anrufe von Kunden, die über Probleme beim Mailverkehr klagten. Die Provider sind wohl schon fleißig am Patchen. Der Witz an der Sache ist, daß gerade erst die Zugänge auf "sicheres" SSL umgestellt wurden. Nach NSA-Affäre, Router-Hacks und SSL-Bug, wieviele böse Überraschungen schlummern wohl noch im Web? Kommunikation 2.0 fängt an, sich zu rächen...
Kubuntu meint saucy-mäßig (gewagt, naseweis, frech), es wäre uptodate: > apt-show-versions openssl > openssl:amd64/saucy-security 1.0.1e-3ubuntu1.2 uptodate
Dr. Sommer schrieb: > Das fällt denen ja früh auf. Nö, aber sie haben sich halt die Mühe gemacht, alle diejenigen noch explizit anzuschreiben, die dort in den letzten 2 Jahren Zertifikate ausgefasst haben. Die Reparatur ihrer eigenen betroffenen Systeme hatte sicher erstmal Vorrang. Akku schrieb: > Das ist kein so grosses Ding, die meisten sind noch auf 0.9.8 Ja, offenbar.
Mir stellt sich da eher die Frage der Kommunikation. Wir wurden Montag Nacht Pikett aufgeboten, offensichtlich wurde die Firma eher informiert oder wir haben eine verdammt gute Security (was man auschliessen kann). So oder so, die Kommunikation muss da schneller werden. Wenn Exploits vor der Bekanntmachung verfügbar sind, ist nicht gut!
Detlef Kunz schrieb: > Kubuntu meint saucy-mäßig (gewagt, naseweis, frech), es wäre uptodate: >> apt-show-versions openssl >> openssl:amd64/saucy-security 1.0.1e-3ubuntu1.2 uptodate Immerhin ist der Bug gefixt, das sagt die "1.2". Wirklich uptodate (mit Version 1.0.1g) ist bspw. Arch-Linux.
Debian (stable) und Derivate werden meistens innerhalb der Version gefixt, d.h. es gibt keine möglicherweise funktionell geänderte 1.01g, sondern eine gefixte 1.01e.
:
Bearbeitet durch User
Andreas Schwarz schrieb: > Gestern kam's auf Bayern 3 in den Nachrichten :) So wichtig ist das? Kann mal einer das Problem erklären?
dfffs schrieb: > So wichtig ist das? Der Bug serviert dem Angreifer geheime Daten (z.B. Paßwörter) im Klartext auf dem Silbertablett. Die weite Verbreitung von OpenSSL macht das zu einem ernsthaften Problem. > Kann mal einer das Problem erklären? http://www.heise.de/security/artikel/So-funktioniert-der-Heartbleed-Exploit-2168010.html
Das eigentümliche an dem Bug ist, dass nur jene betroffen sind, die sorgfältig alle Server auf dem neuesten Stand halten. Wer aber beispielsweise noch die Vorversion von Debian verwendet, der kann sich (in diesem Fall) beruhigt zurücklehnen. Synology scheint es mit der Sicherheit übertrieben zu haben. Ein paar Leute haben sich mit dem Update ihre Box gebrickt. Totsicher: http://www.golem.de/news/synology-dsm-5-0-update-2-heartbleed-bugfix-legt-einige-nas-systeme-lahm-1404-105796.html
:
Bearbeitet durch User
Icke ®. schrieb: > dfffs schrieb: >> So wichtig ist das? > > Der Bug serviert dem Angreifer geheime Daten (z.B. Paßwörter) im > Klartext auf dem Silbertablett. Die weite Verbreitung von OpenSSL macht > das zu einem ernsthaften Problem. > >> Kann mal einer das Problem erklären? > > http://www.heise.de/security/artikel/So-funktioniert-der-Heartbleed-Exploit-2168010.html Oder sehr anschaulich im heutigen xkcd.com: http://xkcd.com/1354/
Was für ein bescheuerter Bug! http://www.heise.de/security/artikel/So-funktioniert-der-Heartbleed-Exploit-2168010.html Schicke als Client 1 Byte ("Heartbeat-Payload") an einen doofen (SSL-) Server zur Aufrechterhaltung der Kommunikation. Teile ihm mit, du hättest "64 Kilobyte" geschickt. Server ist doof (gehalten), glaubt dem Client natürlich, nimmt das 1 (!) Byte, packt es in seinen Puffer, denkt der sei jetzt mit 64 Kilobyte gefüllt (wie ihm der Client fälschlicherweise mitgeteilt hat)und returniert einen UNINITIALISIERTEN Puffer entsprechender Größe zurück, in dem nun alles mögliche stehen kann, was gerade zuvor so in der Verarbeitung anfiel, z.B. Passwörter. malloc() hurra!!
Wer mehr Details wissen möchte, insbesondere wer der Purche ist, der den Bug vom Zaun gebochen hat, der hier hat's verraten http://blog.fefe.de/
Unglaublich - ich hab jetzt eine ellenlange Erklärung erwartet, die man dann doch nicht komplett versteht will, und dann sowas. Puh das ist echt böse und ganz übel. Wenn der Rest vom code auch mit dieser Qualität aufwartet, dann gute Nacht. Gruß Jonas
Ich muss sagen mir ist nach der Aktion (jetzt alles gepatched und alle Zertifikate erneuert), ein böser Beigeschmack zurück geblieben. Wie kann es sein, dass diese Lücke seit über zwei Jahren im Quellcode schlummert (übrigens von einem jetzigen Mitarbeiter der Telekom eingecheckt) und niemand auch nur irgendwas bemerkt? Fehler macht jeder, keine Frage. Auch möchte ich keine Diskussion über open source/closed source anfachen. Nur hätte ich gedacht, dass es wesentlich schneller entdeckt wird. Zwei Jahre und dann entdecken es zwei Gruppen parallel. Die Malware war schneller: Ein Botnetz nutzt es schon mindestens seit einem halben Jahr. Da stellt sich natürlich die Frage, ob sich so ein Desaster nicht wiederholt. Vielleicht nicht in dem Umfang. Aber biete ich Serverdienste nach außen an kann ich mir zumindest nicht sicher sein, ob diese nicht kompromittiert werden können. Eine 100% Sicherheit gibt es natürlich nie. Aber zumindest eine, dass die NSA es nur schafft Metadaten auszuwerten gab es bislang. Übrigens sind meine Smartphones auch betroffen. Die Dinger zu aktualisieren entzieht sich allerdings den vertretbaren Möglichkeiten. Bislang habe ich allerdings auch noch nirgends gelesen wie man die Lücke auf einem Smartphone (sinnvoll) ausnutzen kann. Solange es also kein realistisches Angriffsszenario gibt, bleibt es wohl bei der Lücke. P.S.: Wie lange muss man warten, bis man nun alle Kennwörter ändern kann?
upgrade_completed schrieb: > jetzt alles gepatched und alle > Zertifikate erneuert Hoffentlich auch den Private Key hinter den Zertifikaten erneuert. Mindestens zwei Trustcenter haben Zertifikats-Erneuerungs-Anleitungen geschickt, bei denen der essentielle Schritt "Neuen Private Key erstellen" gefehlt hat... da gings gleich mit "neuen CSR erstellen&einsenden" los. Damit wird die ganze Aktion ziemlich sinnfrei.
Ich bin entsetzt. Auf das Schloß-Symbol in der Browser-Statusleiste kann man nun wohl kac*en.
Visualdingens schrieb: > Schicke als Client 1 Byte ("Heartbeat-Payload") an einen doofen (SSL-) > Server zur Aufrechterhaltung der Kommunikation. Teile ihm mit, du > hättest "64 Kilobyte" geschickt. Server ist doof (gehalten), glaubt dem > Client natürlich, nimmt das 1 (!) Byte, packt es in seinen Puffer, denkt > der sei jetzt mit 64 Kilobyte gefüllt (wie ihm der Client > fälschlicherweise mitgeteilt hat)und returniert einen UNINITIALISIERTEN > Puffer entsprechender Größe zurück, in dem nun alles mögliche stehen > kann, was gerade zuvor so in der Verarbeitung anfiel, z.B. Passwörter. > > malloc() hurra!! Der Buffer ist danach nicht unintialisiert und malloc hat nichts damit zu tun.
vn nn (wefwef_s) schrieb: > Der Buffer ist danach nicht unintialisiert und malloc hat nichts damit > zu tun. Es wird jedenfalls ein Buffer (Antwortpaket) mit irgendwelchen zufälligen (wohl eher riskanten) Daten returniert. Was ist daran nach deiner Meiunung jetzt "initialisiert"? Ich hab den Text überflogen und keine "Codeanalyse" erstellt. malloc kommt jedenfalls in einer eigenen Implementierungsvariante vor.
Positiv sehen! Jetzt werden wenigstens mal zahlreiche Server aktualisiert. Vielleicht auch ein paar schwache Zertifikate gegen bessere getauscht. (Schlechte Passwörter in andere schlechte geändert :)
Visualdingens schrieb: > malloc kommt jedenfalls in einer eigenen > Implementierungsvariante vor. und das malloc wurde nicht etwa aus Sicherheitsgründen neu implementiert, so z.B. Speicher überschreiben, boundary-checks etc, sondern rein aus Performance-Gründen. Auf gewissen *BSDs hat das system-malloc nämlich genau sowas gemacht, openssl war deshalb dort langsamer. d.H: für blöde Benchmark-Optimiererrei eine zusätzliche Sicherheitsebene über Bord geworfen, die genau dieses Problem verhindert hätte... ... Premature Optimization is the root of all Evil ...
Free the Mallocs! schrieb: > d.H: für blöde Benchmark-Optimiererrei eine zusätzliche Sicherheitsebene > über Bord geworfen, die genau dieses Problem verhindert hätte.. Schwachsinn. In wie fern hätten noch so viele Malloc-Checks verhindert, dass anschließend bei der Verwendung des Speichers über den reservierten Speicherbereich hinaus gelesen wurde?
Da Dieter schrieb: > Schwachsinn. In wie fern hätten noch so viele Malloc-Checks verhindert, > dass anschließend bei der Verwendung des Speichers über den reservierten > Speicherbereich hinaus gelesen wurde? Prinzipiell nichts. Es hätte aber die Wahrscheinlichkeit reduziert, in den erreichbaren 64KB interessante Daten zu finden, da der Heap dann für das Gesamtprogramm zuständig wäre, nicht nur für die SSL-Lib. Mit hoher Wahrscheinlichkeit lägen beispielsweise der private Key und dynamische Pufferdaten weit auseinander.
:
Bearbeitet durch User
Visualdingens schrieb: > Es wird jedenfalls ein Buffer (Antwortpaket) mit irgendwelchen > zufälligen (wohl eher riskanten) Daten returniert. Was ist daran nach > deiner Meiunung jetzt "initialisiert"? Ich hab den Text überflogen und > keine "Codeanalyse" erstellt. malloc kommt jedenfalls in einer eigenen > Implementierungsvariante vor. Es werden aber Daten mit memcpy hineinkopiert, konkret 16kB - 1 die nach pl kommen, er ist also nicht mehr uninitialisiert. Malloc hat nach wie vor nichts damit zu tun. Im Gegenteil, die Annahme, dass die malloc-Implementierung den Buffer mit einem bestimmten Pattern füllt, liegt nahe. Free the Mallocs! schrieb: > d.H: für blöde Benchmark-Optimiererrei eine zusätzliche Sicherheitsebene > über Bord geworfen, die genau dieses Problem verhindert hätte... > > ... Premature Optimization is the root of all Evil ... Unfug. Das Problem lag im Aufruf von memcpy, welcher ungeprüft mit der angegebenen Bufferlänge erfolgte und somit nicht nur den Payload, sondern auch nachfolgenden Speicher kopierte. A. K. schrieb: > Prinzipiell nichts. Es hätte aber die Wahrscheinlichkeit reduziert, in > den erreichbaren 64KB interessante Daten zu finden, da der Heap dann für > das Gesamtprogramm zuständig wäre, nicht nur für die SSL-Lib. Mit hoher > Wahrscheinlichkeit lägen beispielsweise der private Key und dynamische > Pufferdaten weit auseinander. Dann nutze ich Heartbleed eben per Script ein paar tausend Mal, und schon hab ich große Teile des Programmspeichers abgeklappert.
vn nn schrieb: > Dann nutze ich Heartbleed eben per Script ein paar tausend Mal, und > schon hab ich große Teile des Programmspeichers abgeklappert. Oder du bewegst dich immer im gleichen Bereich des Speichers, in dem kurzlebig allozierte und freigegebene Daten landen. Eine halbwegs moderne Heapverwaltung wird bei einer Anforderung vorzugsweise frisch freigegebenen Speicher vergeben.
:
Bearbeitet durch User
A. K. schrieb: > Oder du bewegst dich immer im gleichen Bereich des Speichers Denke ich auch, gibt es irgendwo einen bestätigten Fall wo wirklich mal sensible Daten gestohlen werden konnten? Also nicht nur "theoretisch". Hat die Schwachstelle in der Fritzbox ggf. genau damit zu tun gehabt? (Auf einem Embedded System kann ich mir das nämlich viel eher vorstellen).
:
Bearbeitet durch User
Läubi .. schrieb: > Denke ich auch, gibt es irgendwo einen bestätigten Fall wo wirklich mal > sensible Daten gestohlen werden konnten? Also nicht nur "theoretisch". http://www.golem.de/news/heartbleed-keys-auslesen-ist-einfacher-als-gedacht-1404-105825.html > Hat die Schwachstelle in der Fritzbox ggf. genau damit zu tun gehabt? Denke nicht. Aber wenn sich solche Einschläge im Internet weiter häufen, mit freundlicher Unterstützung seitens eigentlich für dessen Schutz vorgesehener Behörden, dann bestellen wir bald wieder per Brief aus dem Neckermann-Katalog statt bei Amazon und transportieren das Überweisungsformular per Walknet in die Bankfiliale. Ob es sich für den Wirtschaftsstandort Deutschland lohnen könnte, die Infrastruktur für ein das systematische Abhören und Schummeln erheblich erschwerendes Sneakernet aufzubauen? Sowas wie die Ökowende beim Strom, nur eben als Datenkommunikation per RFC1149? ;-) Amazon scheint sich schon auf solche Zeiten vorzubereiten. Dass dabei die Auslieferung von Waren im Vordergrund steht dürfte nur Tarnung sein.
:
Bearbeitet durch User
A. K. schrieb: > http://www.golem.de/news/heartbleed-keys-auslesen- Naja ich meinte eigentlich fernab von gestellten Szenarien. Gefakte Amzoneinkäufe, gehackte Accounts, MITM Pishings... 2,5 Millionen - 100.000 Anfragen sollten ja nun normalerweise auch nicht gänzlich unbemerkt bleiben.
vn nn schrieb: > Free the Mallocs! schrieb: >> d.H: für blöde Benchmark-Optimiererrei eine zusätzliche Sicherheitsebene >> über Bord geworfen, die genau dieses Problem verhindert hätte... >> >> ... Premature Optimization is the root of all Evil ... > > Unfug. Das Problem lag im Aufruf von memcpy, welcher ungeprüft mit der > angegebenen Bufferlänge erfolgte und somit nicht nur den Payload, > sondern auch nachfolgenden Speicher kopierte. Da Dieter schrieb: > Free the Mallocs! schrieb: >> d.H: für blöde Benchmark-Optimiererrei eine zusätzliche Sicherheitsebene >> über Bord geworfen, die genau dieses Problem verhindert hätte.. > > Schwachsinn. In wie fern hätten noch so viele Malloc-Checks verhindert, > dass anschließend bei der Verwendung des Speichers über den reservierten > Speicherbereich hinaus gelesen wurde? Erst nachdenken und sich gegebenenfalls informieren, dann "Unfug" oder "Schwachsinn" schreiben. Die "langsame" Malloc-Implementierung, die die OpenSSL-Entwickler rausoptimieren wollten, war die von OpenBSD. Warum war sie langsam? Weil sie den Speicher per "mmap" organisiert hat. Mit dieser Implementierung wäre der Bug nie zustande gekommen, weil a) ASLR es unwarscheinlich macht, dass zwei aufeinanderfolgene Mallocs "nebeneinander" zu liegen kommen b) frisch ge"mmap"-ter Speicher sauber mit 0x00 initialisiert ist, der out-of-bounds read hätte also nichts wertvolles gefunden c) freigegebener Speicher wird ge-'unmmp't ein memcopy hätte so auch beim reinen Lesezugriff über die Grenzen des Buffers hinaus einen SEGV ausgelöst.
Free the Mallocs! schrieb: > c) freigegebener Speicher wird ge-'unmmp't ein memcopy hätte so auch > beim reinen Lesezugriff über die Grenzen des Buffers hinaus einen SEGV > ausgelöst. OpenBSD verwendet Speicherallokation auf Bytegrenze? Wie macht es das? x86/x64 Paging hat 4KB Auflösung, wenn man nicht auf Segmentierung geht. Das geht also m.E. nur, wenn jedes derart verwaltete Speicherobjekt auf 4K aufgerundet und der Rest nicht genutzt wird. Kann man machen, ist aber für kleinteilige Allokation höchst ineffizient.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.