How about this one from XKCD?

The most "non-technical" explanation I found.

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.

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.

To przykładowe okno dialogowe - być może oboje jesteście postaciami lub sprawiacie, że zadają wam pytania:

P1: Jaki jest twój ulubiony kolor (1 słowo)
A1: Niebieski

P2: Gdzie ostatnio byłeś na wakacjach (2 słowa)
A2: Do Francji

Q3: Jakim samochodem jeździsz (1000 słów)
A3: Opel Astra. Cheeseburger. Jutro jadę do Londynu. Lubię ciasto. Och, wiewiórka. Mój kod PIN to 1234. Lubię kurczaki. SPAAAACEEEE. Ostatniej nocy zjadłem spaghetti. BUD WEIS EEEEERRRR. etc etc etc etc

Ten ostatni kawałek to głównie śmieci, ale może być w nim kilka dobrych rzeczy.

Here's an attempt to use almost no jargon at all.

When you connect to a "secure" website (one with a green bar and padlock icon), your browser and the website perform a bit of mathematical hocus-pocus and you both end up with a secret key - like a very long, random password - with which you can send each other encrypted messages.

As you browse around the site and click links, it would be very expensive to redo the whole hocus-pocus each time so the website and browser just carry on using the same key for a while. Since the website doesn't want to keep a list of every single key that every single visitor has ever used, a protocol called heartbeat was invented. As long as you're still browsing around, every now and then your browser will send the website a message saying HEARTBEAT, which means "I'm still here, keep hold of my key". The website replies something to the effect of "roger that". If the website doesn't hear any HEARTBEATs from you for a while, it presumes you've gone on to some other site and throws away your key to make space for new ones.

Actually, heartbeats do one more thing. You can send any text you like along with them and the website will reply with exactly the same text. Why it's done this way is not quite clear to me, I suppose it's so that your browser can check if something funny's going on (like the wrong text coming back, or texts coming back in the wrong order) and let you know that someone may be doing something nasty.

So your browser every now and then sends a message like "HEARTBEAT, text with 5 letters, HELLO" and the website replies "roger that, 5 letters, HELLO". The text can be pretty much anything, like the current date and time. You could send a poem if you want to.

The heartbleed bug is that if you send a message like "HEARTBEAT, 1000 letters, CHEESE" then if the website is using a program called OpenSSL to do the encryption it goes badly wrong. And OpenSSL is kind of the most common program used to do encryption on the internet. What it should do is notice that CHEESE has 6 letters, not 1000, and complain. Instead, it reads your message and writes it to somewhere in its memory. Then, it replies "roger that, 1000 letters, ..." and starts reading out the next 1000 letters from its memory starting at wherever it stored your CHEESE. So you get to hear whatever the next 994 letters in its memory are, and this could be literally anything. It could be the website's secret keys. It could be a poem. It could be other customers' passwords and credit card details. It could be a picture of a cat. It's completely random but every time you send a HEARTBEAT message like this, you get to see a different random portion of the website's memory so if you just repeat your HEARTBEATs often enough, you're quite likely to hit something interesting sooner or later.

The worst that can happen is that you get back the website's master keys, the ones used to start off the hocus-pocus whenever a new visitor comes to the site. If you do this, you can in theory read everything that everyone is doing on the site, as if there were no encryption at all. Whenever someone logs in, you'd get to see their password in the clear. That's not a nice thing to happen.

Użyję jednego dwóch trzech terminów technicznych: „puls”, „błąd” i „serwer sieciowy”. Mam nadzieję, że to nie odstraszy twoich nietechnicznych przyjaciół.

Kiedy komputery wymieniają dane przez Internet, czasami warto wiedzieć, czy drugi nadal nasłuchuje. W wielu miejscach istnieją przepisy, które odpowiadają zapytaniu „Hej, słuchasz? Czy możesz mi powiedzieć, co właśnie powiedziałem?” W różnych kontekstach istnieje wiele różnych nazw takich technik, które czasami pojawiają się nawet w mediach głównego nurtu - „echo” to jedno, „ping” innym i to, które ma poważny błąd w bardzo szeroko używanym oprogramowaniu to „bicie serca”. Ten konkretny schemat „bicia serca” nie jest w rzeczywistości używany w wielu aplikacjach, ale ponieważ ogólny pomysł może być tak przydatny, wiele komputerów na to pozwala.

Problem polega na tym, że jeden element oprogramowania używany przez większość serwerów WWW ma błąd : W zależności od tego, jak "Co ci właśnie powiedziałem?" można go oszukać, próbując powtórzyć więcej niż to, co wysłała druga strona, wypełniając resztę przypadkowymi informacjami, o których zdarzyło się wiedzieć serwer sieciowy. Pytając w tak podstępny sposób, można nakłonić serwery internetowe z tym błędem, aby powiedziały prawie wszystko, o czym wiedzą, w tym hasła użytkowników i (z serwerów internetowych, które obsługują takie informacje) poufne dane, takie jak numery kart kredytowych, zawartość e-maili itp. Nie poprzestaj na tym, nawet sekrety, którymi inne komputery mogłyby podszywać się pod te serwery, są zagrożone.

Nie ogranicza się to do serwerów sieciowych, ale styka się z nim każdy, kto korzysta z internetu. Ale ludzie zajmujący się bezpieczeństwem komputerowym mają teraz pełne ręce roboty, mając wiele komputerów i wiele różnych programów, na które może to wpłynąć.

Podczas odwiedzania strony internetowej używającej protokołu „https” połączenie między Tobą a serwerem internetowym jest szyfrowane. Ta warstwa ochronna nosi nazwę SSL lub TLS. Podstawowy składnik tej implementacji ma z tym problem z bezpieczeństwem - powodując, że serwer obsługujący stronę internetową „wycieka dane” (tj. Ujawnia zawartość pamięci atakującemu). Istnieją pewne ograniczenia dotyczące sposobu, w jaki te dane wyciekają, ale jest to bardzo poważne i może ujawnić wszelkiego rodzaju dane na serwerze z lukami w zabezpieczeniach.

Oto techniczne wideo, które pokazuje przykład wycieku danych z serwera wrażliwy serwer, a także pokazuje, jak zapobiec wyciekowi danych: https://www.youtube.com/watch?v=UjkK22VBzjA

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.

Wyobraź sobie książkę, której nigdy nie czytałeś, a potem nie znasz jej treści, ponieważ książka jest zamknięta, krwawy błąd, to tylko sposób na przypadkowe otwarcie strony i możliwość przeczytania tekstu z książki. po wydobyciu wystarczającej ilości informacji jesteś w stanie powielić książkę i umieścić ją w schronisku bez nikogo, kto by tego zauważył. Książka jest albo twoim komputerem, albo serwerem.

To byłoby najprostsze wyjaśnienie, jakie dałbym osobom nietechnicznym.

It's like this.

You're walking along the street and, passing the entrance to a bank, you encounter an autistic savant on his way out. He seems like a nice guy, but you're not, and you know you can use him for nefarious purposes, because you've watched enough movies to have learnt that savants can retain and repeat amazing amounts of data and are generally pretty observant, too.

So, you ask him for the time. He tells you the time, but can't help but keep talking. He tells you every bank account number and password that went past his eyes and ears whilst he was in there.

That information is now yours. All you had to do was ask for the time because, by virtue of his condition, the savant was unable to stop himself from telling you more than he was supposed to. What he doesn't realise is that, by asking for the time with your nefarious purposes, since you knew what was likely to happen, you asked for more than you were supposed to as well.

Poor chap.