| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
Frank
registrierter User
Anmeldungsdatum: 31.07.2003
Beiträge: 6643
|
 (#1915342) Verfasst am: 11.04.2014, 14:04 Titel: Heartbleed & Co |
 |
|
http://hpd.de/node/18348
Was ist Eure Meinung?
Open Source versus Closed Source/ Security by Obscurity?
Wer ist Schuld?
Wie kann man das Internet einfacher und sicherer machen?
|
|
| Nach oben |
|
 |
Frank
registrierter User
Anmeldungsdatum: 31.07.2003
Beiträge: 6643
|
| (#1915343) Verfasst am: 11.04.2014, 14:36 Titel: |
|
|
Der User "ishrott" im Heise Forum hat den Heartbleed-Bug sehr anschaulich auch für IT-Laien beschrieben:
Client an Server: "Hier hast du 1 Byte Daten, ich behaupte aber, dass die Grösse 65536 Bytes beträgt."
Server an Client: "Okay, ich vertraue deiner Grössenangabe. Hier hast du dein Byte zurück und dazu noch 65535 Bytes aus meinem Speicherbereich, in dem ich bevorzugt vertrauliche Daten ablege."
Client an Server: "Cool, play it again, Sam!"
|
|
| Nach oben |
|
|
alae
auf eigenen Wunsch deaktiviert
Anmeldungsdatum: 23.03.2006
Beiträge: 7039
|
| (#1915345) Verfasst am: 11.04.2014, 14:42 Titel: |
|
|
| Frank hat folgendes geschrieben: | Der User "ishrott" im Heise Forum hat den Heartbleed-Bug sehr anschaulich auch für IT-Laien beschrieben:
Client an Server: "Hier hast du 1 Byte Daten, ich behaupte aber, dass die Grösse 65536 Bytes beträgt."
Server an Client: "Okay, ich vertraue deiner Grössenangabe. Hier hast du dein Byte zurück und dazu noch 65535 Bytes aus meinem Speicherbereich, in dem ich bevorzugt vertrauliche Daten ablege."
Client an Server: "Cool, play it again, Sam!" |
Noch anschaulicher: http://xkcd.com/1354/
|
|
| Nach oben |
|
|
Frank
registrierter User
Anmeldungsdatum: 31.07.2003
Beiträge: 6643
|
|
| Nach oben |
|
|
nocquae
diskriminiert nazis
Anmeldungsdatum: 16.07.2003
Beiträge: 18183
|
| (#1915348) Verfasst am: 11.04.2014, 15:12 Titel: Re: Heartbleed & Co |
|
|
| Frank hat folgendes geschrieben: | | Open Source versus Closed Source/ Security by Obscurity? |
Das überlege ich mir, wenn ich Schlaf nachgeholt habe.
Seit Dienstag tue ich nichts anderes, als im Akkord apache und nginx zu patchen und Zertifikate zu erneuern. 
_________________
In Deutschland gilt derjenige, der auf den Schmutz hinweist, als viel gefährlicher, als derjenige, der den Schmutz macht.
-- Kurt Tucholsky
|
|
| Nach oben |
|
|
Frank
registrierter User
Anmeldungsdatum: 31.07.2003
Beiträge: 6643
|
| (#1915351) Verfasst am: 11.04.2014, 15:37 Titel: Re: Heartbleed & Co |
|
|
| nocquae hat folgendes geschrieben: | | Frank hat folgendes geschrieben: | | Open Source versus Closed Source/ Security by Obscurity? |
Das überlege ich mir, wenn ich Schlaf nachgeholt habe.
Seit Dienstag tue ich nichts anderes, als im Akkord apache und nginx zu patchen und Zertifikate zu erneuern. |
Oh. Auf dem gbs/hpd Server sind wir nicht betroffen. 
|
|
| Nach oben |
|
|
Kival
Profeminist Ghost
Anmeldungsdatum: 14.11.2006
Beiträge: 24071
|
| (#1915352) Verfasst am: 11.04.2014, 15:40 Titel: Re: Heartbleed & Co |
|
|
| Frank hat folgendes geschrieben: |
Open Source versus Closed Source/ Security by Obscurity? |
Nothing changed:
| Bruce Schneier, Crypto-Gram 1999/09/15 hat folgendes geschrieben: |
As a cryptography and computer security expert, I have never understood the current fuss about the open source software movement. In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It's true for cryptographic algorithms, security protocols, and security source code. For us, open source isn't just a business model; it's smart engineering practice. |
http://www.schneier.com/crypto-gram-9909.html
_________________
"A basic literacy in statistics will one day be as necessary for efficient citizenship as the ability to read and write." (angeblich H. G. Wells)
Zuletzt bearbeitet von Kival am 11.04.2014, 16:30, insgesamt einmal bearbeitet |
|
| Nach oben |
|
|
sehr gut
dauerhaft gesperrt
Anmeldungsdatum: 05.08.2007
Beiträge: 14852
|
|
| Nach oben |
|
|
nocquae
diskriminiert nazis
Anmeldungsdatum: 16.07.2003
Beiträge: 18183
|
| (#1915367) Verfasst am: 11.04.2014, 19:05 Titel: Re: Heartbleed & Co |
|
|
| Frank hat folgendes geschrieben: | Open Source versus Closed Source/ Security by Obscurity?
Wer ist Schuld?
Wie kann man das Internet einfacher und sicherer machen? |
Also die Vergangenheit zeigt doch, dass sich open und closed source in puncto fehleranfälligkeit zunächst einmal nicht unterscheiden.
Bei open source werden Fehler aber im Durchschnitt schneller entdeckt und geschlossen.
_________________
In Deutschland gilt derjenige, der auf den Schmutz hinweist, als viel gefährlicher, als derjenige, der den Schmutz macht.
-- Kurt Tucholsky
|
|
| Nach oben |
|
|
nocquae
diskriminiert nazis
Anmeldungsdatum: 16.07.2003
Beiträge: 18183
|
| (#1915371) Verfasst am: 11.04.2014, 19:18 Titel: Re: Heartbleed & Co |
|
|
| Frank hat folgendes geschrieben: | | nocquae hat folgendes geschrieben: | | Frank hat folgendes geschrieben: | | Open Source versus Closed Source/ Security by Obscurity? |
Das überlege ich mir, wenn ich Schlaf nachgeholt habe.
Seit Dienstag tue ich nichts anderes, als im Akkord apache und nginx zu patchen und Zertifikate zu erneuern. |
Oh. Auf dem gbs/hpd Server sind wir nicht betroffen. |
Das FGH auch nicht.
Weil die OpenSSL-Version 6,5 Jahre alt ist.
Auf einem immerhin noch nicht ganz 6 Jahre alten Apache.
_________________
In Deutschland gilt derjenige, der auf den Schmutz hinweist, als viel gefährlicher, als derjenige, der den Schmutz macht.
-- Kurt Tucholsky
|
|
| Nach oben |
|
|
sehr gut
dauerhaft gesperrt
Anmeldungsdatum: 05.08.2007
Beiträge: 14852
|
| (#1915374) Verfasst am: 11.04.2014, 19:43 Titel: |
|
|
Was wir hier bei OpenSSL gerade haben, ist die kleinste Risikostufe. Bei der SDL heißt das "Information disclosure (untargeted)".
..
OpenSSL hat seinen eigenen Allokator gebaut. Theo de Raadt (der Mann hinter OpenBSD) regt sich schön darüber auf, erwähnt aber nur die halbe Problematik. Eigentlich nur ein Viertel. Der Grund, wieso OpenSSL einen eigenen Allokator gebaut hat, ist — so vermute ich jedenfalls — OpenBSD. OpenBSD scheißt auf Performance und macht ihr malloc dafür richtig doll langsam. Auf der Plus-Seite segfaultet das dann sofort, wenn jemand was falsch macht. Kann man vertreten, aber dann sieht das halt in Benchmarks so aus, als sei OpenSSL furchtbar langsam. OpenSSL hatte jetzt zwei Möglichkeiten. Sie hätten mal ihren Code entkernen können, damit der nicht so viel malloc und free aufruft. Das wäre die gute Variante gewesen. OpenSSL hat aber lieber getrickst und sich einen eigenen Allokator gebaut und damit, wie Theo kritisiert, die Sicherheitsvorteile des OpenBSD-Allokators aufgegeben.
|
|
| Nach oben |
|
|
smallie
resistent!?
Anmeldungsdatum: 02.04.2010
Beiträge: 3726
|
| (#1915389) Verfasst am: 11.04.2014, 23:55 Titel: |
|
|
Der größte Murks ist nicht C zuzuschreiben, sondern der Idee, einen Heartbeat mit 64K payload zuzulassen. Das ist etwa so, als würde ich nach vorübergehender Abwesenheit vom Forum im zugehörigen Thread das erste Kapitel von Krieg und Frieden posten - und dann erwarten, daß jemand mit einem Vollzitat antwortet, unter dem steht: "Schön, FULL ACK".
Das Konzept ist schlicht falsch.
Natürlich kann man sagen: bei einer managed language, in der Speicherbereiche von neuen Instanzen von Objektvariablen automatisch genullt werden, wäre das nicht passiert. Damit schließt man einen ganzen Bereich von Fehlern aus.
Aber erstens stehen solche Sprache nicht hoch im Kurs. Dazu ein etwas veraltetes Zitat:
| Zitat: | bondage-and-discipline language: n.
A language (such as Pascal, Ada, APL, or Prolog) that, though ostensibly general-purpose, is designed so as to enforce an author's theory of ‘right programming’ even though said theory is demonstrably inadequate for systems hacking or even vanilla general-purpose programming. Often abbreviated ‘B&D’; thus, one may speak of things “having the B&D nature”. See Pascal; oppose languages of choice.
http://www.catb.org/jargon/html/B/bondage-and-discipline-language.html |
Nicht umsonst war Ada im militärisch-industriellen Komplex lange die bevorzugte Sprache.
Zweitens kann man auch in diesen Sprachen Fehler machen. Ich erinnere daran, daß eine Ariane V vor vielen Jahren im Flug gesprengt werden mußte, weil es einen Überlauf in einer Routine gab. Für die Ariane IV war gezeigt worden, daß bei ihren Flugfähigkeiten kein Überlauf auftreten kann - das was so tief in der Dokumentation versteckt, daß niemand daran gedacht hatte zu überprüfen, ob es für die Ariane V immer noch gilt.
Die saubere Lösung, egal ob C oder eine andere Sprache, wäre TDD - Test Driven Development. Das bedeutete aber, daß für n Zeilen Code ein vielfaches an Testcode geschrieben werden muß. Der Testcode selbst muß wiederum durch absichtlichen Einbau von Fehlern in die Testdaten überprüft werden. Alles in Allem kein triviales Vorgehen, schon alleine weil es ungemein zeitraubend ist.
_________________
"There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors."
|
|
| Nach oben |
|
|
Kival
Profeminist Ghost
Anmeldungsdatum: 14.11.2006
Beiträge: 24071
|
|
| Nach oben |
|
|
Frank
registrierter User
Anmeldungsdatum: 31.07.2003
Beiträge: 6643
|
| (#1915419) Verfasst am: 12.04.2014, 15:03 Titel: Re: Heartbleed & Co |
|
|
| nocquae hat folgendes geschrieben: | | Frank hat folgendes geschrieben: |
Oh. Auf dem gbs/hpd Server sind wir nicht betroffen. |
Das FGH auch nicht.
Weil die OpenSSL-Version 6,5 Jahre alt ist.
Auf einem immerhin noch nicht ganz 6 Jahre alten Apache. |
Manchmal ist etwas konservativ sein doch nicht verkehrt. Ich wollte im letzten Jahr im Qualys SSL Server Test unbedingt ein Overall "A" Rating für unsere gbs/hpd & Co Webseiten haben. Und natürlich auch "Perfect Forward Secrecy", der Ehre wegen. Zur Abwehr von BEAST (Browser Exploit Against SSL/TLS) Angriffen wurde man damals regelrecht dazu gedrängt, TLS nur in der Version 1.1 und höher einsetzen. Eine weltfremde Empfehlung, da die wenigsten Webbrowser diesen schon mehrere Jahre alten Standard beherrschen (bzw. aktiviert haben). Und die, die TLS 1.1 und höher nutzen, laufen immer noch in unangenehme Bugs. Und ich meine hier nicht nur den aktuellen „Heartbleed“ Bug. Würde man nur TLS 1.1 bzw. 1.2 aktivieren und die „unsicheren älteren Protokolle“ abschalten, dann würde wir für die Mehrheit unserer User nicht mehr erreichbar sein. Das habe ich dann resigniert einsehen müssen.
Zuletzt bearbeitet von Frank am 12.04.2014, 15:22, insgesamt einmal bearbeitet |
|
| Nach oben |
|
|
Frank
registrierter User
Anmeldungsdatum: 31.07.2003
Beiträge: 6643
|
| (#1915422) Verfasst am: 12.04.2014, 15:21 Titel: |
|
|
| smallie hat folgendes geschrieben: |
Der größte Murks ist nicht C zuzuschreiben, sondern der Idee, einen Heartbeat mit 64K payload zuzulassen. |
agree, Das ist entweder eine bewusst eingebaute Hintertür um SSL/TLS zu kompromittieren, oder die Idee eines konzeptionellen Analphabeten, der in der IT Branche (nicht nur als Programmierer) nichts zu suchen hat. Selbst unter Beachtung des Dilbert-Prinzips wäre er selbst als Manager kaum tragbar.
| fefe.de hat folgendes geschrieben: |
Aus meiner Sicht riecht das wie eine Backdoor, es schmeckt wie eine Backdoor, es hat die Konsistenz einer Backdoor, und es sieht aus wie eine Backdoor.
|
Aber ganz so dumm scheint der Herr Dr. S. dann doch nicht zu sein. Ein partieller Aussetzter oder doch Backdoor Programmierer? Man sollte mal seine finanziellen Verhältnisse unter die Lupe nehmen.
|
|
| Nach oben |
|
|
sehr gut
dauerhaft gesperrt
Anmeldungsdatum: 05.08.2007
Beiträge: 14852
|
| (#1915460) Verfasst am: 12.04.2014, 21:48 Titel: |
|
|
| smallie hat folgendes geschrieben: | | Zweitens kann man auch in diesen Sprachen Fehler machen. Ich erinnere daran, daß eine Ariane V vor vielen Jahren im Flug gesprengt werden mußte, weil es einen Überlauf in einer Routine gab. Für die Ariane IV war gezeigt worden, daß bei ihren Flugfähigkeiten kein Überlauf auftreten kann - das was so tief in der Dokumentation versteckt, daß niemand daran gedacht hatte zu überprüfen, ob es für die Ariane V immer noch gilt. |
Ich kenne den Fall, da wurde ein 64bit-Fliesskomma in ein 16bit-Integer umgewandelt, was bei der IV ging und nicht mehr überprüft wurde, bei der V ging es nicht mehr, ohne Überprüfung.
Allerdings findet da doch kein Zugriff auf andere Speicherbereiche statt, die höheren Bits werden nur nicht beachtet.
Mein Punkt war ja das man eine Programmiersprache nutzt die den Zugriff auf andere Speicherbereiche leichter ermöglicht (Fehler oder Absicht).
Pufferüberläufe (englisch buffer overflow) gehören zu den häufigsten Sicherheitslücken in aktueller Software, die sich u. a. über das Internet ausnutzen lassen können. [..]
Die wesentlichste Ursache für Pufferüberläufe ist die Verwendung von Programmiersprachen, die nicht die Möglichkeit bieten, Grenzen von Speicherbereichen automatisch zu überwachen, um eine Bereichsüberschreitung von Speicherbereichen zu verhindern. Dazu gehört besonders die Sprache C
|
|
| Nach oben |
|
|
Skeptiker
"I can't breathe!"
Anmeldungsdatum: 14.01.2005
Beiträge: 16834
Wohnort: 129 Goosebumpsville
|
| (#1915489) Verfasst am: 13.04.2014, 09:56 Titel: |
|
|
| sehr gut hat folgendes geschrieben: | | smallie hat folgendes geschrieben: | | Zweitens kann man auch in diesen Sprachen Fehler machen. Ich erinnere daran, daß eine Ariane V vor vielen Jahren im Flug gesprengt werden mußte, weil es einen Überlauf in einer Routine gab. Für die Ariane IV war gezeigt worden, daß bei ihren Flugfähigkeiten kein Überlauf auftreten kann - das was so tief in der Dokumentation versteckt, daß niemand daran gedacht hatte zu überprüfen, ob es für die Ariane V immer noch gilt. |
Ich kenne den Fall, da wurde ein 64bit-Fliesskomma in ein 16bit-Integer umgewandelt, was bei der IV ging und nicht mehr überprüft wurde, bei der V ging es nicht mehr, ohne Überprüfung.
Allerdings findet da doch kein Zugriff auf andere Speicherbereiche statt, die höheren Bits werden nur nicht beachtet.
Mein Punkt war ja das man eine Programmiersprache nutzt die den Zugriff auf andere Speicherbereiche leichter ermöglicht (Fehler oder Absicht).
Pufferüberläufe (englisch buffer overflow) gehören zu den häufigsten Sicherheitslücken in aktueller Software, die sich u. a. über das Internet ausnutzen lassen können. [..]
Die wesentlichste Ursache für Pufferüberläufe ist die Verwendung von Programmiersprachen, die nicht die Möglichkeit bieten, Grenzen von Speicherbereichen automatisch zu überwachen, um eine Bereichsüberschreitung von Speicherbereichen zu verhindern. Dazu gehört besonders die Sprache C |
(Beim Link statt "ü" einfach "ü" eintragen, sonst kommt die Meldung: "Seite nicht erreichbar.")
Ja, Pufferüberlauf, Endlosschleifen, Informationsverlust durch Übersetzung von Fließkomma in ganze Zahlen - das sind Sachen, die bereits in einigen unzulänglichen Programmiersprachen eingebaut sind. Dass da Fehler und Eingriffsmöglichkeiten entstehen, ist zwangsläufig.
Die Personalcomputer für die breite Masse sollen ja auch nicht den Zweck erfüllen, sicher und zuverlässig zu sein oder nur so weit, dass die Masse damit Infos abrufen kann, Mails austauschen - all das, was sie so braucht, um ihren Alltag zu regeln und immer pünktlich zur Arbeit zu kommen.
Das Verkehrssystem muss ja auch nur so einigermaßen funktionieren, damit die Wirtschaft läuft. Kollateralschäden durch Verkehrstote sind da nicht so schlimm.
Das selbe gilt ja auch für die Energieerzeugung. Ein paar Krebstote mehr oder weniger durch Feinstaub fällt unter die Kategorie: wo gehobelt wird, fallen Späne.
---
Um zum Programmieren zurück zu kommen:
Hier sollte man nach dem Motto verfahren: "Lieber weniger, aber besser!" ...-!
_________________
°
K.I.Z - Frieden
Das ist Postmoderne Ideologie! Psychologe und Philosoph analysieren RASSISMUS-Video
Informationsstelle Militarisierung e.V.
|
|
| Nach oben |
|
|
alae
auf eigenen Wunsch deaktiviert
Anmeldungsdatum: 23.03.2006
Beiträge: 7039
|
| (#1915495) Verfasst am: 13.04.2014, 10:53 Titel: |
|
|
| Skeptiker hat folgendes geschrieben: | | Ja, Pufferüberlauf, Endlosschleifen, Informationsverlust durch Übersetzung von Fließkomma in ganze Zahlen - das sind Sachen, die bereits in einigen unzulänglichen Programmiersprachen eingebaut sind. |
Ernste Frage: Kennst du eine Sprache in der all das nicht vorkommen kann?
|
|
| Nach oben |
|
|
Skeptiker
"I can't breathe!"
Anmeldungsdatum: 14.01.2005
Beiträge: 16834
Wohnort: 129 Goosebumpsville
|
| (#1915501) Verfasst am: 13.04.2014, 11:10 Titel: |
|
|
| alae hat folgendes geschrieben: | | Skeptiker hat folgendes geschrieben: | | Ja, Pufferüberlauf, Endlosschleifen, Informationsverlust durch Übersetzung von Fließkomma in ganze Zahlen - das sind Sachen, die bereits in einigen unzulänglichen Programmiersprachen eingebaut sind. |
Ernste Frage: Kennst du eine Sprache in der all das nicht vorkommen kann? |
So absolut nicht. Aber es gibt Unterschiede in der Speicherkontrolle, Typensicherheit oder auch Lesbarkeit des Codes.
Die eine Sache ist die Sicherheit der Programmiersprache selbst, wofür es durchaus noch Potenzial gibt.
Und das andere wären eben systematische Programmierabläufe, bei denen vom ersten Entwurf über tiefgehende Tests eine zu entwickelnde Software optimiert wird.
Natürlich ist das umso wichtiger je komplexer die Anforderungen werden und die werden ja in Zukunft (- Robotik, Datensicherheit, Datenschnittstellen, usw. -) immer komplexer.
_________________
°
K.I.Z - Frieden
Das ist Postmoderne Ideologie! Psychologe und Philosoph analysieren RASSISMUS-Video
Informationsstelle Militarisierung e.V.
|
|
| Nach oben |
|
|
sehr gut
dauerhaft gesperrt
Anmeldungsdatum: 05.08.2007
Beiträge: 14852
|
| (#1915502) Verfasst am: 13.04.2014, 11:12 Titel: |
|
|
| Skeptiker hat folgendes geschrieben: | | (Beim Link statt "ü" einfach "ü" eintragen, sonst kommt die Meldung: "Seite nicht erreichbar.") |
Hatte ich getan, aber wenn du die Seite aufrufst wird aus dem "ü" ein "ü" gemacht.
[/OT]
|
|
| Nach oben |
|
|
sehr gut
dauerhaft gesperrt
Anmeldungsdatum: 05.08.2007
Beiträge: 14852
|
| (#1915503) Verfasst am: 13.04.2014, 11:20 Titel: |
|
|
| Skeptiker hat folgendes geschrieben: | | Die Personalcomputer für die breite Masse sollen ja auch nicht den Zweck erfüllen, sicher und zuverlässig zu sein oder nur so weit, dass die Masse damit Infos abrufen kann, Mails austauschen - all das, was sie so braucht, um ihren Alltag zu regeln und immer pünktlich zur Arbeit zu kommen. |
Schon klar, solange NSA/Stasi nur das Volk ausschnüffelte war das kein Problem, erst als die Merkel selbst betroffen war wurde es zur Frechheit.
|
|
| Nach oben |
|
|
NoReply
registrierter User
Anmeldungsdatum: 21.09.2013
Beiträge: 683
|
| (#1915562) Verfasst am: 13.04.2014, 18:50 Titel: |
|
|
| sehr gut hat folgendes geschrieben: | | Mein Punkt war ja das man eine Programmiersprache nutzt die den Zugriff auf andere Speicherbereiche leichter ermöglicht (Fehler oder Absicht). |
Allerdings sind die gleichen Programme in solchen Sprachen dann auch langsamer und brauchen mehr RAM. Und die Möglichkeit Pufferüberläufe einzubauen bieten sie immer noch, nur dass das Programm dann gleich komplett abstürzt.
|
|
| Nach oben |
|
|
sehr gut
dauerhaft gesperrt
Anmeldungsdatum: 05.08.2007
Beiträge: 14852
|
| (#1915564) Verfasst am: 13.04.2014, 18:58 Titel: |
|
|
| NoReply hat folgendes geschrieben: | | sehr gut hat folgendes geschrieben: | | Mein Punkt war ja das man eine Programmiersprache nutzt die den Zugriff auf andere Speicherbereiche leichter ermöglicht (Fehler oder Absicht). |
Allerdings sind die gleichen Programme in solchen Sprachen dann auch langsamer und brauchen mehr RAM. |
Das war früher bei langsamen CPUs und winzigen RAM-Mengen ein Punkt...
|
|
| Nach oben |
|
|
NoReply
registrierter User
Anmeldungsdatum: 21.09.2013
Beiträge: 683
|
| (#1915579) Verfasst am: 13.04.2014, 19:40 Titel: |
|
|
| sehr gut hat folgendes geschrieben: | | NoReply hat folgendes geschrieben: | | sehr gut hat folgendes geschrieben: | | Mein Punkt war ja das man eine Programmiersprache nutzt die den Zugriff auf andere Speicherbereiche leichter ermöglicht (Fehler oder Absicht). |
Allerdings sind die gleichen Programme in solchen Sprachen dann auch langsamer und brauchen mehr RAM. |
Das war früher bei langsamen CPUs und winzigen RAM-Mengen ein Punkt... |
Bei Anwendungen für Endanwender ist das heute sicherlich eher ein unbedeutender Punkt, kommt auf das genaue Programm an und wenn man zeitkritische Programmteile hat, schreibt man dann häufig nur diese in C/C++ oder Assembler. Aber bei systemnahen Komponenten ist das durchaus auch heute noch ein sehr kritischer Punkt.
|
|
| Nach oben |
|
|
sehr gut
dauerhaft gesperrt
Anmeldungsdatum: 05.08.2007
Beiträge: 14852
|
| (#1915581) Verfasst am: 13.04.2014, 19:57 Titel: |
|
|
| NoReply hat folgendes geschrieben: | | sehr gut hat folgendes geschrieben: | | NoReply hat folgendes geschrieben: | | sehr gut hat folgendes geschrieben: | | Mein Punkt war ja das man eine Programmiersprache nutzt die den Zugriff auf andere Speicherbereiche leichter ermöglicht (Fehler oder Absicht). |
Allerdings sind die gleichen Programme in solchen Sprachen dann auch langsamer und brauchen mehr RAM. |
Das war früher bei langsamen CPUs und winzigen RAM-Mengen ein Punkt... |
Bei Anwendungen für Endanwender ist das heute sicherlich eher ein unbedeutender Punkt, kommt auf das genaue Programm an und wenn man zeitkritische Programmteile hat, schreibt man dann häufig nur diese in C/C++ oder Assembler. Aber bei systemnahen Komponenten ist das durchaus auch heute noch ein sehr kritischer Punkt. |
Mag sein dass das bei 0.01% sämtlicher Programme ein Punkt sein kann, aber ausgerechnet ein sicherheitsrelevantes Programm (wo dies nicht zutrifft) mit einer kritischen Programmiersprache zu schreiben...
|
|
| Nach oben |
|
|
Landei
Gesinnungspolizist
Anmeldungsdatum: 27.02.2011
Beiträge: 1180
Wohnort: Sandersdorf-Brehna
|
| (#1915590) Verfasst am: 13.04.2014, 20:26 Titel: |
|
|
| alae hat folgendes geschrieben: | | Skeptiker hat folgendes geschrieben: | | Ja, Pufferüberlauf, Endlosschleifen, Informationsverlust durch Übersetzung von Fließkomma in ganze Zahlen - das sind Sachen, die bereits in einigen unzulänglichen Programmiersprachen eingebaut sind. |
Ernste Frage: Kennst du eine Sprache in der all das nicht vorkommen kann? |
- Pufferüberlauf wird in allen Sprachen mit automatischer Bereichsprüfung (wo dann naturgemäß auch Pointerarithmetik verboten ist) verhindert, z.B. Java
- Endlosschleifen lassen sich in einer turing-kompletten Sprache (und das sind alle in der Praxis eingesetzten) nicht sicher verhindern - Stichwort "Halteproblem"
- Versehentlicher Informationsverlust durch Konvertierung wird dort zumindest erschwert, wo eine Umwandlung explizit erfolgen muss, etwa in Haskell
_________________
Der Islam gehört auf den Müllhaufen der Geschichte. Diese Gotteslehre eines unmoralischen Beduinen ist ein verwesender Kadaver, der unser Leben vergiftet. (Kemal Atatürk)
|
|
| Nach oben |
|
|
smallie
resistent!?
Anmeldungsdatum: 02.04.2010
Beiträge: 3726
|
| (#1915591) Verfasst am: 13.04.2014, 20:30 Titel: |
|
|
| Frank hat folgendes geschrieben: | | smallie hat folgendes geschrieben: |
Der größte Murks ist nicht C zuzuschreiben, sondern der Idee, einen Heartbeat mit 64K payload zuzulassen. |
agree, Das ist entweder eine bewusst eingebaute Hintertür um SSL/TLS zu kompromittieren, oder die Idee eines konzeptionellen Analphabeten, der in der IT Branche (nicht nur als Programmierer) nichts zu suchen hat. Selbst unter Beachtung des Dilbert-Prinzips wäre er selbst als Manager kaum tragbar. |
In der Tat.
Es gibt zwar diesen alten Spruch, man solle nie etwas durch Böswilligkeit erklären, was auch durch Dummheit erklärt werden kann. Stichwort Hanlon's Razor. Aber ab einem gewissen Schweregrad ist auch Dummheit keine ausreichende Erklärung mehr. Eine überzeugende Motivation für die 64k kann ich mir kaum vorstellen. In jedem Fall würde hier ein anderes Prinzip greifen: YAGNI - you ain't gonna need it. Das sollte ein Informatiker, ein Dr. der Informatik gar, eigentlich kennen.
Ah, ok. Wenn du Sicherheit so fasst, daß es nicht um Zugriffsverletzungen geht, die ein Programm abstürzen lassen, sondern nur um Datensicherheit im Sinne von "es darf keinen (untypisierten) Zeiger geben, der irgendwo in den gültigen Adressbereich des Programms zeigt und dann Datenmüll oder eben sicherheitsrelevante Daten enthält" - dann gebe ich dir natürlich völlig Recht.
| Skeptiker hat folgendes geschrieben: | | alae hat folgendes geschrieben: | | Skeptiker hat folgendes geschrieben: | | Ja, Pufferüberlauf, Endlosschleifen, Informationsverlust durch Übersetzung von Fließkomma in ganze Zahlen - das sind Sachen, die bereits in einigen unzulänglichen Programmiersprachen eingebaut sind. |
Ernste Frage: Kennst du eine Sprache in der all das nicht vorkommen kann? |
So absolut nicht. Aber es gibt Unterschiede in der Speicherkontrolle, Typensicherheit oder auch Lesbarkeit des Codes.
Die eine Sache ist die Sicherheit der Programmiersprache selbst, wofür es durchaus noch Potenzial gibt. |
Auch eine moderne Sprache wie C# erlaubt es, "unsicheren" Code zu schreiben, wenn man das unsafe keyword setzt.
_________________
"There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors."
|
|
| Nach oben |
|
|
alae
auf eigenen Wunsch deaktiviert
Anmeldungsdatum: 23.03.2006
Beiträge: 7039
|
| (#1915637) Verfasst am: 14.04.2014, 09:15 Titel: |
|
|
| Skeptiker hat folgendes geschrieben: | | alae hat folgendes geschrieben: | | Skeptiker hat folgendes geschrieben: | | Ja, Pufferüberlauf, Endlosschleifen, Informationsverlust durch Übersetzung von Fließkomma in ganze Zahlen - das sind Sachen, die bereits in einigen unzulänglichen Programmiersprachen eingebaut sind. |
Ernste Frage: Kennst du eine Sprache in der all das nicht vorkommen kann? |
So absolut nicht. Aber es gibt Unterschiede in der Speicherkontrolle, Typensicherheit oder auch Lesbarkeit des Codes.
Die eine Sache ist die Sicherheit der Programmiersprache selbst, wofür es durchaus noch Potenzial gibt. |
Ah, OK.
Ich hab nur nachgefragt, weil ich erst gemeint habe, du würdest alle Sprachen mit Endlosschleifen und Typecasting für unzulänglich halten.
|
|
| Nach oben |
|
|
sponor
registrierter User
Anmeldungsdatum: 16.05.2008
Beiträge: 1712
Wohnort: München
|
| (#1915855) Verfasst am: 15.04.2014, 10:59 Titel: Re: Heartbleed & Co |
|
|
Um mal darauf zurück zu kommen:
| Frank hat folgendes geschrieben: | http://hpd.de/node/18348
Was ist Eure Meinung?
Open Source versus Closed Source/ Security by Obscurity?
Wer ist Schuld?
Wie kann man das Internet einfacher und sicherer machen? |
Sascha Lobo hält ja unverdrossen bei SpOn die Netzaktivisten-Flagge hoch (zum Glück), da hat er auch zum zukünftigen Internet was geschrieben, was ich ähnlich sehe: Dezentralisierung.
Ansonsten würde ich deinem hpd-Beitrag auch weitgehend zustimmen. Ich denke, technisch sind die Probleme relativ einfach zu lösen, falls die Voraussetzungen stimmen: Neutralität, generelle Verschlüsselung (evtl. sogar immer zwingend vorgeschrieben), sinnvolle Beilegung des Copyright-Streits und eine echt unabhängige, dezentrale Verwaltung müssten "halt einfach" politisch erwünscht sein; fertig.
Ja, ich weiß, es entwickelt sich komplett in die andere Richtung...
Nebenbei: Schöne Idee, ich glaube beim von mir schon öfter verlinkten 30C3-Vortrag Bullshit made in Germany: Wenn man elektronischen Perso und De-Mail gescheit hätte machen wollen, hätte das ganz wunderbar werden können:
Jeder kriegt sein eigenes, persönliches Zertifikat auf seinem ePerso (das natürlich "von Staats wegen" ordentlich autorisiert ist). Das kann er fürderhin nutzen, um alles – Mails und jede andere Kommunikationsart – damit zu signieren und/oder Ende-zu-Ende zu verschlüsseln. Wenn man gleich noch S/MIME etwas aufhübschte...
Warum es das nicht gibt, wird im Vortrag auch genannt und ist (leider) trivial: niemand könnte Geld verdienen, niemand könnte abhören.
(Das gern genommene Beispiel mit den Geldautomaten sehe ich i.Ü. gar nicht so kritisch – wenn die über ein geschlossenes Netzwerk mit der Bank/Clearingstelle/wemauchimmer verbunden sind, kann nicht so schrecklich viel passieren. Außerdem ist die Haftungsfrage ziemlich eindeutig. Pech für die Bank, wenn dann Jungs mit USB-Sticks anrücken und die Kiste leeren...)
_________________
Unsere Welt wird noch so fein werden, daß es so lächerlich sein wird, einen Gott zu glauben als heutzutage Gespenster.
(G. Chr. Lichtenberg)
|
|
| Nach oben |
|
|
Frank
registrierter User
Anmeldungsdatum: 31.07.2003
Beiträge: 6643
|
| (#1918827) Verfasst am: 29.04.2014, 04:41 Titel: |
|
|
Gravierende Lücken in medizinischen Geräten
| heise online hat folgendes geschrieben: |
Medizinische Geräte in US-Krankenhäusern offenbaren gravierende Sicherheitsmängel ... ferngesteuerte OP-Roboter, schleichende Vergiftung und tödliche Elektroschocks könnten ohne viel Aufwand Wirklichkeit werden. ... Fast alle untersuchten Geräte konnte er hacken. Entweder gab es keine Authentifizierung, oder die verlangten Passwörter waren Massenware wie "admin" oder "1234"
|
Das Problem ist seit längerem bekannt und auch in Deutschland akut, aber wie beim Online Banking spart man bei der Sicherheit auf Kosten der Patenten/Kunden. 
Kommentar von "NO ROM BASIC"@heise-forum
| Zitat: |
Die ganze Branche und die Aufsichtsbehörden betreiben viel Aufwand, um die Illusion von Sicherheit zu erzeugen, erreichen aber leider oft dass Gegenteil. Denn es geht bei der ganzen Sache für alle beteiligten wie gesagt primär darum, im Falle eines Falles nicht Schuld zu sein, da man alle Vorschriften eingehalten hat.
|
"Illusion von Sicherheit" - genau das haben wir.
|
|
| Nach oben |
|
|
|
FAQ 
Suchen 
Mitgliederliste 
Nutzungsbedingungen 
Benutzergruppen 
Links
Registrieren
Profil 
Einloggen, um private Nachrichten zu lesen 
Login 
