Mich wundert, dass hier bisher kein Wort über die jüngst bekannt gewordene Sicherheitskatastrophe namens "Heartbleed" verloren wurde.
http://www.golem.de/specials/heartbleed-bug/
Gibt es irgendwelche nachvollziehbaren Gründe, dass dieses Thema hier komplett unter den Tisch gefallen ist? Oder ist es purer Zufall?
Ist nickles.de von diesem Bug in irgendeiner Form betroffen?
Gruß, mawe2
the_mic 
mawe2 „Sicherheitskatastrophe "Heartbleed": Auf nickles.de kein Thema?“
Ist nickles.de von diesem Bug in irgendeiner Form betroffen?
Machst du als User hier irgendwelche verschlüsselte Verbindungen zu nickles.de? Nun, ich nicht, SSL gibt es hier schlicht nicht. Somit ist nickles.de zwar nicht betroffen. Dafür gehen unsere Passwörter immer im Klartext über die Leitung. Oder anders gesagt: Unsere nickles-Passwort sind eh weltbekannt!
Gibt es irgendwelche nachvollziehbaren Gründe, dass dieses Thema hier komplett unter den Tisch gefallen ist?
Auf nickles.de unterhalten sich relativ wenige Serverbetreiber über ihre Server. Den 08/15 User interessiert Sicherheit und Privatsphäre nur periphär. Dann kommt noch so ein komplexes Thema dazu. Und dieses krude, kompliziert zu bedienende OpenSource-Zeuch (OpenSSL hat doch was mit diesem Linux zu tun, nicht?)
Dazu kommt, dass das Thema auch sonst überall bis zum tot umfallen debattiert wird.
Soweit mal meine pessimistische Einschätzung :-)
mawe2 the_mic „Machst du als User hier irgendwelche verschlüsselte ...“
Nun, ich nicht, SSL gibt es hier schlicht nicht.
Soweit habe ich das für mich auch erkannt.
Aber ich nutze ja nicht alle Optionen von nickles.de, z.B. bin ich kein Premium-User. Deswegen meine Frage "in irgendeiner Form betroffen".
Ich habe mich eben nur gewundert, dass das hier so gar kein Thema ist.
Den 08/15 User interessiert Sicherheit und Privatsphäre nur periphär.
Ich diskutiere ja hier auch nicht mit "08/15 Usern" sondern mit Mitgliedern von nickles.de :-)
Ich denke, wir haben hier schon ganz andere (weniger dramatische) Sicherheitsprobleme ausführlich diskutiert. Zwar sind die Serverbetreiber jetzt zu allererst gefordert; die einzelnen User dieser Server sind aber die Betroffenen / Leidtragenden.
Soweit mal meine pessimistische Einschätzung :-)
Danke erstmal für Deine Einschätzung. Mal sehen, was noch so kommt?
Gruß, mawe2
mawe2 the_mic „Machst du als User hier irgendwelche verschlüsselte ...“
SSL gibt es hier schlicht nicht
Das war unsere letzte (übereinstimmende) Feststellung bezüglich nickles.de
Unter
kann man prüfen, ob ein Server von dem Bug betroffen ist oder nicht.
Ich habe testweise dort mal nickles.de eingegeben und erhalte folgendes Ergebnis:
x509: certificate has expired or is not yet valid
Vielleicht weiß jemand, was das bedeutet?
Wenn alles in Ordnung wäre, würde die Meldung in etwa so lauten:
Gruß, mawe2
mi~we mawe2 „Das war unsere letzte übereinstimmende Feststellung ...“
Vielleicht weiß jemand, was das bedeutet?
Ruf mal spasseshalber
auf. Dann meldet dir der Browser ein ungültiges Zertifikat. Lässt man sich dann die Details anzeigen, so erfährt man, daß das Zertifikat am 15.März abgelaufen ist. Macht man für das ungültige Zertifikat eine Ausnahme, so kann man nickles.de auch per https aufrufen. (Von wegen, es gibt hier kein SSL 
). Allerdings zerhaut es da etwas das Design der Seite.
Wenn du auf der Testseite ein Häkchen bei
Advanced (might cause false results): ignore certificates
machst, bekommst du auch für nickles.de eine "Alles OK" Meldung.
mawe2 mi~we „Ruf mal spasseshalber https://www.nickles.de auf. Dann ...“
Alles klar, danke!
Gruß, mawe2
xafford mawe2 „Das war unsere letzte übereinstimmende Feststellung ...“
Ja, ich weiß was das bedeutet :)
mi~we hat es eigentlich schon hinreichend erklärt - das Zertifikat ist abgelaufen. Der Hintergrund ist, dass Nickles bisher nie SSL für die Verschlüsselung einsetzte und ich das schon länger ändern wollte. Deswegen wurde vor knapp 8 Wochen ein Test-Zertifikat eingerichtet, um die Umstellung auf HTTPS zu testen. Da einiges andere dazwischen kam wurde das Zertifikat vorerst nicht verlängert (wir ziehen demnächst auf neue Server um) und HTTPS nicht im Live-Betrieb aktiviert.
Aufgrund dessen war Nickles auch kurzfristig für Hartbleed anfällig, nämlich von dem Punkt an dem das Test-Zertifikat installiert wurde, bis zu dem Tag an dem die Hartbleed-Lücke publik gemacht wurde. Da der Code für HTTPS jedoch bis zu diesem Zeitpunkt nicht publik war und keine Logins oder andere sensiblen Daten über HTTPS übertragen wurden kann eine Kompromittierung von Nutzer-Daten darüber auch mit ziemlicher Sicherheit ausgeschlossen werden.
Trotzdem werden wir in nächster Zeit SSL für sensible Nutzerdaten aktivieren, aber dies ist erst sinnvoll, wenn wir den Umzug vollzogen haben.
Hyperboreal mawe2 „Sicherheitskatastrophe "Heartbleed": Auf nickles.de kein Thema?“
Hallo,
Gibt es irgendwelche nachvollziehbaren Gründe, dass dieses Thema hier komplett unter den Tisch gefallen ist? Oder ist es purer Zufall?
Überlastung der User. Jeden Tag kommen neue Sicherheitslücken-Horrormeldungen.
Gewürzt mit NSA Interna + Vorratsdatenspeicherungs News.
Irgendwann schaltet man ab.
Ist nickles.de von diesem Bug in irgendeiner Form betroffen?
Wäre zum Glück nicht sicherheitsrelevant. :-) Oder? Ist doch nur ein Hilfe-Forum.
Ausserdem hat solche systemkritischen Sachen Xafford sicher höchstselbst
implementiert. Der überlässt nichts dem Zufall.
Gruss
Hyperboreal
mawe2 Hyperboreal „Hallo, Überlastung der User. Jeden Tag kommen neue ...“
Überlastung der User. Jeden Tag kommen neue Sicherheitslücken-Horrormeldungen.
Da ist sicher was dran.
Nur ist eben dieses Thema jetzt von so unglaublicher Brisanz und von einem so großen Umfang, dass man es in einem solchen Fachforum wie nickles.de doch irgendwie behandeln sollte, oder?
Gruß, mawe2
the_mic mawe2 „Da ist sicher was dran. Nur ist eben dieses Thema jetzt von ...“
Klar, der Fehler ist extrem kritisch, teuer und braucht bei betroffenen Admins eine unverzügliche Reaktion. Auch den Usern potentiell betroffener Systeme ist eine Änderung ihrer Passwörter anzuraten.
E-Banking ist z.B. kaum betroffen, da die Banken aufgrund sehr konservativer Software-Politik zumeist noch so alte Versionen von OpenSSL einsetzen, dass die fehlerhafte Routine noch gar nicht eingebaut war.
Ich persönlich finde die ganze Geheimdienstschnüffelei aber noch viel schlimmer, da dort mit Einsatz praktisch unbegrenzter Geldmengen unbegrenzte Informationsmengen (inkl. Login-Daten) abgegriffen werden. UND: Das ganze auch noch mit Vorsatz! Demgegenüber dürfte Heartbleed tatsächlich nur ein "normaler" Programmierfehler sein.
Hyperboreal the_mic „Klar, der Fehler ist extrem kritisch, teuer und braucht bei ...“
Hallo,
sehr konservativer Software-Politik zumeist noch so alte Versionen von OpenSSL einsetzen
Also, ich frage mich immer wieder, wie viele neue Sicherheitslücken bei
Updates neu ENTSTEHEN. Gibt es da vielleicht Studien dazu?
Oder ist das den "etalbierten Anbietern" von komplexer Software peinlich
so etwas zuzugeben?
Gruss
Hyperboreal
the_mic Hyperboreal „Hallo, Also, ich frage mich immer wieder, wie viele neue ...“
Jedes neue Feature, jede neue Zeile Code birgt das Risiko, eine kritische Sicherheitslücke zu enthalten. Man geht davon aus, dass bei guter Software ein kritischer Fehler pro 1000 Zeilen Code zu erwarten ist. Dieser Umstand ist sehr gut dokumentiert und erforscht.
Hersteller von Closed Source Software haben hier natürlich einen Vorteil. Wenn ein Fehler entdeckt wird, der nicht öffentlich bekannt gemacht wird, können sie in der nächsten Version einfach einen Fix ausliefern - u.U. sogar ohne diese Korrektur anzukündigen.
Hyperboreal the_mic „Jedes neue Feature, jede neue Zeile Code birgt das Risiko, ...“
Hallo,
dass bei guter Software ein kritischer Fehler pro 1000 Zeilen Code zu erwarten ist.
Darum liebe ich Python.
http://www.heise.de/developer/meldung/Python-erreicht-Spitzenwert-bei-Softwarequalitaet-1948541.html
Und vielleicht wirkt sich ja der gute Wert der Sprachimplementierung auch auf
die damit erstellte Software aus :-)
Gruss
Hyperboreal
the_mic Hyperboreal „Hallo, Darum liebe ich Python. ...“
Und vielleicht wirkt sich ja der gute Wert der Sprachimplementierung auch auf die damit erstellte Software aus :-)
Und von was träumst du nachts? ;-)
Stark abstrahierte Hochsprachen wie Python oder Java haben natürlich gewisse Vorteile. Diese ganzen Buffer-Overflows werden dort schon von vorneherein abgefangen. Das erkauft man sich aber mit Performance-Nachteilen (jede Prüfung kostet Zeit -> von vorne herein korrekt implementieren um die Prüfung unnötig zu machen, ist deutlich schneller). Dazu kommt, dass diese Sprachen z.T. jünger sind als bestehende, sicherheitskritische Softwarekomponenten.
Hyperboreal mawe2 „Da ist sicher was dran. Nur ist eben dieses Thema jetzt von ...“
Hallo,
irgendwie behandeln sollte, oder?
Klar.
Für mich gibt es zwei Aspekte:
1. Webkommunikation / Sicherheitsaspekte
2. Programmtechnische Umsetzung
Zu 2. kann ich nur sagen, dass ich C und dessen tollen Speichermanagement
eine gewisse Mitschuld gebe. Immer wieder liest man von Pufferüberläufen,
Zugriff (Abgriff) von Speicherinhalten, direckter Zugriff auf den Stack usw.
Manche Sprachen organisieren den Speicherzugriff selber, da braucht man
keine Pointerarithmetik und memcpy(). So eine Sache mit der gefälschten
Länge des Payloads wären dann gar nicht möglich, weil die Länge nicht
extra angegeben werden würde.
Vielleicht setzt sich ja mal jemand hin und implementiert alle Webdienste
und Protokollstacks in einer sichereren Sprache (Go?).
http://www.heise.de/security/artikel/So-funktioniert-der-Heartbleed-Exploit-2168010.html
Gruss
Hyperboreal
Hyperboreal Nachtrag zu: „Hallo, Klar. Für mich gibt es zwei Aspekte: 1. ...“
Hallo, eins kann ich jetzt schon sagen: Diie Bedeutung von Softwaretests und Software-Qualitätssicherung wird zunehmen! http://www.heise.de/developer/artikel/Qualitaetssicherung-ausgewogen-1792246.html Gruss Hyperboreal
mawe2 Hyperboreal „Hallo, eins kann ich jetzt schon sagen: Diie Bedeutung von ...“
Hier gibt's noch einen interessanten Artikel aus einem "Mainstream"-Blatt:
http://www.zeit.de/digital/internet/2014-04/heartbleed-openssl-open-source-heilsversprechen
Fazit: OpenSource kann auf Dauer nicht funktionieren, wenn das "Kostenlos-Prinzip" dazu führt, dass die Projekte nicht finanziert werden können.
OpenSource-Software muss kostenpflichtig werden!
Eine Garantie, dass grobe Sicherheitsmängel zuverlässig unterbunden werden, hat man zwar auch dann nicht. Aber wenn wichtige Projekte (wie eben Open-SSL) chronisch unterfinanziert sind, kann eben ein wichtiger Teil der Arbeiten (die strenge Qualitätskontrolle) nicht in angemessenem Maße stattfinden.
Gruß, mawe2
Borlander mawe2 „Hier gibt s noch einen interessanten Artikel aus einem ...“
Aber wenn wichtige Projekte (wie eben Open-SSL) chronisch unterfinanziert sind, kann eben ein wichtiger Teil der Arbeiten (die strenge Qualitätskontrolle) nicht in angemessenem Maße stattfinden.
Die strenge Qualitätskontrolle fällt aber gerade bei kommerzieller Software als erstes unter den Tisch. Kostet Geld und bringt sobald das ganze stabil läuft keinen unmittelbar sichtbaren Nutzen mehr.
Ich setze selbst bereits eine kommerzielles OpenSource-Produkt ein. Und da ist die Qualität keinesfalls besser als bei anderen OpenSource-Produkten. Ganz im Gegenteil. Für Dritte besteht in so einer Konstellation zudem absolut keine Motivation selbst etwas beizutragen.
Zu von den Dir verlinkten Artikel gibt es auch noch eine "Gegenpostion", die ich für näher an der Realität halte: http://blog.fefe.de/?ts=adb29937
Es wäre durchaus begrüßenswert wenn mehr Geld an freie Software-Projekte fließen würde. Der aktuelle Vorfall hat auch schon irgendwie eine gewisse Sensibilität für das Thema geschaffen wie man alleine an den aktuellen Zuwendungen für OpenSSL sehen kann. Es wäre zu hoffen, dass es dabei bleibt. Für Unternehmen ist es wohl leider oft auch Buchhalterischen Gründen schwierig für solche Projekte zu spenden. Gibt halt keine Rechnung darüber.
Wir könnten natürlichauch einfach Analog zu GEMA und VGWORT noch eine OpenSource-Abgabe auf Hardware einführen. Immerhin könnte man hier argumentieren, dass heute wirklich jeder irgendwie ein Stück freier Softwarearbeit nutzt. Spätestens beim Aufbau einer Internetverbindung.
mawe2 Borlander „Die strenge Qualitätskontrolle fällt aber gerade bei ...“
Zu von den Dir verlinkten Artikel gibt es auch noch eine "Gegenpostion", die ich für näher an der Realität halte
Naja, ob das realitätsnah ist, darüber könnte man sicher streiten.
Aber dieser Aspekt des "verantwortlich seins" ist schon sehr interessant. Komischerweise bin ich für das bisschen Code, das ich gelegentlich schreibe, sehr wohl verantwortlich: Weil ich es kommerziell mache. Weil ich einen Vertrag mit einem Kunden habe und Geld dafür bekomme. Und wenn ich dem Kunden Müll anbiete, dann haut er mir den Müll aber solange um die Ohren, bis ich was Ordentliches abliefere.
Bei OpenSource ist eben irgendwie niemand verantwortlich. Oder doch? Wer denn? Wen kann ich denn in Regress nehmen, wenn ich einen Schaden erleide auf Grund einer fehlerhaften OpenSource-Software?
Für Unternehmen ist es wohl leider oft auch Buchhalterischen Gründen schwierig für solche Projekte zu spenden. Gibt halt keine Rechnung darüber.
Wenn das unter dem Dach eines gemeinnützigen Vereins läuft, sollte eine finanzamtsaugliche Spendenquittung kein Problem darstellen.
Gruß, mawe2
Borlander mawe2 „Naja, ob das realitätsnah ist, darüber könnte man sicher ...“
für das bisschen Code, das ich gelegentlich schreibe, sehr wohl verantwortlich: Weil ich es kommerziell mache. Weil ich einen Vertrag mit einem Kunden habe und Geld dafür bekomme.
Dann sind wir aber schon im Bereich der Individualsoftware. Da ist die Beziehung zwischen Entwickler und Kunde doch ganz anders als bei Standardsoftware. Und da willst Du dann vielleicht auch noch mal einen lukrativen Folgeauftrag bekommen und machst deshalb sogar eher ein bisschen mehr als ein vereinbart wurde, oder wirst nach Zeitaufwand bezahlt…
Wen kann ich denn in Regress nehmen, wenn ich einen Schaden erleide auf Grund einer fehlerhaften OpenSource-Software?
Versuche mal Microsoft in Regress zu nehmen. Oder irgend einen anderen großen Softwarehersteller.
unter dem Dach eines gemeinnützigen Vereins läuft, sollte eine finanzamtsaugliche Spendenquittung kein Problem darstellen.
Dann bräuchtest Du aber in jedem Land einen entsprechenden Verein um das passend zu den lokalen Bedingungen zu gestalten. Ich befürchte das ist nicht so ganz praktikabel.
mawe2 Borlander „Dann sind wir aber schon im Bereich der Individualsoftware. ...“
Versuche mal Microsoft in Regress zu nehmen. Oder irgend einen anderen großen Softwarehersteller.
Ich will gar nicht behaupten, das mir das Gelingen würde. Aber da wüsste man zumindest, wer die Verantwortung hat. Und zumindest potentere Microsoft-Kunden als ich es bin, könnten durchaus einen Rechtsstreit in Angriff nehmen.
Dann bräuchtest Du aber in jedem Land einen entsprechenden Verein um das passend zu den lokalen Bedingungen zu gestalten. Ich befürchte das ist nicht so ganz praktikabel.
Bei LibreOffice geht das. Natürlich kann man das nicht verallgemeinern. Aber zumidest für größere OSS-Projekte sollte sowas machbar sein.
Gruß, mawe2
gelöscht_320029 Borlander „Die strenge Qualitätskontrolle fällt aber gerade bei ...“
Es bietet bei mir heute "Avira Free Antivirus" über ein Fenster an sich gegen "Heartbleed" zu schützen. Doch es steht nicht dabei ob man per "Klick" installieren auch etwas zu bezahlen hat. Gerade in letzter Zeit hat Avira so schon kostenpflichtig was verscherbelt ohne das es erkennbar war.
Sollte es solch eine Sicherheit gegen Heartbleed kostenlos geben?Falls ja, welche Auswirkungen hat diese zusätzliche Installation über Avira auf den Ablauf des PC- Alltags?
mawe2 gelöscht_320029 „Es bietet bei mir heute Avira Free Antivirus über ein ...“
Wie soll denn eine lokal installierte AV-Software gegen einen Fehler auf einem fremden Server helfen? Absurde Idee!
Gruß, mawe2
Borlander gelöscht_320029 „Es bietet bei mir heute Avira Free Antivirus über ein ...“
Es bietet bei mir heute "Avira Free Antivirus" über ein Fenster an sich gegen "Heartbleed" zu schützen.
Das wäre eher was für einen neuen Thread. Die Antwort in Kurzform hat mawe2 Dir ja bereits gegeben.
gelöscht_320029 Borlander „Das wäre eher was für einen neuen Thread. Die Antwort in ...“
Entschuldige bitte, so schnell lese ich nicht stetig, schaue ab und an auch in Mail nach. Das ist keine Entschuldigung, doch ich habe die Antwort verstanden und sehe meine Frage als beantwortet.
mawe2 Nachtrag zu: „Sicherheitskatastrophe "Heartbleed": Auf nickles.de kein Thema?“
@all:
WOW! Da hab ich ja was losgetreten... :-)
Auch wenn die programmier-theoretischen Überlegungen sicher alle ganz interessant sind, ging es mir mehr um die praktische Bedeutung für jeden User.
Alle Passwörter sollten geändert werden - so viel ist klar.
Aber wann sollte man das machen? Sofort? Ich weiß doch gar nicht, ob der jeweilige Server betroffen war und vor allem weiß ich nicht, ob der Bug bereits beseitig ist? Wenn ich das Passwort noch wechsele, bevor der Bug beseitig wurde, habe ich nichts gekonnt. Dann gilt das neue Passwort genau so als potenziell komprimittiert.
Welche Strategie als (möglicherweise) Betroffener User ist hier sinnvoll?
Zur Frage, ob man Passwörter regelmäßig (prophylaktisch) ändern sollte, wurde ja auch schon viel diskutiert. Fakt ist: Das ist bei der Menge an vorhandenen Online-Accounts einfach nicht machbar.
Hilft es, Online-Accounts, die nur gelegentlich gebraucht werden, immer sofort nach Beendigung des Vorgangs wieder zu löschen? Oder verbaue ich mir nur die Möglichkeit, selbst drauf zuzugreifen während meine persönlichen Daten für Dritte dort ohnhin weiter verfügbar / ausspionierbar vorliegen?
Aber ich merke schon: Die Fragen sind so vielfältig, einfache Antworten sind kaum zu erwarten, die Diskussion ist wichtig aber übersteigt wahrscheinlich auch alle verfügbaren (Zeit-) Ressourcen...
Gruß, mawe2
mawe2 Nachtrag zu: „Sicherheitskatastrophe "Heartbleed": Auf nickles.de kein Thema?“
Übrigens haben wir auch schon öfters diskutiert, ob Open Source Software per se sicherer als Closed Source Software ist, weil eine (große?) Community die Source Codes durchleuchtet und Schwachstellen entdeckt / beseitigt.
Ich war damals der Meinung, dass "Open Source" allein noch kein Qualitätskriterium sein kann und dass es keineswegs automatisch zu sichererer Software führen wird.
Das aktuelle Beispiel zeigt, dass der Fehler zwar in einer Open Source Software aufgedeckt wurde und dass die Qualitätsprüfung somit grundsätzlich funktioniert.
Wenn es aber zwei Jahre dauert, bis das passiert und der Bug somit zwei Jahre lang ausgenutzt werden konnte, kann man dieses Beispiel nur noch für die Untauglichkeit dieser Form der Qualitätssicherung heranziehen!
Gruß, mawe2
gelöscht_84526 mawe2 „Übrigens haben wir auch schon öfters diskutiert, ob Open ...“
Wenn es aber zwei Jahre dauert, bis das passiert und der Bug somit zwei Jahre lang ausgenutzt werden konnte,
Na ja, wenn man mal überlegt, wie lange MS an XP herumgebastelt hat und es nicht sicher bekommen hat, dann sind zwei Jahre ja geradezu ein verschwindend kleiner Zeitraum.
....und mit Win7 wird es wohl nicht anders sein. Da wird mit an Sicherheit grenzender Wahrscheinlichkeit ebenfalls bis zum Supportende dran gebastelt werden. So richtig sicher wird es auch im Jahr 2020 noch nicht sein - wie alles von MS.
Gruß
K.-H.
Hyperboreal gelöscht_84526 „Na ja, wenn man mal überlegt, wie lange MS an XP ...“
Hallo,
- wie alles von MS.
aber eigentlich geht es doch hier um Open-SSL
Microsoftprodukte sind nicht betroffen.
Gruss
Hyperboreal
gelöscht_84526 Hyperboreal „Hallo, aber eigentlich geht es doch hier um Open-SSL ...“
Mir ging es ja auch nur um diesen Satz:
"Wenn es aber zwei Jahre dauert, bis das passiert und der Bug somit zwei Jahre lang ausgenutzt werden konnte, kann man dieses Beispiel nur noch für die Untauglichkeit dieser Form der Qualitätssicherung heranziehen!"
...und um die Behauptung, dass diese Form der Qualitätssicherung als untauglich bezeichnet wird.
Anstelle von MS hätte ich jede andere Softwareschmiede nennen können. Nur kenne ich da kein Produkt, welches - wie WinXP - 13 Jahre supportet wurde und dann immer noch unsicher ist bzw. war.
Ich hoffe, dass du nun verstehst, wie mein Einwand gemeint war. Er war eher allgemeiner Natur, was Sicherheit angeht, wenn es darum geht, ob es sich um "Open" oder "Closed" handelt.
Gruß
K.-H.
mawe2 gelöscht_84526 „Mir ging es ja auch nur um diesen Satz: Wenn es aber zwei ...“
diese Form der Qualitätssicherung als untauglich bezeichnet
Als ich damals dieses Argument gebracht habe, hätte ich selbst nicht geglaubt, dass kein halbes Jahr später ein so fundamentaler Beweis für meine These erbracht wird!
Falls jemand die Diskussion von damals nochmal nachlesen möchte:
Und eines ist auch klar: Direkt betroffen sind diesmal ausschließlich die Nutzer bzw. Betreiber von Open Source Software. Neben den betroffenen Servern sind ausschließlich Linux-Clients betroffen! Windows und MacOS benutzen kein Open-SSL.
Indirekt sind natürlich alle betroffen, weil natürlich auch Windows- und Mac-User auf unsichere Open-SSL-Server zugreifen.
Gruß, mawe2
mawe2 gelöscht_84526 „Na ja, wenn man mal überlegt, wie lange MS an XP ...“
Na ja, wenn man mal überlegt, wie lange MS an XP herumgebastelt hat
Darum geht es aber hier nicht...
Gruß, mawe2
gelöscht_84526 mawe2 „Darum geht es aber hier nicht... Gruß, mawe2“
Ich wusste, dass du mein Beispiel bzw. meinen Hinweis nicht verstehst. Habe ich nicht anders erwartet.
Gruß
K.-H.
Hyperboreal gelöscht_84526 „Ich wusste, dass du mein Beispiel bzw. meinen Hinweis nicht ...“
Hallo,
na vielleicht war es doch ein bisschen schlecht, das Beispiel?
*duck und wech*
Hyperboreal
gelöscht_84526 Hyperboreal „Hallo, na vielleicht war es doch ein bisschen schlecht, das ...“
na vielleicht war es doch ein bisschen schlecht, das Beispiel?
Nee, war es eigentlich nicht. Man muss nur sein Gehirn einschalten und seinen Verstand (falls vorhanden) benutzen, um es zu verstehen.
Gruß
K.-H.
mawe2 gelöscht_84526 „Nee, war es eigentlich nicht. Man muss nur sein Gehirn ...“
Man muss nur sein Gehirn einschalten und seinen Verstand (falls vorhanden) benutzen
Na, wenn Du das schon so schön erkannt hast, wundert es mich, dass Du es hier so strikt vermeidest.
Gruß, mawe2
mawe2 gelöscht_84526 „Ich wusste, dass du mein Beispiel bzw. meinen Hinweis nicht ...“
Ich wusste, dass du mein Beispiel bzw. meinen Hinweis nicht verstehst.
Es ist für mich in der Tat immer wieder auf's Neue schwer verständlich, wie jemand in so einer Diskussion so weit am Thema vorbei diskutieren kann. Das hast Du richtig erkannt!
Wenn Dir das schon in dem Moment klar war, als Du das geschrieben hast, hättest Du es ja durchaus noch ändern können.
Und dann noch der Vorwurf, dass Microsoft doch tatsächlich immer wieder ("sicher auch wieder bei Windows 7") bis zum angekündigten Supportende den Support erbringt:
Da wird mit an Sicherheit grenzender Wahrscheinlichkeit ebenfalls bis zum Supportende dran gebastelt werden.
Na sowas aber auch!
Du fändest es also besser, wenn die schon vor dem offiziellen Supportende die Beseitigung von Sicherheitslücken einstellen würden??? Auch das ist wieder eine Deiner Argumentationen, die ich nicht verstehe...
Gruß, mawe2
gelöscht_84526 mawe2 „Es ist für mich in der Tat immer wieder auf s Neue schwer ...“
Wenn Dir das schon in dem Moment klar war, als Du das geschrieben hast, hättest Du es ja durchaus noch ändern können.
Nichts liegt mir ferner. Du verstehst doch sowieso nix.
Dieses Posting von dir, auf welches ich hier antworte, stärkt mich nur weiter in meiner Überzeugung.
Gruß und EOD
K.-H.
Borlander mawe2 „Übrigens haben wir auch schon öfters diskutiert, ob Open ...“
Wenn es aber zwei Jahre dauert, bis das passiert und der Bug somit zwei Jahre lang ausgenutzt werden konnte, kann man dieses Beispiel nur noch für die Untauglichkeit dieser Form der Qualitätssicherung heranziehen!
Es gibt allerdings auch genügend Beispiele für Lücken in Closed-Source-Software die noch länger ausnutzbar waren. Siehe z.B. die RTF-Lücke die seit grob mindestens 12 Jahren in MSO drin gewesen sein muss.
Zwei Jahre sind nun also keinesweg ein irrsinng langer Zeitraum. Natürlich sollte sowas generell nicht passieren. Im hier vorliegenden Fall wurde die Lücke allerdings durch unbeteiligte Dritte (einem Mitarbeiter von Google Security) entdeckt. Die Verfügbarkeit des Quellcodes wird dabei sicher nicht von Nachteil gewesen sein.
Ich gehe allerdings davon aus, dass dieser Bug sicherlich einen gewissen Einfluss haben wird auf die OpenSource-Software-Welt. Vor wird durch diesen Vorfall die Chance steigen, dass häufiger unabhängige Code-Reviews von häufig eingesetzter freier Software erfolgen.
Gruß
Borlander
mawe2 Borlander „Es gibt allerdings auch genügend Beispiele für Lücken in ...“
Es gibt allerdings auch genügend Beispiele für Lücken in Closed-Source-Software die noch länger ausnutzbar waren. Siehe z.B. die RTF-Lücke die seit grob mindestens 12 Jahren in MSO drin gewesen sein muss.
Das ist richtig. Nur dürfte diese Lücke kaum von der Dimension sein wie beim Heartbleed-Bug.
Und so lange eine Software Closed Source ist, haben auch die Hacker weniger Möglichkeiten, den Code nach solchen ausnutzbaren Problemen zu durchsuchen.
Zwei Jahre sind nun also keinesweg ein irrsinng langer Zeitraum.
Dafür, dass in dieser Zeit fast jede verschlüsselte Client-Server-Kommunikation als kompromittiert gelten kann, finde ich den Zeitraum schon ziemlich lang!
wird durch diesen Vorfall die Chance steigen, dass häufiger unabhängige Code-Reviews von häufig eingesetzter freier Software erfolgen.
Das ist möglich. Aber wo wird das verbindlich geregelt? So lange die Suche nach solchen Bugs mehr oder weniger zufällig stattfindet, sind die Verfahren nach wie vor sehr fragwürdig.
Gruß, mawe2
Borlander mawe2 „Das ist richtig. Nur dürfte diese Lücke kaum von der ...“
Nur dürfte diese Lücke kaum von der Dimension sein wie beim Heartbleed-Bug.
Dann werfen wir doch einfach mal einen Blick auf Sasser (betroffen waren mindestens W2K, XP und 2003 Server) und stellen uns vor es gäbe auch noch eine Variante ohne sichtbare Schadfunktion. Die hätte dann auch über 4-5 Jahre eingesetzt werden können…
Die Dimension ergibt sich schlicht und einfach aus der extrem hohen Verbreitung der Software. Wer weiß, was damals passiert wäre wenn die Hälfte der Webserver auf einem Windows-Server gelegen hätten. Dann wäre ein ähnliches Schreckensszenario denkbar gewesen.
Aber wo wird das verbindlich geregelt?
In wie fern ist das bei Closed-Source anders?
So lange die Suche nach solchen Bugs mehr oder weniger zufällig stattfindet, sind die Verfahren nach wie vor sehr fragwürdig.
Soweit ich das mitbekommen habe fand bei Google eine gezielte Überprüfung von OpenSSL statt, weil sie es in Zukunft verstärkt einsetzen wollen. Dabei wurde der Fehler gefunden. Wenn die oder ein anderer Software prüfen ohne dabei einen spektakulären Fehler zu finden bekommt davon natürlich keiner was mit. Ist vielleicht auch sogar besser so. Sonst sagt irgendwann mal einer: Jetzt haben sich das schon drei andere angeschaut, dann muss ich das nicht mehr selbst machen.
Maybe mawe2 „Übrigens haben wir auch schon öfters diskutiert, ob Open ...“
the_mic hatte das doch recht gut und prägnant zusammengefasst.
Jedes neue Feature, jede neue Zeile Code birgt das Risiko, eine kritische Sicherheitslücke zu enthalten. Man geht davon aus, dass bei guter Software ein kritischer Fehler pro 1000 Zeilen Code zu erwarten ist. Dieser Umstand ist sehr gut dokumentiert und erforscht. Hersteller von Closed Source Software haben hier natürlich einen Vorteil. Wenn ein Fehler entdeckt wird, der nicht öffentlich bekannt gemacht wird, können sie in der nächsten Version einfach einen Fix ausliefern - u.U. sogar ohne diese Korrektur anzukündigen.
Alle 1000 Zeilen ein kritischer Fehler. Das zählt für jegliche Software, ob nun FOSS (Free and Open Source Software) oder Proprietär.
Der Unterschied ist, Fehler in Open Source könnten schneller entdeckt werden, wenn sie eben jemandem auffallen und können schneller behoben werden, wenn sich denn jemand darum kümmert.
Von daher ist die hochgelobte Sicherheit bei Open Source doch recht theoretisch, wie es mit Sicherheit eben immer so ist.
Gruß
Maybe
The Wasp mawe2 „Sicherheitskatastrophe "Heartbleed": Auf nickles.de kein Thema?“
Die Reaktionen auf den Heartbleed-Bug sind mal wieder typsich Hysteriegeneration. Ein Angreifern könnte einen 64kb-Speicher auslesen, der zufällig beschrieben wird. Gezielt kann man gar nichts auslesen. Was bekommt der Angreifer? Die Stecknadel im Heuhaufen. Viel Spass beim Suchen und bei der weiteren Panikmache!
mawe2 The Wasp „Die Reaktionen auf den Heartbleed-Bug sind mal wieder ...“
Also Entwarnung??
groggyman mawe2 „Also Entwarnung??“
Hallo
Gerade habe ich eine Meldung dazu gelesen, wonach der NSA sich dieser Sicherheitslücke auch schon bedient haben soll, warum auch nicht, wenn es geht....
Bericht: NSA nutzte "Heartbleed" seit Jahren aus - WinFuture.de
Für mich wird das Netz immer mehr ein Sündenpfuhl, in dem sich mehr und mehr nur noch Kriminelle aufhalten, der eigentliche Spass ist schon seit Jahren nicht mehr vorhanden.
Das Beste wird sein, man stellt sich darauf ein, das alle Welt mitlesen kann und richtet seine Informationen danach aus.
Schönes WE.
-groggyman-
Hyperboreal groggyman „Hallo Gerade habe ich eine Meldung dazu gelesen, wonach der ...“
Hallo,
Loriot: "Ach"...
Das ist ja ganz was Neues.
Für mich wird das Netz immer mehr ein Sündenpfuhl,
Du machst doch selber mit, indem du kommentarlos Postings von Foristen löschst...
Sowas ist für mich eine Sünde.
Gruss
Hyperboreal
jueki Hyperboreal „Hallo, Loriot: Ach ... ...“
Du machst doch selber mit, indem du kommentarlos Postings von Foristen löschst... Sowas ist für mich eine Sünde.
Jeder Mensch und jede Gruppe auf dieser Welt nutzt vorhandene, gewährte Macht gnadenlos aus, weil sie sich absolut im Recht wähnt.
Da die, welche die Auswirkungen dieser Machtausübung spüren, nach Ansicht Ersterer im Unrecht sind, ist es dem/den jeweilig Macht ausübenden vollkommen gleichgültig, was die Betroffenen denken.
Denn sie haben ja Recht...
Jürgen
andy11 jueki „Jeder Mensch und jede Gruppe auf dieser Welt nutzt ...“
Fällst du allmählich dem Schwachsinn anheim? Andy
jueki andy11 „Fällst du allmählich dem Schwachsinn anheim? Andy“
allmählich
Ach wo, schon immer...
Jürgen
andy11 jueki „Ach wo, schon immer... Jürgen“
"Um ein tadelloses Mitglied einer Schafherde sein zu können, muss man vor allem ein Schaf sein." Albert Einstein
Dann wirst du wohl niemals der Schäfer werden. Andy
jueki andy11 „Dann wirst du wohl niemals der Schäfer werden. Andy“
Dann wirst du wohl niemals der Schäfer werden
Ja, das befürchte ich ebenfalls.
Jürgen
gelöscht_231142 jueki „Ach wo, schon immer... Jürgen“
Full ack...
und die Mächtigen hier dürften keinen Grund zum Machtausüben sehen 
.
enl
Borlander The Wasp „Die Reaktionen auf den Heartbleed-Bug sind mal wieder ...“
Was bekommt der Angreifer?
Der bekommt Daten die zuvor vom selben OpenSSL-Prozess verarbeitet wurden. Also nicht einfach irgendwelche. Das Problem wird auch dadurch begünstigt, dass OpenSSL eine eigene Speicherverwaltung implementiert und da soweit ich das mitbekommen habe mit recht großen Blöcken arbeitet. Der Heuhaufen ist deutlich kleiner als man auf den ersten Blick vermuten würde. Und wenn du das einfach mal ein paar Tausend mal probierst dann bekommst Du mit recht hoher Wahrscheinlichkeit auch mal Daten die kritisch sind zu Gesicht. Die Chancen dafür dürften signifikant besser sein als beim Lotto spielen.
Siehe auch So funktioniert der Heartbleed-Exploit:
"Erschwerend hinzu kommt, dass OpenSSL seine eigene Speicherverwaltung implementiert […], so dass dort dann nicht irgendwelche allgemeinen Daten des Servers stehen, sondern Daten aus dem Kontext von OpenSSL. Das sind dann häufig Passwörter oder andere, gerade eben entschlüsselte Daten eines anderen Benutzers oder auch geheime Schlüssel des Servers. […] Diesen Angriff kann man nun beliebig wiederholen und so massenweise Daten in 16 K großen Blöcken auslesen."
The Wasp Borlander „Der bekommt Daten die zuvor vom selben OpenSSL-Prozess ...“
Es gibt bisher keinen einzigen Beleg dafür, dass der Exploit verwendet wurde. Es geht wie fast immer in den letzten Jahren um die dramatisierte Möglichkeit und das Geschnatter über den daraus zu erwartenden Weltuntergang.
mawe2 The Wasp „Es gibt bisher keinen einzigen Beleg dafür, dass der ...“
Es sind wohl doch schon mehrere Belege vorhanden...
Ich denke, wir haben es hier nicht nur mit einem theoretischen Problem zu tun.
Gruß, mawe2
mawe2 The Wasp „Es gibt bisher keinen einzigen Beleg dafür, dass der ...“
http://www.golem.de/news/heartbleed-keys-auslesen-ist-einfacher-als-gedacht-1404-105825.html
Hyperboreal The Wasp „Die Reaktionen auf den Heartbleed-Bug sind mal wieder ...“
Hallo,
mal wieder typsich Hysteriegeneration.
Das ist ja ein statistisches Problem.
Wenn man lange genug Daten abgreift, bekommt man auch nützliches.
Was mich stutzig macht ist die zeitliche Nähe zu den Nachrichten über Millionen gefundene
Passwörter + Mailadressen, die letzte Woche durch die Presse geisterten.
Sollten die Daten nur mit Trojanern+Keyloggern entstanden sein?
Gruss
Hyperboreal
andy11 mawe2 „Sicherheitskatastrophe "Heartbleed": Auf nickles.de kein Thema?“
Mal sehen ob es noch härter kommt:
Eines hat mich die jüngste Vergangenheit gelehrt. Kommt Scheisse ans Tageslicht, ist das
in der Regel nicht mal die halbe Wahrheit. Entschuldigt meine Ausdrucksweise. Andy
Hyperboreal andy11 „Mal sehen ob es noch härter kommt: ...“
Hallo,
Joke of the day:
http://www.ad-hoc-news.de/us-geheimdienst-dementiert-ausnutzen-von--/de/News/36407666
Ha Ha Ha, sehr witzig -> "Nein sowas mach wir doch nicht!!! Niemals!!!"
Amerika Sicht auf die Welt ist doch diese:
http://www.ricdes.com/wp-content/stuff/americans.jpg
Jetzt müssen nur noch die Chinesen und die Russen dementieren und
die Welt ist wieder sicher. Oh, ich habe glatt Nordkorea vergessen.
Gruss
Hyperboreal
xafford mawe2 „Sicherheitskatastrophe "Heartbleed": Auf nickles.de kein Thema?“
Leider etwas spät, aber ich will trotzdem noch darauf antworten:
Mich wundert, dass hier bisher kein Wort über die jüngst bekannt gewordene Sicherheitskatastrophe namens "Heartbleed" verloren wurde.
Nun, Du warst wohl der erste Nutzer, der sich darüber Gedanken machte.
Gibt es irgendwelche nachvollziehbaren Gründe, dass dieses Thema hier komplett unter den Tisch gefallen ist? Oder ist es purer Zufall?
Siehe oben, es scheint auf Seiten der Nutzer so zu sein, dass entweder die Tragweite nicht bekannt ist, oder das Interesse eher gering.
Ist nickles.de von diesem Bug in irgendeiner Form betroffen?
Jein- siehe andere Antwort. Nickles hat bisher kein SSL eingesetzt, auch wenn seit knapp 8 Wochen testweise ein SSL-Betrieb möglich wäre. Den habe ich eingerichtet, um die Umstellung auf SSL für sicherheits-relevante Dinge zu testen. Da dies aber nur für Test-Zwecke verfügbar war und ist sind im Speicherbereich von OpenSSL keine sensiblen Daten von Nickles-Usern vorhanden und somit für Angrifer auch nicht auslesbar. An dem Tag als die Lücke bekannt wurde wurden auch der Server direkt aktualisiert.
Trotzdem werden wir demnächst SSL in einigen Bereichen einsetzen für eine verschlüsselte Übertragung und auch einige andere Bereiche werden umgestellt werden müssen um die Sicherheit zu erhöhen.
The Wasp xafford „Leider etwas spät, aber ich will trotzdem noch darauf ...“
Gibt es irgendwelche nachvollziehbaren Gründe, dass dieses Thema hier komplett unter den Tisch gefallen ist? Oder ist es purer Zufall?
Purer Zufall. Die Informatikprofis waren einfach mit anderen ähnlich komplexen Code-Problemen auf dem Programmierbrett so beschäftigt, dass sie Heartbleed einfach vergaßen.
