La maggior parte dei miei amici che non hanno esperienza con i computer vogliono sapere cos'è Heartbleed e come funziona. Come si spiegherebbe Heartbleed a qualcuno senza un background tecnico?
La maggior parte dei miei amici che non hanno esperienza con i computer vogliono sapere cos'è Heartbleed e come funziona. Come si spiegherebbe Heartbleed a qualcuno senza un background tecnico?
Che ne dici di questo da XKCD?
La spiegazione più "non tecnica" che ho trovato.
L'analogia tra banca e impiegato di banca
Chiami la banca per richiedere un nuovo conto bancario, per fissare un appuntamento - qualunque cosa. In qualche modo tu e la banca vi assicurate di essere chi siete, e la banca è effettivamente la banca. Questo è il processo TLS che protegge la connessione tra te e la banca e presumiamo che sia gestito correttamente.
I ruoli in questa commedia
Rimanere connesso: il battito cardiaco
Un impiegato di banca risponde alla tua chiamata. Richiedi alcune informazioni. L'impiegato dice di aspettare un minuto e disattiva il suo microfono. Lui può sentirti, tu non puoi sentirlo. Allora è tranquillo. Per molto tempo. Inizi a chiederti se ha riattaccato. Quindi dici "ciao?" Il dipendente viene istruito a fare eco a qualsiasi cosa tu dica e risponde con "ciao". Questo è il battito cardiaco per verificare se c'è ancora una connessione.
Ora con questo strano impiegato di banca, devi prima dire quante parole utilizzerai prima di chiedere se il dipendente è ancora online. Quindi, invece di dire "ciao", devi dire "uno: ciao" o "due: ciao". Il dipendente ora sa che può rispondere ripetendo quelle (prime) due parole, e poi può continuare a lavorare sulla tua richiesta. Questo è il protocollo heartbeat.
Il problema - il cuore sanguinante - nessun controllo su ciò che viene restituito
OK, sei annoiato e fai una battuta. Dici "mille: ciao". Il dipendente non controlla che tu abbia detto solo una parola (ciao) e inizia a rispondere con "ciao" più le successive 999 parole che dice, o pensa, o ha in memoria, prima di spegnere il microfono. Questo è il bug che causa il problema.
Queste 999 parole non sono correlate. La maggior parte sarà inutile, osservazioni sul tempo, richiesta di caffè, appuntamenti per il pranzo, ecc. Alcune possono essere informazioni importanti sulla banca o altri clienti. Un trasporto d'oro, un cliente porterà 1 milione di dollari, il codice per entrare in banca o in cassaforte, ecc.
Non c'è controllo se ci sono effettivamente 1000 parole da rispondere. Inoltre puoi fare questa richiesta più e più volte: il dipendente non si lamenterà e nessun altro noterà cosa sta succedendo.
C'è un limite. Otterrai informazioni solo da questo impiegato di banca e solo le cose a cui parla o pensa. Gli altri dipendenti non sono interessati. Non puoi vedere cosa c'è sulla sua scrivania o nel suo rolodex. (Analogia: solo i dati in memoria (RAM) sono a rischio; i dati sul disco rigido che non vengono letti in memoria e i dati di altri programmi e processi sono al sicuro.)
In questo modo non lo sai quali informazioni otterrai, ma facendolo per molto tempo più e più volte, otterrai abbastanza informazioni per poter finalmente entrare senza che nessuno se ne accorga. Puoi entrare in banca fuori orario, aprire la cassaforte, ecc. Questo è il rischio.
La soluzione: controllare la richiesta e rinnovare i codici
Se il dipendente pensasse un momento risponderebbe solo con una parola e poi disabiliterebbe il microfono in modo non puoi più sentire di cosa sta discutendo. Effettuando questo controllo, rimarrai connesso e saprai che il dipendente non ha riattaccato, ma non sentirà più alcuna informazione casuale. In effetti, il dipendente ha bisogno di nuove istruzioni su cosa fare eco. Questo problema viene risolto con l'aggiornamento all'ultima versione di OpenSSL.
La banca dovrà rinnovare le chiavi di sicurezza per entrare in banca e in cassaforte, perché non è noto se qualcuno abbia i vecchi codici.
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.
In really plain English: the attacker says they're sending a packet of size "x" and asks the server to send it back, but actually sends a much smaller packet. The OpenSSL library trusts the attacker, sends back the small real packet as the start of the reply, and then grabs data from memory to fill out the reply to the expected size. This could be any data the server has handled recently, and often contains sensitive information.
This example dialog - perhaps you are both characters, or you get them to ask the questions of you:
Q1: What's your favourite colour (1 word)
A1: BlueQ2: Where did you last go on holiday (2 words)
A2: To FranceQ3: What car do you drive (1000 words)
A3: Vauxhall Astra. Cheeseburger. Tomorrow I'm driving to London. I like cake. Ohhh a squirrel. My PIN is 1234. I like chickens. SPAAAACEEEE. Last night I ate spaghetti. BUD WEIS EEEEERRRR. etc etc etc
That last chunk is mainly garbage, but there might be a few good things in there.
Questo è un tentativo di usare quasi nessun gergo.
Quando ti connetti a un sito web "sicuro" (uno con una barra verde e l'icona di un lucchetto), il tuo browser e il sito web eseguono un po 'di hocus-pocus matematici e vi ritroverete entrambi con una chiave segreta, come una password casuale molto lunga, con la quale potete inviarvi reciprocamente messaggi crittografati.
Mentre navighi nel sito e fai clic sui collegamenti, Sarebbe molto costoso rifare l'intero hocus-pocus ogni volta, quindi il sito Web e il browser continuano a utilizzare la stessa chiave per un po '. Dal momento che il sito web non vuole mantenere un elenco di ogni singola chiave che ogni singolo visitatore ha mai utilizzato, è stato inventato un protocollo chiamato heartbeat. Finché stai ancora navigando in giro, di tanto in tanto il tuo browser invierà al sito un messaggio che dice HEARTBEAT, che significa "Sono ancora qui, tieni la mia chiave". Il sito risponde qualcosa all'effetto di "roger that". Se il sito web non sente alcun HEARTBEAT da te per un po ', presume che tu sia andato su un altro sito e butti via la tua chiave per fare spazio a nuovi.
In realtà, i heartbeat ne fanno uno più cosa. Puoi inviare qualsiasi testo che ti piace insieme a loro e il sito web risponderà esattamente con lo stesso testo. Il motivo per cui è fatto in questo modo non mi è del tutto chiaro, suppongo che sia così che il tuo browser possa controllare se sta succedendo qualcosa di divertente (come il testo sbagliato che ritorna o i testi che tornano nell'ordine sbagliato) e farti sapere che qualcuno potrebbe sta facendo qualcosa di brutto.
Quindi il tuo browser ogni tanto invia un messaggio come "HEARTBEAT, testo con 5 lettere, CIAO" e il sito risponde "roger quello, 5 lettere, CIAO". Il testo può essere praticamente qualsiasi cosa, come la data e l'ora correnti. Puoi inviare una poesia se vuoi.
Il bug del cuore è che se invii un messaggio come "HEARTBEAT, 1000 letters, CHEESE", se il sito web utilizza un programma chiamato OpenSSL per eseguire la crittografia, va male. E OpenSSL è una specie di programma più comune utilizzato per eseguire la crittografia su Internet. Quello che dovrebbe fare è notare che CHEESE ha 6 lettere, non 1000, e lamentarsi. Invece, legge il tuo messaggio e lo scrive da qualche parte nella sua memoria. Quindi, risponde "Roger che, 1000 lettere, ..." e inizia a leggere le successive 1000 lettere dalla sua memoria a partire da dove ha memorizzato il tuo FORMAGGIO. Quindi puoi sentire qualunque siano le successive 994 lettere nella sua memoria, e questo potrebbe essere letteralmente qualsiasi cosa. Potrebbero essere le chiavi segrete del sito web. Potrebbe essere una poesia. Potrebbero essere le password di altri clienti e i dettagli della carta di credito. Potrebbe essere la foto di un gatto. È completamente casuale, ma ogni volta che invii un messaggio HEARTBEAT come questo, puoi vedere una porzione casuale diversa della memoria del sito Web, quindi se ripeti i tuoi HEARTBEAT abbastanza spesso, è molto probabile che prima o poi raggiungerai qualcosa di interessante.
La cosa peggiore che può accadere è che tu recuperi le chiavi principali del sito web, quelle utilizzate per avviare l'hocus-pocus ogni volta che un nuovo visitatore arriva sul sito. Se lo fai, in teoria puoi leggere tutto ciò che tutti stanno facendo sul sito, come se non ci fosse affatto la crittografia. Ogni volta che qualcuno accede, vedrai la sua password in chiaro. Non è una cosa carina che accada.
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.
When you visit a webpage which uses "https", the connection between you and the webserver is encrypted. This protective layer is called SSL or TLS. An underlying component of this implementation has a security-problem with it - causing the server which serves a webpage to "leak data" (i.e. disclose memory contents to an attacker). There are some constraints on how this data is leaked, but it is very serious and could expose all kinds of data on the vulnerable server.
Here is a technical video which shows an example of data-leakage from a vulnerable server and also shows how to prevent data from being leaked:https://www.youtube.com/watch?v=UjkK22VBzjA
Nuova analogia:
Immagina di chiamare la banca per chiedere se uno dei suoi uffici è aperto. Hai una macchinetta sulla linea (la famigerata "per l'inglese, premi 1" signora) e ti chiede per quante banche vuoi conoscere gli orari e per quali banche. Quindi dici che vuoi le ore per 65.000 banche, ma dai solo il codice per una singola banca. La macchina pensa di dover dare le ore per 65.000 banche, ma dato che dai solo 1 codice banca, riempie il resto con tutto ciò che riesce a trovare: estratti conto da conti casuali, numeri e codici di carte di credito, un'immagine della chiave per la cassaforte, la discussione che il gestore ha in quel momento con il suo medico, ... Non si rende conto che gli altri dati sono irrilevanti e che dovresti avere solo gli orari di apertura di 1 banca.
Vecchia risposta:
Immagina che la tua banca abbia un sistema in cui puoi inviare una richiesta sicura per il codice PIN corrente della tua carta di debito e che il sistema restituisca un codice PIN e un numero di carta bancaria. Questo sistema riceve un aggiornamento in cui puoi inviare un elenco di carte da reimpostare.
Invii una richiesta per un elenco di 65.535 carte di debito da reimpostare, ma passi solo 1 numero di carta. Invece di restituire solo quella singola carta o restituire un errore, la tua banca restituisce i codici esistenti per altre 65.534 carte da altri utenti casuali.
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.
È così.
Stai camminando per strada e, oltrepassando l'ingresso di una banca, incontri un sapiente autistico che sta uscendo. Sembra un bravo ragazzo, ma non lo sei, e sai che puoi usarlo per scopi nefasti, perché hai visto abbastanza film per aver imparato che i savant possono conservare e ripetere quantità incredibili di dati e sono generalmente piuttosto attenti, anche.
Quindi gli chiedi l'ora. Ti dice l'ora, ma non può fare a meno di continuare a parlare. Ti dice ogni numero di conto bancario e password che gli sono passati davanti agli occhi e alle orecchie mentre era lì.
Quelle informazioni ora sono tue. Tutto quello che dovevi fare era chiedere il tempo perché, in virtù delle sue condizioni, il sapiente non poteva trattenersi dal dirti più di quanto avrebbe dovuto . Quello di cui non si rende conto è che, chiedendo tempo con i tuoi propositi nefasti, dato che sapevi cosa sarebbe potuto succedere, hai chiesto anche più di quanto avresti dovuto .
Povero ragazzo.