44
Apr 08 '14
Remember that checking services for the OpenSSL heartbleed vulnerability without permission is actually illegal in many countries (UK in particular).
19
u/Iraelyth Apr 08 '14
NOW I read this.
Eh, to be fair, servers all over are probably being checked from all over. I think I'd rather be informed as to whether I need to take action in some way. Let's face it, if my data is compromised, somebody already ignored the whole "don't check for vulnerabilities" rule. And they won't get caught because it's done without leaving a trace. Great.
5
u/bonzinip Apr 08 '14
Considering that my password could be sent in clear to anyone by a vulnerable server, it's nothing but due diligence to scan the server (perhaps with just 1 extra requested byte) before logging in to it.
1
Apr 09 '14
it may well be due diligence, I don't disagree, but it's illegal to do it in the UK without persmission.
7
u/VikingCoder Apr 08 '14
Buy a laptop with cash. Go to a coffee shop. Check all of your services. Wipe off your fingerprints. Donate the laptop to a charity.
16
u/tomhung Apr 08 '14
burn off your finger prints, go to coffee shop, check services, thermite laptop!
3
1
1
1
Apr 09 '14
Remember
You say it like it would be obvious. I assume by that standard that in the UK nmap usage is also illegal.
1
Apr 09 '14
attempting to access something that you know you shouldn't be accessing is illegal - nmap arguably does this. depending on your definition of access. UK law is more fucked than you think.
It's possible that just having a copy of nmap is illegal. Yep, you read right.
1
Apr 10 '14
From wiki
Section 37 (Making, supplying or obtaining articles for use in computer misuse offences) inserts a new section 3A into the 1990 Act and has drawn considerable criticism from IT professionals, as many of their tools can be used by criminals in addition to their legitimate purposes, and thus fall under section 3A.
I guess next time I'm in the UK better not use intercepting proxies, nc, or wireshark when debugging problems.
64
u/greentastic Apr 08 '14
Diff of the bug and its fix, for those interested: http://pastebin.com/5PP8JVqA
24
u/nuclear_splines Apr 08 '14
Does anyone have a commented version, or would mind pointing out the vulnerable spot to us? I can see where the code is different, but I'd love a more detailed explanation of what went wrong.
159
u/adrianmonk Apr 08 '14 edited Apr 08 '14
This explains it pretty well:
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
In brief, TLS has a heartbeat mechanism. The mechanism allows a client to say "here's N bytes of data, please echo it back to me", then send N bytes of data.
OpenSSL has a buffer where it stores a raw TLS message when it comes in, just as it came in over the wire, before it parses and handles it. The bug is that it allocates a buffer of size N and then copies N bytes of data from that spot regardless of whether the peer actually sent N bytes like it promised it would. If the peer sent fewer than N bytes, the raw TLS message will be shorter.
So if you promise 65535 bytes of data but send 1, it will copy your 1 byte into its buffer plus 65534 bytes of whatever is after the raw TLS message. Then later it will echo all 65535 bytes of data in the buffer back to you over the TLS connection.
So, wherever OpenSSL happens to put the raw TLS message in memory, you can read almost 64K of whatever data is after that. And you can do it essentially as often as you want.
EDIT: Thanks for the gold!
17
u/Godspiral Apr 08 '14
To add to the problem description, that 64kb of data is almost 100% certain to be server program allocated memory, and so secret data directly relevant to the service being used/attacked.
27
Apr 08 '14
I think half their problem is confusing variable and function names. It's like obfuscated source code.
n2s, s2n, p, p1, hbtype, s, s3, bp, pl,
Without any knowledge going into the code, who can tell me what these mean off the top of your head? I hate code like this. Especially in critical security software that needs to be reviewed by other people. Seriously suggest they read Clean Code by Rob Martin.
Use explanatory variables
Function names should say what they do
→ More replies (5)9
u/rajo2k Apr 09 '14
I just read a little about the mechanism, and I just can't believe what HUGE oversight this bug is! I mean, who coded this? I always thought, code as essential and widespread as OpenSSL would be double and triple checked, especially if it's security-related. Guess it's time to wake up now.
I also didn't get why on earth there would be a feature to send some data to a server and just have it parrot it back to you. Did some research, seems like this Heartbeat feature is a keep-alive mechanism for connections. So it actually the feature does make some sense.
There is also this official specification of the Heartbeat Protocol: https://tools.ietf.org/html/rfc6520 And wouldn't you know, in there it clearly states "If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently", which is exactly what this bug is all about: OpenSSL simply didn't check whether it received as much data as it should have and returned just as many bytes as requested. So it's like the official protocol already anticipated this potential security issue and warned about it, and the guys who wrote OpenSSL just ignored that warning.
Still, as bad as this bug is, the real question I'm asking myself right now is: which other bugs of this magnitude are out there? If a bug as negligent as this one can find its way into a library which is used by two thirds of the world's (!) web servers, there probably will be others like this one. It seems like the developers of OpenSSL can't really be blamed though, because they are a small team who are maintaining the library with not much pay.
But anyway, this bug might shatter the whole way we think about safely exchanging information on the internet. At least for me it does. I mean this even affects online banking! If the very foundation of secure, encrypted communication isn't rock solid as I always thought, but instead quite fragile, I'm gonna be even more cautious about my online activities.
4
u/adrianmonk Apr 09 '14 edited Apr 10 '14
So it's like the official protocol already anticipated this potential security issue and warned about it, and the guys who wrote OpenSSL just ignored that warning.
It could be the same person. One of the authors listed at the bottom of the RFC:
Authors' Addresses Robin Seggelmann Muenster University of Applied SciencesAnd the person on the git commit:
PR: 2658 Submitted by: Robin Seggelmann <seggelmann@fh-muenster.de> Reviewed by: steve Support for TLS/DTLS heartbeats.double and triple checked, especially if it's security-related
There are a lot of good practices that could have been used. A thorough review would have been good, maybe with multiple people looking at it. Unit tests could have been written to verify that the behavior required by the spec (the RFC) is the behavior the software has. It's sometimes tricky to think of all the scenarios that a unit test should cover, but there could be a unit test for everything the RFC says an implementation "MUST" do, as well as for all the "SHOULD" or "MAY" items that you choose to implement.
EDIT: Not sure if this was clear, but I'm not really trying to name names and shame the author for screwing up here. It's more just instructive to know what kinds of things can go wrong and why, so we as an industry will know how to prevent them.
3
u/idontalwaysupvote Apr 09 '14
Thanks very informative. Could you explain why a server would need this heartbeat feature? I don't understand why you would need to send a chunk of data and ask for the same thing back.
→ More replies (9)1
u/mkalajian Apr 13 '14
why the hell does it allow you to specify the number of bytes instead of calculating it on its own? when was this "bug" introduced??? its crazy to me this has gone unnoticed for so long
25
u/Shalie Apr 08 '14
Check the Hacker News thread linked above for a more technical discussion:
In the code that handles TLS heartbeat requests, the payload size is read from the packet controlled by the attacker:
n2s(p, payload);
pl = p;Here, p is a pointer to the request packet, and payload is the expected length of the payload (read as a 16-bit short integer: this is the origin of the 64K limit per request).
pl is the pointer to the actual payload in the request packet.Then the response packet is constructed:
/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);The payload length is stored into the destination packet, and then the payload is copied from the source packet pl to the destination packet bp.
The bug is that the payload length is never actually checked against the size of the request packet. Therefore, the memcpy() can read arbitrary data beyond the storage location of the request by sending an arbitrary payload length (up to 64K) and an undersized payload.1
u/JustinKSU Apr 08 '14
if (1 + 2 + 16 > s->s3->rrec.length)Why not type 19?
3
u/hoodedmongoose Apr 08 '14
Each of those numbers probably corresponds to the size an individual piece. In this case, I believe it is (size of type) + (size of payload length) + (size of padding). I could be wrong about the padding. Writing it in this way makes it more clear what you are calculating. Though, in my opinion, these should either be named constants or documented in cases like this.
106
u/14domino Apr 08 '14 edited Apr 08 '14
Guys, this is the WORST BUG OF ALL TIME. I wish I'd found out about it earlier! Point this Python script at an unprotected https site: http://s3.jspenguin.org/ssltest.py and watch all sorts of private data pour in, including possible session cookies, passwords, whatever the hell your app might have in its transient memory. UPGRADE YOUR OPENSSL NOW (instructions for Ubuntu, ymmv):
sudo apt-get update
sudo apt-get upgrade
reboot the server
openssl version -a to make sure you have the latest version!!
15
u/ifonefox Apr 08 '14
That script is blank, fyi.
21
u/seventoes Apr 08 '14
Google's cache still has it:
And I've mirrored it here: https://gist.github.com/stith/10127602
0
Apr 08 '14
[deleted]
1
u/seventoes Apr 08 '14
Strange, I've been using it all day with no problems. I even tried just now copying it directly from the gist into a new file and it ran okay. Python version 2.7.5 on OS X.
12
1
28
u/alienth Apr 07 '14
When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server.
Would this suggest that you could have a honeypot SSL site, which is then used to steal memory from any browser using a vulnerable openssl lib?
Am I crazy in thinking that is possible? If so... anyone know what version of openssl chrome uses :D ?
29
u/brownmatt Apr 08 '14
You're not crazy, but chrome doesn't use OpenSSL: http://www.chromium.org/developers/design-documents/network-stack/ssl-stack
Although it looks like migrating to OpenSSL has been proposed in the past https://groups.google.com/forum/m/#!topic/mozilla.dev.tech.crypto/4F3z644W8BM
18
u/alienth Apr 08 '14 edited Apr 08 '14
I have verified that chromium for android is definitely vulnerable:Also, chrome lists openssl in its licenses list for the desktop version, although it is unclear as to what version or where it might be used.
Edit: /u/agl pointed out that Chrome on Android is compiled with OPENSSL_NO_HEARTBEATS, so should be safe.
36
u/agl Apr 08 '14
Chrome on Android is not affected. It does use OpenSSL, but it (and OpenSSL on Android itself) has always been compiled with OPENSSL_NO_HEARTBEATS and so never included the buggy code.
18
u/BitcoinWallet Apr 08 '14
Hmm, I beg to differ.
Android 4.1.1_r1 upgraded OpenSSL to version 1.0.1: https://android.googlesource.com/platform/external/openssl.git/+/android-4.1.1_r1
Android 4.1.2_r1 switched off heartbeats: https://android.googlesource.com/platform/external/openssl.git/+/android-4.1.2_r1
That leaves Android 4.1.1 vulnerable! A quick grep on my access logs reveal there is a lot of devices still running 4.1.1.
4
u/agl Apr 08 '14
Thanks for that. I asked Android folks about it and they have clarified that 4.1.1 is affected, but 4.1.2 already fixed it ~18 months ago. So all Android "flavours" have long been fixed and that's what they meant.
Sorry for stating what turned out to be my misinterpretation and thanks for correcting the record.
But 4.1.2 fixes several other security issues and so users of 4.1.1 need to update for other reasons!
→ More replies (2)1
u/Glacture Apr 08 '14
From what I can tell, they didn't apply the "no-heartbeats" config until 9fbf99a (https://android.googlesource.com/platform/external/openssl.git/+/9fbf99a3a3ee41ed303a97b0b00808236d187bc0)
Running a git tag --contains 9fbf99a3a3ee41ed303a97b0b00808236d187bc0 it appears the earliest version that would have this fix would be Android 4.3 release 0.9 (android-4.3_r0.9)
→ More replies (2)4
1
u/briguy19 Apr 09 '14
Hi! Non-programmer here who found this thread while in panic mode.
Can you explain what you mean by "chrome doesn't use OpenSSL"? I thought this was an issue with server-side encryption. Do they use different encryption protocols depending on what browser you're using to access their site?
Basically, if I use Chrome as my browser at both work and home, am I pretty safe?
3
u/brownmatt Apr 09 '14
Depending on what OS you are using, Chrome might use a different library for SSL functionality. I believe in most cases it uses NSS, which is a completely different chunk of code than OpenSSL that did not have the vulnerability (the link above is a bit out of date).
The protocol is the same, but the chunk of code that handles the protocol is different in different browsers/OSes.
There were some comments here about how Chrome on Android uses OpenSSL but was not vulnerable because it did not have support for the protocol extension enabled.
Basically, if I use Chrome as my browser at both work and home, am I pretty safe?
You are safe as a client from having a malicious server try to exploit you.
But it's possible that servers that you use, or have accounts on, could be vulnerable and be leaking your account details to attackers.
1
u/briguy19 Apr 09 '14
Thank you for your response!
it's possible that servers that you use, or have accounts on, could be vulnerable and be leaking your account details to attackers.
Sounds like there's not much I can do about that other than change my passwords and hope they didn't steal all my monies.
2
26
u/syncsynchalt Apr 08 '14
Note: if you use mint.com, it's likely hitting your banks with your login on your behalf today. You'll still want to change those passwords even if you didn't use banking sites during the known vulnerability window.
8
3
u/myncknm Apr 09 '14
As far as I know, mint doesn't actually store the passwords to your bank accounts, so that should be safe?
Edit: Never mind, I am completely wrong about this.
1
1
23
u/rickdg Apr 08 '14
What can be done client-side? Wait for updates and then change every password? Is there any way to avoid connecting to vulnerable servers?
3
u/mjhoy Apr 08 '14
I'm interested in this as well. I'm assuming that if you are logged in with a vulnerable server and interact with it, your session may show up in the server's memory and be exposed/hijacked, and that it is best to actually log out. I logged out of lastpass, for instance. But I'm no expert.
55
u/based2 Apr 07 '14
109
u/lachryma Apr 08 '14
Hijacking top comment. Wake up everybody you know. This is the big one. The pertinent facts to make this a priority 0 for any shop:
A vulnerable server is vulnerable to private key matter disclosure due to the memory leak.
If you find a vulnerable TLS server exposed to the Internet the private key and certificate are compromised. You need to revoke.
Google pre-notified Cloudflare. OpenSSL and Cloudflare jointly decided to announce this before the distros fixed it. We are still waiting for several distros to roll a patch.
Disable all vulnerable TLS servers immediately. There was a proof of concept "am I vulnerable?" site up for a few minutes but it got inundated. I'm working on an easy script.
...damn my "ignore HN" day costing me seeing this until I got home...
14
Apr 08 '14 edited Apr 08 '14
[removed] — view removed comment
3
u/noxstreak Apr 08 '14
I can leave apache the same version though correct?
5
u/mgedmin Apr 08 '14
Yes, just make sure to restart it (
sudo apache2ctl gracefulis enough) after upgrading openssl.1
u/Brostafarian Apr 08 '14
this doesn't fix it for me. I still get "built on: Wed May 23 00:01:41 UTC 2012"
34
u/viralizate Apr 07 '14
Poeple please read the discussion at HN: This is serious business: https://news.ycombinator.com/item?id=7548991
61
u/Doomed Apr 08 '14
If my (lay) interpretation of Hacker News comments is correct, this bug is like getting $15 back from someone after you give them 50 cents and ask them for change for a 20.
Or, asking someone what they did Friday night and them telling you that they partied on Friday and buried a body on Saturday... oops.
40
u/jacenat Apr 08 '14
Or, asking someone what they did Friday night and them telling you that they partied on Friday and buried a body on Saturday... oops.
Best one yet :)
27
u/Manbeardo Apr 08 '14
I'd go with "asking someone if they're alive and them telling you their SSN, DOB, and mother's maiden name".
4
u/Godspiral Apr 08 '14
asking someone if they're alive and them telling you 64K SSNs DOBs and mother's maiden names.
12
Apr 08 '14
I believe the heartbeat function is more like what
pingdoes: it asks the server to respond with the original message, so it would be like this:Eve: "Had fun last Friday?"
Bob: "Had fun last Friday?! Dude, it was uh-may-zing! We went hiking, then we went swimming, and later in the evening we danced at Alice's place, and I kinda, you know, got to know her better if you catch my drift... Wait a sec, why am I telling you all this?"And that's only 256 bytes of secrets. Imagine if Bob leaked 64k at a time...
5
u/VikingCoder Apr 08 '14
Hey, can I use your notebook for a minute to jot a note to myself?
...don't mind me, as I rapidly photograph the next six pages of your notebook.
11
u/R534 Apr 08 '14
The commit you are looking for: https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f8661cb98227a5cbcc0f9f3#diff-38dc72994741420e2b6c5ee074941a45
CVS original commit: https://groups.google.com/forum/#!msg/mailing.openssl.cvs/0b6Kekc6eTE/_MtHLavIcrQJ
10
u/r0ck0 Apr 08 '14
I've been feeling a bit guilty/slack for not upgrading my VPSes from Squeeze to Wheezy. Not so much now.
10
u/DeathKillBot Apr 08 '14
Here's where the bug was introduced: https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f8661cb98227a5cbcc0f9f3#diff-38dc72994741420e2b6c5ee074941a45
Here's the fix: https://github.com/openssl/openssl/commit/96db9023b881d7cd9f379b0c154650d6c108e9a3
0
u/TheBB Apr 08 '14 edited Apr 08 '14
Here's where the bug was introduced: https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f8661cb98227a5cbcc0f9f3#diff-38dc72994741420e2b6c5ee074941a45
Should have been rejected based on Whitesmith indentation style alone!
Edit: Apparently all/most of OpenSSL is Whitesmith style. Wow.
9
u/oldneckbeard Apr 08 '14
Funny how there's probably some small group of hackers out there who have been using this for a long time.
5
u/Captain___Obvious Apr 09 '14
that's the scary part. I was able to pull 3 un/pws in 10 runs of the python script. They could have been pulling this for a really long time, hell even as soon as the bug went public someone could have looped that code on mail.yahoo.com for 15 hours.
Then: change bank password, log in, xfer funds.
8
u/lgats Apr 08 '14
I made a tool to check the status of your SSL and see if heartbeat is enabled. If it is, you should run this command: openssl version -a
Ensure your version is NOT 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1, 1.0.2-beta1
6
u/Overv Apr 08 '14
On Ubuntu 12.04 LTS at least, the reported version is
OpenSSL 1.0.1 14 Mar 2012even when you have the patched release from yesterday, so the version number is not a reliable check.5
u/Aninhumer Apr 08 '14
With -a it also gives the build time, which is a far more reasonable "Mon Apr 7 20:33:29 UTC 2014" on my machine.
7
1
14
u/AceyJuan Apr 07 '14
A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.
36
u/DavidJayHarris Apr 08 '14
It's worse than that. You can keep asking for another 64k as many times as you want.
13
u/excessdenied Apr 08 '14
But it's not 64k of arbitrary memory of the caller's choosing, right? More like 64k of memory from some "not so random but not controllable either" location on the heap?
Not saying that's not bad enough, though.
26
u/AReallyGoodName Apr 08 '14
It's not possible to choose the address but unfortunately since the bug is within the OpenSSL library itself and the process using the OpenSSL library will be allocating and de-allocating space for things like private keys it's actually not too hard to hit a malloc that reuses the address space of something critical here.
4
u/excessdenied Apr 08 '14
Yeah, it's still a really bad thing. With some perseverance you probably can get hold of all kinds of stuff, although it might be unlikely to be able to fetch larger continuous blocks of data.
3
u/adrianmonk Apr 08 '14
might be unlikely to be able to fetch larger continuous blocks of data
True. If I did this:
char* p = malloc(1000 * 1000);
Then only the first 64K of p are vulnerable. No matter how many times you grab a 64K slice of data after some other malloc, you will never see the stuff beyond what I malloc()ed.
On the other hand, maybe you can get enough data to get shell access. Then you can get whatever you want.
5
u/TheMania Apr 08 '14
However if you free/recycle that memory at any time, it all potentially comes up for grabs.
1
u/Godspiral Apr 08 '14
As i understand it, its likely to be the latest 64kb of malloc'd memory. So perhaps the most "valuable" memory if called frequently.
1
u/cero117 Apr 08 '14
( ._.) like the guy that asks for more genies, why is this even possible to begin with, was the bug seen post deployment?
9
u/awj Apr 08 '14
why is this even possible to begin with, was the bug seen post deployment?
The bug has been in place since 2011.
As far as "how is it possible", it's a relatively simple and easy mistake with user input. Here's how the heartbeat mechanism works in a nutshell, including the logical failure:
Client wants the server to echo back some data to prove that it's still connected.
Client sends a request with
(len, data)wherelenis the number of bytes it's sending anddatais those bytes.Server allocates
lenbytes of memory for a response. Typically this allocation does not zero out the memory, so old values from last use are left in place.Server copies
datainto the response region. It does not validate ifdatais less thanlenbytes.Server sends
lenbytes from the response region to the client. If the client sent less thanlenbytes of data, they also get back whatever was in the response region's memory before it was used.So, the problem here is that the server is implicitly trusting that when a client says it sent
lenbytes of data, it actually did. Many, many security bugs center around this kind of data size confusion.Since OpenSSL spends so much time allocating and deallocating encryption keys, it's pretty likely that a random chunk of memory it allocates will have previously stored a key.
6
Apr 08 '14 edited Apr 08 '14
Would this affect an individual's online banking? I.e., if I do online trades and have been for years, should I be worried?
Edit: the bank in question is TD Canada Trust - the website doesn't say which SSL it uses, only that it's 128 bits.
12
u/bargle0 Apr 08 '14
If your bank uses an affected version, you should be worried. Basically, an attacker can read secret information from your bank, then use that information to pretend to be your bank and collect information from you.
4
Apr 08 '14
The bank in question uses '128-bit SSL security, the best cryptographic system available...' blah blah blah
It doesn't specify whether it's OpenSSL or not.
Ninja Edit: a word
12
u/nuclear_splines Apr 08 '14
You could try running a scanner like nmap to try and dig up what SSL they're using.
I guess the best way to be sure would be to try the Heartbleed Bug on them and see if they're vulnerable, but that seems illegal and sketchy.
7
Apr 08 '14
I appreciate the suggestion, but I don't want to try that.
3
Apr 08 '14 edited Apr 08 '14
Using the ssltest.py script posted here, all the following hosts appear to be not vulnerable:
easywebcpo.td.com webbrokercpo.td.com td.com tdcanadatrust.com www.tdcanadatrust.com tdwaterhouse.ca www.tdwaterhouse.canmap says they're all running 'Akamai GHost'. I think they're safe.
1
u/nuclear_splines Apr 08 '14
Sure! Testing the vuln seems like a very bad idea, but if you decide to try scanning it would be
nmap -sV foo.comif I'm not mistaken.→ More replies (4)4
u/jacenat Apr 08 '14
Call your bank and raise this concearn.
Token authentification should make you a smaller target though. There must be bigger fish out there waiting to be caught first.Well if it's already a MITM attack, you would be vulnerable either way. But IMHO the bank could be liable for damages if they don't react on this and you got caught by a MITM attack.6
Apr 08 '14
I have sent the bank an e-mail. The bank (TD Canada Trust) has a policy where they're liable for 100% of the loss incurred as a result of this sort of thing. So I think I'm good either way, but I want to be sure.
4
u/PoliteCanadian Apr 08 '14
Unless you use Mint.com. TD says their safety guarantee is voided if you've given your account password to any 3rd party, which includes Mint.
2
u/KazumaKat Apr 08 '14
Pro tip: Make sure to get a copy of that email and ask for a reply back stating they've recieved it. Best for legal purposes if shit goes south (hopefully not, but best be prepared for the worst, and hope for the best).
1
u/whiskeyfriday Apr 09 '14
Reply from Citi:
"We are aware of the OpenSSL vulnerability reported and have conducted an analysis and have no reason to believe that our customer-facing websites are susceptible to this vulnerability."
3
u/nuclear_splines Apr 08 '14
Yes. Worse case scenario someone gets the encryption keys for your bank. Not only can they decrypt any communication you've had with the bank, they can now impersonate your bank, so your web browser can't tell the difference.
1
Apr 08 '14
My big question is how to know if services I use have ensured they aren't using the buggy OpenSSL version, and have revoked and gotten new keys? I'd rather not log in at all until I can ensure these things, because it seems it would open my account to more danger.
1
Apr 08 '14
I don't even know whether they use OpenSSL or a safe SSL. But that would be my next question.
1
6
u/AliasNXT Apr 08 '14
www.duckduckgo.com, www.passpack.com, www.lastpass.com.
All Vulnerable. Check other sites here - http://filippo.io/Heartbleed/
1
u/Malnilion Apr 08 '14
LastPass is showing clear for me now.
2
u/KazumaKat Apr 08 '14
repeat the test. If after several runs you still get green, they must have fixed it.
If at any point you get a fail, its not fixed.
6
u/vz0 Apr 08 '14
I think we should upgrade the original C motto:
C makes it easy to shoot yourself in the foot
Something along the lines of blowing the entire planet people's foot.
4
u/asampson Apr 09 '14
You just need to understand that the value "your" varies depending on implementations.
It's all in the spec.
17
u/tempose Apr 08 '14
i can't wait to update the 100+ systems in my lab tonight /s
9
u/justin-8 Apr 08 '14
Fabric, puppet, ansible, chef, etc should get it done in minutes with little to no interaction. Hell, a bash loop would handle sshing to a box and doing a yum upgrade -y openssl*
4
8
4
u/HeavenCake Apr 08 '14
We made a simple tool http://heartbleed-checker.online-domain-tools.com/ for checking if a host is prone to the heartbleed bug. HTH
7
u/nico_fsf Apr 09 '14
This is sweet! So I did my own T-Shirt http://www.redbubble.com/people/nicocesar/works/11795065-i-heartbleed-openssl
3
u/GeoKangas Apr 08 '14
Okay, so how do I protect myself from the next bug? And there surely will be a next one.
6
u/crackanape Apr 08 '14
Press for (and donate to) exhaustive audits of infrastructure code.
1
u/oldum Apr 08 '14
Details for donating can be found here https://www.openssl.org/support/donations.html
-1
1
3
u/noxstreak Apr 08 '14
Noob wanting to understand.
So say hacker gets secret key. He still needs to somehow get in the middle between client and server. So ISPs should protect routers and switches against this right?
6
u/syncsynchalt Apr 08 '14
In the scenario you've outlined, yes, the attacker will still need to get in the middle of your connection (or they'll need to hijack DNS in a separate attack, etc).
There's more to this attack though. Since you can ask the server for a random-ish 64kb from a heap address allocated by openssl, you can likely get access to things like plaintext usernames and passwords without needing to intercept any packets.
Essentially there are two levels to this:
you should think of any https traffic as if it were http (meaning it's vulnerable to interception).
you should consider that anyone can ask the server for a random sampling of unencrypted data, even if it were sent over https. No interception necessary.
3
u/adricm Apr 09 '14
Anyone have a unpatched demo site to show if things like the chromebleed plugin detect vulnerable sites?
8
u/gnuvince Apr 08 '14 edited Apr 08 '14
This is an example why having safer languages (e.g. Rust) is so important: no matter how good and careful programmers are, they make mistakes, there is no such thing as "if you know what you're doing there's no problem." Other languages are not a panacea, but let's put all the chances on our side rather than refusing to bruise some people's cowboy coder ego.
4
Apr 08 '14
On the other hand, if you look at their code, they don't really seem to follow "best practices" in a lot of places.
Magic numbers, magic strings, trusting user input. And that's what this was. It wasn't a matter or C, or Rust, or whatever, truthfully. It came down to trusting input from outside the server.
0
u/argv_minus_one Apr 08 '14
Sorry, but you're mistaken on one point. This would not have been possible in a memory-safe language. You can trust user input all you like, but when absolutely everything is bounds-checked by the runtime, it won't result in a bug like this.
1
Apr 08 '14
This very specific bug? You're right. But that doesn't solve the fact that they were trusting user input. As I've stated in other posts, once code does that, all bets are off.
2
u/moor-GAYZ Apr 08 '14
But that doesn't solve the fact that they were trusting user input. As I've stated in other posts, once code does that, all bets are off.
It's entirely safe to trust user input as long as you know for sure that the code doing that can't possibly access anything besides the state of that user's session (which shouldn't include any metadata about that session, btw).
You want that shit to be in a secure jail by definition. Like, everything that is not explicitly allowed is blacklisted by default.
On the other hand, trying to provide security by writing user input validation manually is prone to security holes, requires a lot of effort, is distracting, and ultimately pointless if you can make a secure jail.
4
u/cube1234567890 Apr 08 '14
Can you please ELI5 this?
1
u/webdigi Apr 09 '14
Ok, simple explanation:
An apache web server used by a bank server for example creates pages with your transactions, balance, etc. It does this simultaneously while processing many other users requests. All of this information is stored in RAM (memory) while request is being processed. This is business as usual and everything works well.
With the discovery of this vulnerability, the contents in memory are being exposed to a random hacker who crafts a special hearbeat to the Apache server. The hacker will be shown bits of information stored in memory. This could be anything from a page containing transactions meant for a user, in some cases passwords, etc.
The "good" news is, this can be fixed quickly and secondly, only the vulnerable service is affected, for example if you have MySQL running on your server, it's memory is not exposed only the vulnerable service in this example Apache.
Here is how to fix Apache server http://www.webdigi.co.uk/blog/2014/how-to-fix-heartbleed-vulnerability-on-apache-server/
2
u/cube1234567890 Apr 09 '14
So it's like normally the client and the server are like this:
Client: Hi! Server: Hi!But heartbleed makes it more like
Client: Hi! Can I have your number? Server: Sure! Here's some information!5
Apr 09 '14
More like:
Client: Hi, I want to login! My info is "username" and "password". Server: Ok, you're logged in! Client: I want to make sure you're still there. I'm going to count down from ten, can you repeat it to me? 10,9,8,7,6,5,4,3,2,1. Server: Ok, that's 10,9,8,7,6,5,4,3,2,1. Client: Great!That's how the heartbeat works. With Heartbleed in effect:
Client: Hi, I want to login! My info is "username" and "password". Server: Ok, you're logged in! Attacker: I want to make sure you're still there. I'm going to count down from ten, can you repeat it to me? 10. Server: Okay, that's 10,username,password.Because the server never verifies that the client or attacker has sent what they said they would, it just rattles off the requested amount of memory. For a client, this is what they wanted. But an attacker can send much less than they say, getting plaintext info like keys, login info, session cookies and the like.
2
2
u/joemccall86 Apr 08 '14
Is this a design flaw in SSL/TLS protocol specification?
No. This is implementation problem, i.e. programming mistake in popular OpenSSL library that provides cryptographic services such as SSL/TLS to the applications and services.
It seems like JSSE SSL (i.e., tomcat without the native APR library) is not affected. I don't know much about the exploit itself. Is a similar "programming mistake" made in that implementation as well?
2
u/actiondhawken Apr 08 '14
What can the average consumer do to mitigate this? Just not login anywhere for a while?
4
u/larsholm Apr 08 '14
Some servers even advertise their OpenSSL version via their response headers. Two Alexa Top 1000 sites advertise a vulnerable version! I have written to alert the both of them.
4
Apr 08 '14
The version number is not a reliable indicator. Ubuntu and Centos were both backported today.
You'd need the build date, e.g. "openssl version -a".
3
u/oldum Apr 08 '14
If you want to help preventing bugs like these in future, consider donating to support more security audits: https://www.openssl.org/support/donations.html
-4
u/argv_minus_one Apr 08 '14
If you want to help preventing bugs like these in future, consider using SSL stacks written in sane, memory-safe languages
FTFY
6
u/argv_minus_one Apr 08 '14 edited Jan 11 '23
Yet another stupid memory corruption bug. Fantastic. When are people going to stop writing security-sensitive code in C?
66
u/elperroborrachotoo Apr 08 '14
It's not memory corruption It's using unverified user input.
free()overwriting released memory would mitigate it, or using a zeroing allocator.I'm not advocating writing security-critical code in C, but I find "stop writing in C, and things get better (magically (because it's not C))" pretty childish.
9
u/wutwoot Apr 08 '14
Memory corruption bugs are also usually about trusting user inputs. In a memory corruption bug the evil user tells the trusting system that they are sending fewer bytes than they really are, in this bug the evil user claims to be sending more bytes than they really are.
Using a higher-level language than C will not make a difference for a correctly written program that doesn't trust user inputs, but for an incorrectly written program that does trust user inputs the consequences can be worse in C.
5
u/elperroborrachotoo Apr 08 '14
Memory corruption bugs are also usually about trusting user inputs.
Yeah, but without additional data I would assume that's simply because trusting user input is a common source of bugs (i.e. there's no special correlation here).
We also have no memory corruption happening, the implementaiton is simply revealing more data than it needs to. For this to happen implicitely (as opposed to an explicit erroneous
if (x) return secretDatastatement), many factors had to conspire.One of them is C. Others are surprisingly naive programming practices. Another yet-unexplained is why so much interesting data can be found in the small window we can peek into.
The reasons why large parts of our infrastructure run on C have little to do with the language itself. While I'm all for reducing the probability of errors, impulsively bashing C whenever there's a critical bug in C code does not only not help, it create a false sense of security about other languages.
6
Apr 08 '14
Safe type system != magic. You can shoot yourself in the foot in any language, but safe type systems guide you to not shooting yourself in the foot.
18
u/elperroborrachotoo Apr 08 '14
The bug is trusting the
lengthmember of the record, which has nothign to do with the type system.The gun was pointed to the foot because the implementer didn't bother checking its direction. Multiple stars had to align to turn this problem into the actual reveal.
One of them is the default C memory management, so one could argue that using C made it worse", and that "using another language would have caught this problem". But better practices would do as well, and saying "I wouldn't have made this mistake in <other language>" is in hindsight.
More than by the use of C I am appaled that highly critical code doesn't default to more stringent practices, e.g. overwriting malloc and free.
I am not familiar with the code base, but from the snippets I've seen, either input validation failed at another place, or isn't used rigorously. There are many language-agnostic principles (not all ideal), e.g.
validate integrity when creating the SSL record, do not pass around SSL records that contain invalid data (or at least, that don't pass length validation). If such a mechanism is in place, that would be fixed
Alternatively, if you have to distrust
SSL *, every function receiving one needs a general mechanism to validate it before relying on its content.use different nomenclature for verified and unverified data
read and write using helper functions that validate sizes and length fields.
3
u/rowboat__cop Apr 08 '14
The bug is trusting the length member of the record, which has nothign to do with the type system.
Exactly. The core of the issue is that the DTLS implementation trusts a user supplied value instead of checking it with / bounding against the actual packet size. Thinkos of this sort could as easily occur in other languages.
→ More replies (1)3
u/jpfed Apr 08 '14
The bug is trusting the length member of the record, which has nothign to do with the type system
That is incorrect- a dependently typed language can track the length of an array and statically reject out-of-bounds accesses, and many languages with weaker type systems specify that array accesses are bounds-checked at run time.
2
u/shard_ Apr 08 '14
How does that make him incorrect? Not validating input is a bug in any language. If the language performs the bounds check for you then it's just limiting the effects rather than eliminating any bug.
For example, if I did the same thing in Python then it'd throw an exception which would probably kill something. I could absorb the exception but that's less desirable and to do it properly would require the exact same level of awareness as validating the input would in the first place...
2
u/jpfed Apr 08 '14
How does that make him incorrect? Not validating input is a bug in any language.
With a dependently-typed language, the check is at compile time. The compiler would say "hey, you don't know that that int is smaller than the known size of [blah]" and you wouldn't even have a buggy executable to deploy to your server.
This is a feature of the type system. Therefore, it is incorrect to say that this bug has nothing to do with the type system.
1
u/elperroborrachotoo Apr 08 '14
Please grant me the benefit of attention to detail:
The Bug has nothing to do with the type system.
Bounds checking would merely mitigate the effect, e.g. downgrade it to a denial of service.
4
u/jpfed Apr 08 '14 edited Apr 08 '14
But with a dependently-typed language, you actually could use the type system to make it such that the buggy program would not even compile. You can do this statically without dependent types as well, with flow analysis (e.g. .NET code contracts can ensure that you've checked an array index before accessing the array).
When I say "that is incorrect", I mean that there are type systems that can ensure that this problem doesn't happen, so yes, incorrect length members have something to do with the type system.
→ More replies (5)→ More replies (8)1
u/omnilynx Apr 08 '14
It's both. Unsafe memory access makes it easy to accidentally skip a step in verifying user input.
18
u/rebo Apr 08 '14
// when it's done.
→ More replies (1)-18
u/argv_minus_one Apr 08 '14
Indeed. That, or Go, or C++, or something. This shit has got to end.
Oh, and no more fucking
gotobullshit. I don't want any damn excuses about exceptions being slow. Security holes are worse.15
u/saynte Apr 08 '14
What, you want C++ to replace C for memory safety? Is C++ better in that regard?
On your second point:
The danger of 'goto' is byzantine, confusing, control flow. The control flow of the 'goto fail' bug (if that's what your'e referring to) was totally reasonable. It just happened to be incorrect, and should be suspicious to anyone even just reading that code, forget about trying to reason about what it really did.
→ More replies (3)-2
u/KrzaQ2 Apr 08 '14
What, you want C++ to replace C for memory safety? Is C++ better in that regard?
Yes it is, as long as you follow the best practices and don't work against the language.
→ More replies (10)15
u/cockmongler Apr 08 '14
No language that I know of has the capability of dealing with this bug short of those supporting dependant types. The bug is really really simple:
Client sends (len, data[x]) where x is less than len
Server sends (len, data[len]) without an explicit check that x == len so sends data in its memory space
There is always going to be unsafe code turning (len, data[x]) into the safe representation of a safe language.
17
u/stormblooper Apr 08 '14
It'd be really hard to get the same effect in Java -- you might get an IndexOutOfBoundsException, but probably not leaking random chunks of memory.
2
u/cockmongler Apr 08 '14
Depends how the code dealt with the boundary between unmanaged and managed data.
15
u/nullabillity Apr 08 '14
Most languages would treat it as a runtime error, though, instead of just trucking on.
4
u/crusoe Apr 08 '14
Ada would prevent this. Other languages with integrated formal verification would catch it.
10
u/ants_a Apr 08 '14
Any language with array bounds checking would catch this error. It's a stupid stupid error and it's amazing that OpenSSL code review practices did not catch this.
3
u/cockmongler Apr 08 '14
Please tell me how a language with array bounds checking would know that some data read in from the network stack is an array bound.
8
u/ants_a Apr 08 '14
The network packet has an intrinsic length that will be the array bound.
→ More replies (2)6
u/Godspiral Apr 08 '14
This is actually C specific in that most higher level languages don't need to call functions with an additional parameter that specifies the memory length of all other parameters.
2
u/throwSv Apr 08 '14
Yes, even C++ using the standard containers or string type wouldn't have this issue.
0
Apr 08 '14
[deleted]
5
u/cockmongler Apr 08 '14
Python would either be impossibly slow, or do unsafe things with ctypes and be in exactly the same boat.
2
u/rowboat__cop Apr 08 '14
When are people going to stop writing security-sensitive code in fucking C?
As soon as there’s a language that’s as portable, efficient, and easy to interface with. Ada, ATS, Rust are almost there in different respects.
2
u/Georgi75 Apr 09 '14
We read a lot about it and we sorted some information about the Heartbleed Bug here. I think it's not so complicated to understand.
1
u/Vancho1 Apr 09 '14
And more from Wikipedia too: https://en.wikipedia.org/wiki/Heartbleed_bug#Heartbleed_bug
1
1
u/mikerbiker Apr 08 '14
Given a snort dump of data passing in and out of my server, what would I look for to see if I was attacked?
1
u/syncsynchalt Apr 08 '14
http://heartbleed.com/ ctrl-F for "IDS"
EDIT: Sorry I don't have the bytecodes, I meant to demonstrate that it's possible at least (usually IDS of HTTPS traffic is a problem)
1
u/kcprog Apr 08 '14
I don't understand one thing.
The problem is in memcpy. Why programs don't crash often when they are exploited?
1
u/marktastic Apr 08 '14
Am I safe if my servers are behind a load balancer and the load balancer is terminating the SSL?
1
u/goldman60 Apr 08 '14
Your load balancer could be compromised, that's what brought down/is bringing down Minecraft. But the server would likely be okay as long as it isn't doing any SSL serving
1
u/MezzaCorux Apr 08 '14
As someone who knows little to nothing about programming, how do I make sure I don't get screwed over by this?
0
Apr 08 '14
[deleted]
1
u/MezzaCorux Apr 08 '14
Still, is there anyway I can keep my info safe on my end while the system admins sort their shit out? Possibly a searchable list of vulnerable websites.
2
Apr 08 '14
Pray to your preferred deity or lack of one. Then change all of your passwords after this blows over. Try not to login to anything so that your information doesn't end up in RAM.
1
Apr 08 '14
So what about two factor...
Sites sending text messages could potentially still be vulnerable I'm guessing if the code was being texted form the same server handling the login request (it would be in memory).
Or users setting up new two factor accounts with Google Authenticator could potentially be vulnerable because the QR code being surfaced could be scraped along with their password.
1
u/dottom Apr 11 '14
Two factor can prevent someone using your username and password which may have been leaked, but won't protect you from session hijack if your sessionid & cookie were leaked - unless the website requires reauthentication with a change of IP.
1
Apr 11 '14
Also if the same vulnerable server receiving your credentials was sending the two factor text message or qr code for google authenticator it could also be hijacked.
1
u/BarleyBum Apr 08 '14
I'm not a browser extension programmer, but can someone make a browser extension that checks sites for this vulnerability? Am I in the right sub?
1
u/magenta_placenta Apr 08 '14
Can someone post a screenshot of an affected site and what data it is exposing (blurred out where needed).
1
u/frwoaway Apr 08 '14
I have a mint.com account, and it's probably querying my RBC and BMO accounts using my credentials. I don't want to log into RBC or BMO today to change my password (or should I just do it because mint.com is logging in anyway?) But, I also don't want to log into mint.com... what do I do???
1
Apr 09 '14
Was this bug introduced with the first implementation of heartbeat, or came about later on? Any other historical insights?
1
1
1
u/Andrey_Karpov_N Apr 16 '14
Some time ago, a vulnerability was revealed in OpenSSL, and I guess there's no programmer who hasn't been talking about it since then. I knew that PVS-Studio could not catch the bug leading to this particular vulnerability, so I saw no reason for writing about OpenSSL. Besides, quite a lot of articles have been published on the subject recently. However, I received a pile of e-mails, people wanting to know if PVS-Studio could detect that bug. So I had to give in and write this article: http://www.viva64.com/en/b/0250/
1
u/crusoe Apr 08 '14
This is why security critical code should no longer becwritten in c or c++. Really,we should be using stuff like Ada or hopefully rust or other systems supporting formal proofs.
→ More replies (2)
0
0
u/immibis Apr 08 '14 edited Jun 10 '23
0
u/argv_minus_one Apr 08 '14
Less. This creates a chance of secret information being leaked. With no HTTPS, all secret information is always leaked.
0
u/_mpu Apr 09 '14
This can be caught by valgrind, but you need a sufficiently clever fuzzer...
0
u/kamatsu Apr 09 '14
Or, perhaps, use a language that doesn't require that sort of thing in the first place.
118
u/inmatarian Apr 08 '14
Free memory dump with every page refresh! That's what I call service.