Frage:
Wie kann man Heartbleed ohne Fachbegriffe erklären?
user36976
2014-04-10 10:21:49 UTC
view on stackexchange narkive permalink

Most of my friends who are not experienced in computers want to know what Heartbleed is and how it works. How would one explain Heartbleed to someone without a technical background?

Mit Heartbleed kann ein Angreifer anonym einen zufälligen Speicherblock des Servers herunterladen. Dies bedeutet, dass sie unverschlüsselte Passwörter und Verschlüsselungsschlüssel auf niedriger Ebene erhalten können, die Ihr Konto schützen. Ganz zu schweigen davon, dass ein Angreifer möglicherweise auf einen beliebigen Teil der Website (oder auf Daten, die Sie auf dieser Website veröffentlichen) zugreifen kann.
Sie können sie https://www.youtube.com/watch?v=rE5dW3BTpn4 ansehen lassen
Die einfachste Art zu erklären: http://xkcd.com/1354/
Die Erklärung von Maciej Cegłowski im Pinboard-Blog hat mir gefallen: https://blog.pinboard.in/2014/04/heartbleed_and_pinboard/
Wie bei den letzten 50000 Windows-Angriffen mit ungeprüfter Pufferlänge beweist nur dies, dass es sich nicht nur um Windows handelt.
Ich habe einem anderen Studenten der Computertechnik den xkcd-Comic gezeigt, aber da er keine Kenntnisse über Verschlüsselungsschlüssel, https, ssl und Server hatte, hat der Comic wirklich nichts für ihn getan. Ich mag den ersten Kommentar, nur würde ich sagen: "Mit Heartbleed kann ein Benutzer Daten von allem abrufen, was der Server gerade tut, einschließlich Passwörtern, Verschlüsselungsschlüsseln und persönlichen Informationen, wodurch alle privaten Informationen gefährdet werden."
@JFA: Wie wäre es mit "OpenSSL enthält einen Befehl, der im Wesentlichen lautet:" Denken Sie an diese 23 Datenbytes. Sagen Sie, seien Sie die letzten 23 Datenbytes, über die Sie nachgedacht haben ", aber lassen Sie andere Zahlen 23 ersetzen. Eine typische HeartBleed-Angriffsnachricht würde" Hier sind 2 Bytes zum Nachdenken; Sagen Sie mir jetzt die letzten 65.000 Bytes, über die Sie nachgedacht haben. "
@supercat wie wäre es mit "Es ist ein Exploit, mit dem ein Angreifer private Informationen aus dem Speicher anfordern kann?"
http://upload.wikimedia.org/wikipedia/commons/thumb/c/cb/Heartbleed_bug_explained.svg/1000px-Heartbleed_bug_explained.svg.png
Keine einzige Antwort mit "Marco - Polo"? Abstimmung zum Schließen ...
Der Webserver ist wie ein vereister Teich. Ihre Daten sind die Fische, sie sind durch die feste Eisschicht geschützt. Aber jemand hat gerade die Eisbohrmaschine entdeckt und kann nun eine Schnur hineinwerfen und zufällige Sachen herausziehen. Wie vielleicht dein Passwort.
Elf antworten:
#1
+343
Uwe Keim
2014-04-11 11:48:39 UTC
view on stackexchange narkive permalink

Wie wäre es mit diesem von XKCD?

XKCD comics #1354 by Randall Munroe. Licenced CC BY-NC 2.5

Die "nicht-technischste" Erklärung I. gefunden.

Ich bin eine technische Person und auch eine visuelle Person. Ich kann sagen, dass dies die bisher beste Erklärung für Heartbleed ist: Prägnant und doch enthält es alles, was jeder wissen muss, um den Punkt zu verstehen.
#2
+164
SPRBRN
2014-04-10 17:17:36 UTC
view on stackexchange narkive permalink

The analogy of the bank and bank employee

You call the bank to request a new bank account, to make an appointment - whatever. Somehow you and the bank make sure that you are who you are, and the bank is actually the bank. This is the TLS process that secures the connection between you and the bank, and we assume this is handled properly.

The roles in this play

  • The bank: a webserver
  • The bank employee: the OpenSSL service for that server
  • You (the bank robber): a bot fetching all it can get from that server

Staying connected - the heartbeat

A bank employee answers your call. You request some information. The employee says to wait a minute and disables his microphone. He can hear you, you cannot hear him. Then it's quiet. For a long time. You start to wonder if he hung up. So you say "hello?" The employee is instructed to echo whatever you say, and replies with "hello". This is the heartbeat to check if there is still a connection.

Now with this peculiar bank employee, you need to say first how many words you are going to use before you ask if the employee is still online. So instead of saying "hello", you need to say "one: hello", or "two: hello there". The employee now knows he can reply with repeating those (first) two words, and then can continue to work on your request. This is the heartbeat protocol.

The problem - the heartbleed - no check on what is returned

OK, you're bored, and you make a joke. You say "thousand: hello". The employee doesn't check that you only said one word (hello), and starts to reply with "hello" plus then the next 999 words that he says, or thinks about, or has in memory, before putting the mic off. This is the bug that causes the problem.

Those 999 words are unrelated. Most of it will be useless, remarks about the weather, request for coffee, lunch appointments etc. Some of it can be important information about the bank or other customers. A transport of gold, a customer is going to bring in $1m, the code for entering the bank or the safe, etc.

There is no check if there are actually 1000 words to be replied. Plus you can do this request over and over again - the employee won't complain and nobody else is going to notice what is going on.

There is one limit. You will only get information from this one bank employee, and only the stuff he talks or thinks about. Other employees are not affected. You cannot see what is on his desk or in his rolodex. (Analogy: only data in memory (RAM) is at risk; data on the harddisk which is not read into memory, and data from other programs and processes is safe.)

Doing this you don't know what information you will get, but doing it for a long time over and over again, you will get enough information to finally be able to break in without anyone noticing it. You can enter the bank after hours, open the safe, etc. This is the risk involved.

The solution - check request and renew codes

If the employee would think for a moment he would only reply with one word and then disable the microphone so you cannot hear anymore what he is discussing. By making this check, you will stay connected and know that the employee has not hung up, but will not hear any random info anymore. In effect the employee needs new instructions on what to echo. This is fixed with the update to the latest version of OpenSSL.

The bank will have to renew security keys for entering the bank and safe, because it is unknown whether someone has the old codes.

Ich würde sagen, sogar ein Schulkind kann verstehen ... Verdammt, ich kann nur einmal abstimmen ...
Der wichtige Satz lautet: "Einige können Informationen über die Bank oder andere Kunden sein." Wenn dieser eine Mitarbeiter mehrere Aufgaben ausführt und Anfragen von mehreren Personen bearbeitet, teilt er Ihnen möglicherweise deren Daten und auf die gleiche Weise Ihre Daten mit. Leider haben Sie keine Ahnung, was er wem gesagt hat und wem er Ihre Daten gegeben haben könnte.
#3
+163
dr jimbob
2014-04-10 12:30:08 UTC
view on stackexchange narkive permalink

I'm going to have to use a few technical terms, but will try to keep them to a minimum and describe them.

Basic Intro to TLS & Encryption

You (a client) go to a website (known as a server) that uses encryption (the address starts with https://) to make it so no one but you and the website at the other end can know the content of the messages you are sending or receiving. So when your messages are transported across computers on the internet they are encrypted -- they call this transport layer security (TLS) and it is one type of encrypted protocol. One library that implements TLS is OpenSSL (TLS is the newer name for SSL, but both have the same intention -- encrypt network traffic on the internet).

What is Heartbeat - the compromised TLS feature?

To set up a TLS connection there's a negotiation that's relatively expensive (it takes time). Several messages have to be exchanged between the client and server before they can trust each other and safely send encrypted data back and forth. To have a quick and responsive experience (and minimize server load), you want to perform this negotiation rarely when possible, rather than do it before every single request (as you often will perform hundreds of requests in minutes with modern interactive websites). Complicating matters, packets on the internet often get lost or corrupted. The server may be overwhelmed with too many requests and need to drop its end of the TLS connection. Or the client may have closed its browser window, so the server has no need to continue storing its end of the encrypted connection.

So in 2012 a proposal was implemented in OpenSSL (called Heartbeats) to send "keep-alive" messages between client and server to reduce the number of negotiations, when both ends still are using the connection. The client asks the webserver periodically "Are you still there?" and the webserver (if it is still there), replies telling whether or not it is still there or whether future requests need a new TLS negotiation.

How the Heartbeat Extension works

The client sends a Heartbeat message consisting of a payload chosen by the client, as well as a brief header containing the size of the payload. E.g., you could send a Heartbeat request of size 18 and text This is my payload (though generally it will be randomly chosen data). The webserver gets that request, saves the content of the payload to the memory of the webserver, as well as the saving the size of the payload 18 that the client told it.

Then when the server sends a "keep-alive" response back to the client, the library reads those next 18 characters of memory starting from where it stored the payload and sends it back to the client (who checks that they received the right data back) and then the connection is kept alive.

The Heartbleed flaw in OpenSSL

The fatal flaw (that has been named Heartbleed) is that the OpenSSL library never checked that the Heartbeat payload size corresponds with the actual length of the payload being sent. A user is allowed to input any number up to 65535 (64 kilobytes) regardless of the true size of the payload. If an attacker sends a Heartbeat request saying the size is 65535, but a payload that's only 18 bytes long the vulnerable server will store only 18 bytes in memory. However, the response will start with those stored 18 bytes, but continue sending data from the next 64KB of memory back to the client. This data could be usernames and passwords, private keys, username, HTML pages, random junk, or even the private secret that the webserver uses to establish its identity. (The fix to OpenSSL implemented in 1.0.1g and later versions is essentially to perform sanity checks on the payload size as told by the client).

The attack can be repeated many times and in general will reveal different parts of the webserver's memory each time. The attack can be performed anonymously in an undetectable manner for typical webserver configurations. Typically, you only log IP addresses when you serve a web page, but this attack can happen early in the negotation process in vulnerable versions, before any webpage is served.

Attack on Clients

There is also a reverse version of this, where a user connecting to a malicious TLS server will trust the keep-alive request sent from a malicious server where the server lied about the size of its keep-alive payload. This would cause the web browser to leak up to 64KB of information to the webserver. (Granted this would be much harder to get usable information out of it and cannot be done anonymously and must be initiated by the client choosing to go to that webpage. However, it still makes sense to patch OpenSSL quickly if you browse the web with an affected version.)

Remedy

The remedy for clients and servers that use OpenSSL is to update it. System administrators running webservers that used the vulnerable OpenSSL library need to revoke their secret TLS keys and generate new ones (as well as invalidate long lived session tokens). Clients should change their passwords on affected websites, which may have been leaked. For clients, lastpass released a heartbleed checker tool that tests whether a site is (1) currently vulnerable, (2) previously tested to be vulnerable, or (3) likely vulnerable (using a unix/linux webserver and TLS, likely indicating use of OpenSSL which is primarly used on unix/linux systems) which may help determine whether you need to update your password at a given website.

SSH is not TLS so SSH keys are safe

SSH (which stands for Secure Shell) is a common tool on unix and linux machines, allowing users to remotely login to a machine and issue commands that are transported over the network encrypted. SSH is an entirely different protocol from TLS (the answer says SSL, but that's just the old name for TLS -- the terms are often used interchangeably). Even though OpenSSH (the most common implementation of SSH) and OpenSSL have similar names, your SSH keys are not vulnerable due to the Heartbleed attack.

Only memory from the process that is doing the TLS encryption can be leaked through the Heartbleed attack. (A process is the computing term for a running instance of an application.) Modern operating systems implement process isolation that prevent processes from reading or writing memory assigned to other processes on the same system. So contrary to xkcd.com/1353 you do not need to worry about all of your computer's memory being compromised, just the memory of the webserver process (or the webbrowser for the reverse form). Secrets like SSH keys used by other processes (ssh, sshd, ssh-agent) are not being leaked because you also used TLS in a webserver.

For completeness, I should mention that this vulnerability should affect anything that may use the OpenSSL library to perform TLS, which isn't limited to webservers; e.g., FTPS servers (but not SFTP), Email servers, Database servers all may be vulnerable depending on the configuration.

More info about the vulnerable commit

It's also worth noting that the same person who wrote the vulnerable code that doesn't verify the size of the payload was the same author of the Heartbeat extension to TLS (described in RFC 6520). Note the protocol did not specify a maximum size of Heartbeats response (while specifying a minimum size), but allowed it to be arbitrary length and let the payload size be described by a two byte header (allowing it to go up to 65535 instead of only 255 with a 1-byte header, which would have only exposed under 255 bytes of the webserver processes' RAM). I honestly can't think of any reasonable reason to require a heartbeats payload that's longer than 16 bytes (128-bit), and if you wanted to be super paranoid you could let it be 32 bytes (256-bit). With those limitations, it would be very unlikely to leak much usable information.

It's also curious that the vulnerable code is dated to the evening of New Years' Eve 2011, which seems like a likely time to pass something under the radar or with less scrutiny due to the holiday.

Vielen Dank für die hervorragende Erklärung und die Klarstellung, dass SSH nicht betroffen ist. Die Verschwörung am Ende - das i-Tüpfelchen!
"Dies würde dazu führen, dass der Webbrowser bis zu 64 KB an Informationen an den Webserver weiterleitet." Welche Informationen könnten das sein? Wäre es zum Beispiel zwischengespeicherte Informationen über Websites? Könnten es Daten sein, die von Add-Ons gespeichert werden, zum Beispiel Passwort-Manager wie Lastpass?
@Celeritas - Die Dinge, die ich erwarte (obwohl ein vernünftiger Passwort-Manager Passwörter nur bei Bedarf in den Speicher laden und sie schnell freigeben würde). Wenn Sie Ihre OpenSSL auf Ihrem System auf 1.0.1g gepatcht oder eine Version vor 1.0.1 verwendet haben, sind Sie vor diesem Angriff sicher. Wenn Sie Linux verwenden, mit Python vertraut sind und Root-Zugriff haben, können Sie den Inhalt des Speichers untersuchen. Suchen Sie einfach die PID Ihres Webbrowsers (z. B. mit oben) und verwenden Sie dann das [hier] angegebene python2-Skript (http://stackoverflow.com/a/23001686/457571). Denken Sie daran, dass der Client-Angriff nur zufällige Blöcke erhält .
Was ist der Zweck der Nutzlast?
Es ist fast ein Humerus, wie Lastpass 'Tool zur Überprüfung der Herzblutung Lastpass als möglicherweise gefährdet erkennt. Bedeutet das, dass jeder, der den letzten Pass verwendet hat, alle Passwörter ändern sollte?
-1: Dies ist eine * schreckliche * Antwort auf die angegebene Frage. Es besteht keine Chance, dass ein nicht technisch versierter Benutzer zuhört, geschweige denn 10% davon versteht.
@MichaelBorgwardt Wahrscheinlich wahr, aber für jemanden, der technisch ist, aber keine Ahnung von Web-Technologie hat, ist es ausgezeichnet
@MichaelBorgwardt - Ich habe versucht, eine gründliche Antwort zu geben, ohne nur auf Fachjargon oder dumme Analogien zurückzugreifen. Ich glaube, einige fanden es hilfreich. Es ist offensichtlich kein "Erklären Sie es, als wäre ich eine Fünf" oder erklären Sie es in weniger als einer Minute, aber nehmen Sie sich die Zeit, um verwandte Konzepte zu erklären, als wären Sie ein intelligenter Erwachsener, selbst wenn Sie kein Computer- / Sicherheitsexperte sind .
Vermutlich technische Begriffe in dieser Antwort, die vor der Verwendung nicht erklärt werden: Verschlüsselung, Bibliothek, SSL, Netzwerkverkehr, Serverlast, Nutzlastgröße usw., und das ist ungefähr ein Viertel der Erklärung, bevor mir langweilig wurde. Ich denke, die Leute hier vergessen, dass ein großer Teil der Bevölkerung nicht weiß, was ein "Browser" ist.
@drjimbob - Ihre Antwort hat bei mir funktioniert und mir geholfen, meine Antwort zu schreiben.
Ja, dies ist eine großartige Erklärung für Heartbleed, aber nicht für einen Laien.
@MichaelBorgwardt würde ich nicht sagen. Es hängt wirklich sehr von den Leuten ab, denen Sie das erklären. Überraschenderweise traf ich oft Leute ohne technischen Hintergrund, die solchen Erklärungen ohne oder mit nur geringen Schwierigkeiten folgten. Ich würde auch sagen, dass das Überprüfen der Festschreibungszeiten und das Bekanntmachen, wer den Fehler gemeldet und wer ihn codiert hat, wirklich nette Informationen sind.
Dies sollte die akzeptierte Antwort sein, sehr ausführlich und informativ ... Hölle, meine 11-jährige Tochter hat sie gelesen und verstanden, was er sagte ...
#4
+44
Mark
2014-04-10 13:39:05 UTC
view on stackexchange narkive permalink

Im Klartext: Der Angreifer sagt, dass er ein Paket der Größe "x" sendet, und fordert den Server auf, es zurückzusenden, sendet jedoch tatsächlich ein viel kleineres Paket. Die OpenSSL-Bibliothek vertraut dem Angreifer, sendet das kleine echte Paket als Start der Antwort zurück und holt dann Daten aus dem Speicher, um die Antwort auf die erwartete Größe auszufüllen. Dies können alle Daten sein, die der Server in letzter Zeit verarbeitet hat und die häufig vertrauliche Informationen enthalten.

In noch einfacheren Worten wird nicht vertrauenswürdige Eingabe als vertrauenswürdig akzeptiert.
@Elipticalview [Oh ja, "Little Bobby Tables", wir nennen ihn.] (Http://xkcd.com/327/)
#5
+23
Rich Bradshaw
2014-04-12 18:39:02 UTC
view on stackexchange narkive permalink

Dieser Beispieldialog - vielleicht sind Sie beide Zeichen oder Sie lassen sie die Fragen an Sie stellen:

Q1: Was ist Ihre Lieblingsfarbe (1 Wort)
A1: Blau

F2: Wo sind Sie zuletzt in den Urlaub gefahren (2 Wörter)
A2: Nach Frankreich

F3: Welches Auto fahren Sie (1000 Wörter)
> A3: Vauxhall Astra. Cheeseburger. Morgen fahre ich nach London. Ich mag Kuchen. Ohhh ein Eichhörnchen. Meine PIN ist 1234. Ich mag Hühner. SPAAAACEEEE. Letzte Nacht habe ich Spaghetti gegessen. BUD WEIS EEEEERRRR. etc etc etc

Dieser letzte Teil ist hauptsächlich Müll, aber es könnten ein paar gute Dinge drin sein.

Das war wirklich mein Gedankengang ... Sorgen machen oder was!
Sollte die dritte Frage eher Q3 als Q2 sein?
#6
+11
Bristol
2014-04-10 15:14:35 UTC
view on stackexchange narkive permalink

Hier ist ein Versuch, fast keinen Jargon zu verwenden.

Wenn Sie eine Verbindung zu einer "sicheren" Website herstellen (eine mit einem grünen Balken und einem Vorhängeschlosssymbol), führen Ihr Browser und die Website eine gewisse Leistung aus mathematischer Hokuspokus und Sie beide erhalten einen geheimen Schlüssel - wie ein sehr langes, zufälliges Passwort - mit dem Sie sich gegenseitig verschlüsselte Nachrichten senden können.

Wenn Sie auf der Website stöbern und auf Links klicken, klicken Sie darauf Es wäre sehr teuer, den gesamten Hokuspokus jedes Mal zu wiederholen, sodass die Website und der Browser nur eine Weile dieselbe Taste verwenden. Da die Website nicht eine Liste aller einzelnen Schlüssel führen möchte, die jeder einzelne Besucher jemals verwendet hat, wurde ein Protokoll namens Heartbeat erfunden. Solange Sie noch stöbern, sendet Ihr Browser der Website von Zeit zu Zeit eine Nachricht mit der Aufschrift HEARTBEAT, was bedeutet: "Ich bin immer noch hier, halten Sie meinen Schlüssel fest." Die Website antwortet etwas auf den Effekt von "Roger That". Wenn die Website für eine Weile keine HEARTBEATs von Ihnen hört, wird davon ausgegangen, dass Sie zu einer anderen Website gegangen sind, und Ihr Schlüssel wird weggeworfen, um Platz für neue zu schaffen.

Tatsächlich schlagen Herzschläge einen mehr Sache. Sie können einen beliebigen Text zusammen mit diesen senden, und die Website antwortet mit genau demselben Text. Warum es so gemacht wird, ist mir nicht ganz klar, ich nehme an, es ist so, dass Ihr Browser überprüfen kann, ob etwas Lustiges vor sich geht (wie der falsche Text, der zurückkommt, oder Texte, die in der falschen Reihenfolge zurückkommen) und Sie wissen lassen, dass es jemand kann Mach etwas Böses.

Also sendet dein Browser von Zeit zu Zeit eine Nachricht wie "HEARTBEAT, Text mit 5 Buchstaben, HALLO" und die Website antwortet "roger that, 5 Buchstaben, HALLO". Der Text kann so ziemlich alles sein, wie das aktuelle Datum und die aktuelle Uhrzeit. Sie können ein Gedicht senden, wenn Sie möchten.

Der Heartbleed-Fehler ist, dass wenn Sie eine Nachricht wie "HEARTBEAT, 1000 Buchstaben, KÄSE" senden, wenn die Website ein Programm namens OpenSSL verwendet, um die Verschlüsselung durchzuführen, dies schlecht läuft. Und OpenSSL ist das am häufigsten verwendete Programm zur Verschlüsselung im Internet. Was es tun sollte, ist zu beachten, dass KÄSE 6 Buchstaben hat, nicht 1000, und sich zu beschweren. Stattdessen liest es Ihre Nachricht und schreibt sie an eine Stelle in seinem Speicher. Dann antwortet es "Roger That, 1000 Buchstaben, ..." und beginnt, die nächsten 1000 Buchstaben aus seinem Speicher vorzulesen, beginnend an der Stelle, an der es Ihren KÄSE gespeichert hat. Sie können also hören, was auch immer die nächsten 994 Buchstaben in seinem Speicher sind, und dies könnte buchstäblich alles sein. Es könnten die geheimen Schlüssel der Website sein. Es könnte ein Gedicht sein. Dies können Passwörter und Kreditkartendaten anderer Kunden sein. Es könnte ein Bild einer Katze sein. Es ist völlig zufällig, aber jedes Mal, wenn Sie eine HEARTBEAT-Nachricht wie diese senden, sehen Sie einen anderen zufälligen Teil des Speichers der Website. Wenn Sie also Ihre HEARTBEATs nur oft genug wiederholen, werden Sie wahrscheinlich früher oder später auf etwas Interessantes stoßen.

Das Schlimmste, was passieren kann, ist, dass Sie die Hauptschlüssel der Website zurückerhalten, die verwendet werden, um den Hokuspokus zu starten, wenn ein neuer Besucher auf die Website kommt. Wenn Sie dies tun, können Sie theoretisch alles lesen, was jeder auf der Site tut, als ob es überhaupt keine Verschlüsselung gäbe. Immer wenn sich jemand anmeldet, wird das Passwort im Klartext angezeigt. Das ist keine schöne Sache.

Wenn ein Angreifer die "Hauptschlüssel" vom Webserver stiehlt, muss er entweder a) den gesamten Datenverkehr zum und vom Webserver erfassen oder b) einen Man-in-the-Middle-Angriff einrichten, der den gesamten Datenverkehr an ihn weiterleitet stattdessen einen eigenen "Proxy" -Server, um alles lesen zu können, was jeder auf der Site tut. Es wird weiterhin eine Verschlüsselung vom Endbenutzer zum Webserver (m-i-t-m oder real) geben, und die Kommunikation des Benutzers ist vor allen Personen sicher, mit Ausnahme des Angreifers, der die "Hauptschlüssel" gestohlen hat.
Das stimmt (und obwohl ich es im Text nicht erwähnt habe, +1 Grund, auch das perfekte Vorwärtsgeheimnis anzuwenden). Für die in der ursprünglichen Frage erwähnte Zielgruppe müsste ich mir überlegen, wie ich Mitm-Angriffe in diesem Zusammenhang erklären kann.
Warum es so gemacht wird, ist, dass Sie einen klaren Hinweis darauf haben, dass sie Ihren Herzschlag bestätigt haben. Sie haben ihnen eine einzigartige Nutzlast gegeben, die sie Ihnen zurückgeben, aber von keiner anderen Quelle gewusst hätten, und Sie können mit Sicherheit sagen, dass die Verbindung noch besteht.
@MattBianco Es sei denn, sie haben tatsächlich den Klartext-Root-Benutzernamen und das Kennwort gestohlen. In diesem Fall müssen sie nur ssh und der Server gehört ihnen.
@corsiKa, Wie würden sie das Root-Passwort stehlen? Und warum sollte sich root überhaupt mit ssh und mit Passwortauthentifizierung anmelden können? Das ist einfach nur dumm!
@MattBianco Wenn sich jemals jemand am Computer angemeldet hat, besteht die Möglichkeit, dass sich sein Kennwort noch im Speicher befindet (auch wenn es "frei" war). Wenn also ein Administrator als "[email protected]" eingetragen und dann seine Berechtigungen erhöht hat (zum Beispiel "su erhöht") Die Passwörter für "geheimes Konto" und "erhöht" werden wahrscheinlich gespeichert. (Ja, wir sollten Passwörter immer manuell löschen, bevor wir die Daten freigeben. Da sie jedoch irgendwann im Speicher vorhanden sein müssen, müssen sie irgendwann zugänglich sein.)
@corsiKa, Ich kaufe nicht die Möglichkeit, dass die Klartextkennwörter der Prozesse "sshd" oder "login" für den Webserverprozess erreichbar sind. Ich glaube, das würde auch ein gehirngeschädigtes Betriebssystem erfordern.
#7
+4
pyramids
2014-04-10 21:19:42 UTC
view on stackexchange narkive permalink

I'll use one two three technical terms, "heartbeat," "bug," and "webserver." I hope that won't scare off your non-technical friends.

When computers exchange data over the internet, sometimes it is useful to know if the other one is still listening. In many places, there are provisions to do the equivalent of asking "Hey, are you listening? Can you tell me what I just said?" In different contexts, there are many different names for such techniques that sometimes even turn up in mainstream media---"echo" is one, "ping" another, and the one that has a serious bug in a very widely used piece of software is "heartbeat." This particular "heartbeat" scheme is not actually used in many applications, but because the general idea can be so useful, many computers allow it.

The problem is that one piece of software most webservers use has a bug: Depending on just how the "What did I just tell you?" is asked, it can be tricked into trying to repeat more than what the other side had actually sent, filling in the rest with random things the webserver happens to know. By asking in such a tricky way, one can get webservers with this bug to tell almost anything they know about, including user passwords and (from webservers that handle such information) sensitive data like credit card numbers, email contents, etc. And it doesn't stop there, even the secrets with which other computers could impersonate these webservers are at risk.

This is not limited to webservers, but that's where anyone using the internet comes into contact with it. But computer security people have their hands full now with lots of computers and lots of different software that may be affected.

Das ist ziemlich gut, aber ich würde sagen: "Bei der Beantwortung der Frage" Was sind die letzten tausend Dinge, die ich dir gerade gesagt habe? " Nachdem es nur eine Sache erzählt hat, antwortet es achtlos mit dieser einen Sache plus 999 anderen zufälligen Dingen, über die es nachgedacht hat. '
Sicher. Das Problem ist, wenn ich versuche, all diese Details einzubeziehen, bevor ich es weiß, würde ich versuchen, Bits und Bytes und die hexadezimale Zählung zu erklären (warum 999? Warum nicht 0xFFFF?) ...
Richtig, aber ohne eine ungültige Längenanforderung zu beschreiben, scheint es, als ob jeder unschuldige Herzschlag Daten verliert, anstatt nur die böswilligen. Das scheint ein großer Unterschied zu sein, der aber nicht zu technisch ist. (Lassen Sie die spezifischen Zahlen weg, wenn Sie möchten.)
@AShelly Ich habe die Antwort bearbeitet, um zu zeigen, dass nicht bei jedem Herzschlag Daten verloren gehen, obwohl immer noch nicht über Zahlen gesprochen wird. Natürlich frage ich mich jetzt, ob Ihr ursprünglicher Vorschlag doch besser war!
#8
+3
user44002
2014-04-10 11:45:46 UTC
view on stackexchange narkive permalink

Wenn Sie eine Webseite besuchen, die "https" verwendet, wird die Verbindung zwischen Ihnen und dem Webserver verschlüsselt. Diese Schutzschicht wird als SSL oder TLS bezeichnet. Eine zugrunde liegende Komponente dieser Implementierung weist ein Sicherheitsproblem auf, das dazu führt, dass der Server, der eine Webseite bedient, "Daten verliert" (d. H. Speicherinhalte an einen Angreifer weitergibt). Es gibt einige Einschränkungen hinsichtlich des Verlusts dieser Daten, diese sind jedoch sehr schwerwiegend und können alle Arten von Daten auf dem anfälligen Server offenlegen.

Hier ist ein technisches Video, das ein Beispiel für einen Datenverlust von a zeigt Anfälliger Server und zeigt auch, wie verhindert werden kann, dass Daten verloren gehen: https://www.youtube.com/watch?v=UjkK22VBzjA

#9
+3
Nzall
2014-04-10 14:26:36 UTC
view on stackexchange narkive permalink

New analogy:

Imagine you're calling the bank to ask if one of its offices is open. You get a machine on the line (the infamous "for English, press 1" lady) and it asks you how many banks you want to know the hours for, and which banks. You then say you want the hours for 65,000 banks, but only give it the code for a single bank. The machine thinks that it needs to give the hours for 65,000 banks, but since you only give 1 bank code, it fills the rest with whatever it can find: bank statements from random accounts, credit card numbers and codes, a picture of the key for the safe, the discussion the manager has at the time with his doctor,... It doesn't realize that that other data is irrelevant, and that you should have only gotten opening hours for 1 bank.


Old answer:

Imagine your bank has a system where you can send a secure request for the current pincode of your debit card, and the system returns a pincode and a bank card number. This system gets an update where you can send a list of cards to reset.

You send a request for a list of 65,535 debit cards to reset, but only pass 1 card number. Instead of returning just that single card or throwing an error, your bank sends back the existing codes for 65,534 other cards from other random users.

Wenn Sie abstimmen, erklären Sie zumindest, warum, damit ich es bei Bedarf bearbeiten kann. Ich persönlich halte dies für ein ähnliches Konzept: Sie senden eine fehlerhafte Anfrage an den Server, und der Server sendet Daten zurück, die er nicht zurücksenden sollte.
Nicht meine Ablehnung, aber Ihre Antwort kommt der Erklärung, was passiert, nicht nahe. Vielleicht funktioniert diese Antwort für Ihre Großmutter, aber dies ist ein anderes Publikum, auch wenn eine nicht technische Antwort angefordert wird.
Die Frage ist "Ich möchte meinen Nicht-Technikfreunden erklären, was Heartbleed ist". Das OP möchte eine nicht-technische Erklärung für Menschen, die nicht gut mit Computern umgehen können. In diesem Fall kommen Sie nicht so weit, wenn Sie nur das Konzept erklären. Du brauchst eine Analogie. Und eine der besten Analogien, die ich mit derselben Skala und demselben Risiko für betroffene Benutzer erstellen könnte, ist die Verwendung von Bankkontodaten. Mir ist klar, dass es für das normale Publikum absolut unzureichend ist, aber ich glaube, es ist weitaus besser für jemanden geeignet, der nicht weiß, was SSL, ein Herzschlag oder eine Erinnerung ist.
OK, lies Jimbobs Antwort. Dann reparieren Sie Ihre. Angenommen, die Anfrage wird von einer Person und nicht von einem Computer bearbeitet. Der Bankangestellte, der dies erledigt, sendet nicht die Codes dieser 64.000 Karten, sondern alles, was er verarbeitet, wie eine Notiz des Managers, ein Telefongespräch, einen Witz usw. (aber nur für diese 64.000). Alles, was von dieser Person gehandhabt wird. Wenn Sie dies immer und immer wieder tun, können Sie sich ein Bild davon machen, was vor sich geht und wie die Verfahren funktionieren, welche Sicherheitsverfahren besonders, und von da an können Sie sich selbst als Bankangestellter ausgeben.
Ein weiteres Problem in Ihrem Beispiel ist, dass es sich um eine tatsächliche Anfrage handelt, während der Herzschlag nur ein Anruf bei der Bank ist, um festzustellen, ob diese geöffnet ist.
@rxt Ich habe einen weiteren Vergleich durchgeführt, der in diesem Fall genauer sein könnte.
#10
+2
Kiwy
2014-04-10 15:19:19 UTC
view on stackexchange narkive permalink

Imagine a book you never read and then you don't know the content because the book is closed, the heartbleed bug, is just a way to open a page randomly and being able to read the text, from the book. after extracting enought information you're able to replicate the book and replace it on a shelter without anybody being able to notice.The book being either your computer or your server.

That would be the most simple explanation I would give to non technical persons.


If you want a more precise version, let say you have a book closed with an electronic lock that book is your personal diary. You're the only one that have the key, so you're the only one to be able to both read and write it.
Too bad you electronic lock is defective and allow someone who know the trick to unlock it for 2 seconds.
By doing that more and more you will be able to read the whole content and eventually to modify it afterward.
#11
+1
Lightness Races in Orbit
2014-04-14 00:21:35 UTC
view on stackexchange narkive permalink

Es ist so.

Sie gehen die Straße entlang und begegnen beim Eingang einer Bank einem autistischen Gelehrten auf dem Weg nach draußen. Er scheint ein netter Kerl zu sein, aber Sie sind es nicht, und Sie wissen, dass Sie ihn für schändliche Zwecke verwenden können, weil Sie genug Filme gesehen haben, um zu erfahren, dass Savants erstaunliche Datenmengen behalten und wiederholen können und im Allgemeinen ziemlich aufmerksam sind. auch.

Also fragst du ihn nach der Zeit. Er sagt dir die Zeit, kann aber nicht anders, als weiter zu reden. Er teilt Ihnen jede Bankkontonummer und jedes Passwort mit, die ihm während seines Aufenthalts an Augen und Ohren vorbeigegangen sind.

Diese Informationen gehören jetzt Ihnen. Alles, was Sie tun mussten, war nach der Zeit zu fragen, da der Gelehrte aufgrund seines Zustands nicht in der Lage war, sich davon abzuhalten, Ihnen mehr zu erzählen, als er eigentlich sollte. Was er nicht merkt, ist, dass Sie, indem Sie nach der Zeit mit Ihren schändlichen Absichten fragten, da Sie wussten, was wahrscheinlich passieren würde, mehr verlangten, als Sie eigentlich sollten

Armer Kerl.

-1 Erklärt nicht, wie die Informationen abgerufen werden
@Nick: Es ist eine Analogie. Ohne technische Details. Wie gewünscht. Wenn Sie die technischen Details wünschen, sind sie im gesamten Internet verfügbar.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...