6 ms·
OpenSSL Security Advisory: TLS heartbeat read overrun
- tptacek 12y agoUgh, that's a horrible vulnerability. We found something similar in nginx a few years ago, and the result is that you can repeatedly open up client connections and dump server memory as it changes, revealing keys and, without any real effort, authentication info and cookies.
- conformal 12y agonot sure what you have to maintain, but it sure sucks having to scramble and fix this right away. our (quick) fixes are almost all done: - recompile openssl where necessary (web, chat, mail, windows binaries) without heartbeat support - roll related certs and keys ASAP and then comes the painful process of suggesting all web service users roll their certs and auth. oh, and rotate personal passwords at other sites that issue a warning about openssl...
- grittygrease 12y agoIf your site is protected by CloudFlare (like HN is), you are automatically protected from this vulnerability (see: http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerabilities http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerab...).
- amalcon 12y agoThis is perhaps somewhat misleading. It's possible that this bug was being actively exploited before now, so you should change your keys even if you use a CDN (all the majors have already fixed this as far as I'm aware).
- smtddr 12y agoPerhaps Cloudfare should note that the "up to 64kB" isn't entirely correct. http://heartbleed.com/ http://heartbleed.com/ >>There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed.
- ars 12y agoYou are protected now. But you were not before, so if any attacker figured this out before the public disclosure then you have [possibly] already been attacked and compromised.
- extrapolate 12y agoNot entirely correct, as the blog post states: > We fixed this vulnerability last week before it was made public. Although there's still the other 103 weeks this was vulnerable to worry about.
- dmix 12y agoI had to google what "heartbeat extension" does: DTLS is designed to secure traffic running on top of unreliable transport protocols. Usually such protocols have no session management. The only mechanism available at the DTLS layer to figure out if a peer is still alive is performing a costly renegotiation. If the application uses unidirectional traffic there is no other way. TLS is based on reliable protocols but there is not necessarily a feature available to keep the connection alive without continuous data transfer. The Heartbeat Extension as described in this document overcomes these limitations. The user can use the new HeartbeatRequest message which has to be answered by the peer with a HeartbeartResponse immediately. https://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-01 https://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-01 Edit: here is the commit patching the bug https://github.com/openssl/openssl/commit/7e840163c06c7692b796a93e3fa85a93136adbb2 https://github.com/openssl/openssl/commit/7e840163c06c7692b7...
- nly 12y ago"Don't roll your own parsers" should really be up there with "Don't roll your own crypto". This advisory is scant on details, but this extension protocol[0] neither looks complex nor beyond mechanical code generation to me. Just simple enough to be dangerous. And it's pretty new, so this must be recently authored vulnerable code. [0] http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04 http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04
- eliteraspberrie 12y agoLooks like a good use case for Hammer: https://github.com/UpstandingHackers/hammer https://github.com/UpstandingHackers/hammer
- nly 12y agoLooks interesting, but static code generation along the lines of Ragel (but more oriented toward binary structures like Protocol Buffers) would be a lot better for performance.
- iso8859-1 12y agoHere's the commit for the fix: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...
- osivertsson 12y agoOuch, pretty basic lack of bounds checking. Even though the code got better with this fix I still wouldn't accept code that looks like this in a review. Why are 1, 2, 3, 16 not defines? What's up with the code duplication between files? Where are the unit-tests? I'm starting to feel that a lot of software that has been around for 10+ years and is commonly used does not live up to current best practices regarding writing good system-level software.
- rlpb 12y ago
- gry 12y ago"Heartbleed Bug" Q&A: http://heartbleed.com/ http://heartbleed.com/
- cperciva 12y agoIn case anyone was wondering why I wrote spiped...
- FiloSottile 12y agoTotally agreed on the over-complexity and un-securability of TLS, that too often is deployed where something simpler should be used instead. However, wouldn't OpenSSH be the thing spiped replaces most of the times? And that has a better security track record (I mean, better than OpenSSL for sure).
- cperciva 12y agoA lot of people are doing spiped-like things using stunnel.
- FiloSottile 12y agoOh. Sigh.
- midas007 12y agoBasically, for internal infrastructure, where autossh wont work and/or where something simpler than ssh is desired. So the strawmen arguments about it not replacing TLS is not the point. stud, nginx, stunnel, f5 load balancers and cloudflare will still be needed for now, until 'moxie0 or someone comes up with a viable CA alternative AND something way, way simpler than TLS (brain-hurt ASN1, even with Wireshark).
- atmosx 12y ago> Totally agreed on the over-complexity and un-securability of TLS, that too often is deployed where something simpler should be used instead. What would something simpler, less error-prone which would give the same benefits in a client-server connection? EDIT: Spiped is one, I got it (I'm on it right now and might even use it actually on a side-project), anything else that we should know about? :-)
- peterwwillis 12y ago
- jvehent 12y agoCheck for the extension: $ echo -e "quit\n" | openssl s_client -connect google.com:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1' TLS server extension "heartbeat" (id=15), len=1 This doesn't tell you that the server uses OpenSSL, or that it is vulnerable, simply that it supports the extension.
- mpetrov 12y agoKeep in mind that you have to run this with OpenSSL v1.0.1 and above. Running it on a stock OS X Mavericks install will not detect the extension because v0.9.8 of OpenSSL is installed.
- dmix 12y agoI wrote a bash script to check the top 1000 websites and huge percentage of them responded with heartbeat extension (30-40%): INPUT=websites.csv OLDIFS=$IFS IFS=, [ ! -f $INPUT ] && { echo "$INPUT file not found"; exit 99; } while read rank website do echo "checking $website for heartbeat..." echo -e "quit\n" | /usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1' done < $INPUT IFS=$OLDIFS You can download a list of top 1 million websites from Alexa and Quantcast: http://www.seobook.com/download-alexa-top-1-000-000-websites-free http://www.seobook.com/download-alexa-top-1-000-000-websites... Chinese websites timeout on port 443 so you'll have to skip them.
- claudius 12y agoAt least in my Bash (4.2.25(1)), there seems to be a difference between "2>&1|" and "2>&1 |" – the latter works as expected, whereas the former doesn’t give any output. $ echo -e "quit\n" | openssl s_client -connect chubig.net:993 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1' $ echo -e "quit\n" | openssl s_client -connect chubig.net:993 -tlsextdebug 2>&1 | grep 'TLS server extension "heartbeat" (id=15), len=1' TLS server extension "heartbeat" (id=15), len=1 $ Does anybody know why?
- zrail 12y agoHow does one go about installing this update on Ubuntu? "sudo apt-get upgrade openssl" didn't do it.
- vajorie 12y agoBy either compiling & installing it with -DOPENSSL_NO_HEARTBEATS or waiting for the security fix to be backported by ubuntu devs. http://heartbleed.com/ http://heartbleed.com/
- Andys 12y agoThe fix has now been released by Ubuntu, so you can upgrade via the normal methods (apt-get update && apt-get upgrade)
- specto 12y agoMake sure you check running daemons too... apt-get install debian-goodies; checkrestart
- rlpb 12y agoSee: http://www.ubuntu.com/usn/usn-2165-1/ http://www.ubuntu.com/usn/usn-2165-1/ The binary package name is "libssl1.0.0". You want "sudo apt-get update && sudo apt-get install libssl1.0.0", but I suggest that you take all security and regular updates (or set sources.list to security only updates if you insist). Then you can just run "sudo apt-get update && sudo apt-get dist-upgrade" to pick up all updates, without worrying about package names. If you want to verify if a particular vulnerability is fixed, look in /usr/share/doc/<package>/changelog.Debian.gz. In this case, you want /usr/share/doc/libssl1.0.0/changelog.Debian.gz. In this file, you'll see CVE-2014-0160 mentioned as fixed, which is the universal identifier of this vulnerability.
- ctz 12y agoI wonder how many service providers with big OpenSSL deployments (cloudflare, google, facebook, etc.) will do the sane thing and roll their authenticity keys. I'm guessing zero. (Assuming they are deployed in such a way that their long-term authenticity keys are in the memory space of the network service, and not kept on another system or HSM.)
- Silhouette 12y agoOuch. Does this mean almost every Debian 7 web server out there is probably vulnerable to having its private data for supporting HTTPS compromised? https://security-tracker.debian.org/tracker/CVE-2014-0160 https://security-tracker.debian.org/tracker/CVE-2014-0160 If so, that must be an awful lot of web servers, with a horrendous cost for everyone to buy new certificates etc. if there's no reliable way to determine what if anything was compromised. Would any of our resident security experts like to suggest best practices under such circumstances? (Edit: It looks like the page I linked above has been updated and a patch is going into Wheezy security as I write this.) (Edit 2: Confirmed that Wheezy security updates now include openssl 1.0.1e-2+deb7u5 and related libssl changes.)
- rwg 12y agoAll reasonable certificate authorities will — at no cost — revoke your existing certificate and issue you a new certificate with the same expiration date as your old certificate. You'd just need to send the CA a new certificate signing request created from a newly-generated RSA key pair. If your CA wants you to buy a new certificate to recover from a key compromise, your CA is taking you for a ride, and you should find a less horrible CA to throw your money at.
- 0x0 12y agoI think startssl requires $$$$ to revoke and/or reissue those "free" certs before they expire :-/
- StefanWallin 12y agoIs there another good CA that doesn't charge $$$ for both issuing and revocations?
- 0x0 12y agoI just got a revocation request accepted with no charge there.
- FiloSottile 12y agoIt should really be possible to easily detect what functionalities your deploy of OpenSSL is using and recompile only those.
- mappu 12y agoSo they managed to notify Cloudflare in advance, but not debian/ubuntu security teams?
- justizin 12y agoThey may have had someone involved in the research / identification and fix.
- michh 12y agoAn Ubuntu update would be nice right about now. Outside of disabling everything that uses openssl or compiling a new one manually, there's not much I can do to secure my servers at this moment. Meanwhile, I'm guessing a lot of not so nice people are racing to scan IP ranges for this bug.
- mey 12y agoLooks like this being made publicly listed, they did get this CVE out now (I last checked that link around noon PST) http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-0160.html http://people.canonical.com/~ubuntu-security/cve/2014/CVE-20...
- ars 12y agoDebian already updated: http://www.debian.org/security/2014/dsa-2896 http://www.debian.org/security/2014/dsa-2896 Ubuntu should follow really soon, if not already. Edit: Ubuntu updated: http://www.ubuntu.com/usn/usn-2165-1/ http://www.ubuntu.com/usn/usn-2165-1/
- atmosx 12y agoFreeBSD updated (run the update about 40 minutes ago).
- tlrobinson 12y agoApparent introduction of the bug: https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f8661cb98227a5cbcc0f9f3 https://github.com/openssl/openssl/commit/bd6941cfaa31ee8a3f...
- deleted 12y ago[deleted]
- 0x0 12y agoAre Android or iOS affected? Android seems to ship openssl 1.0. Could a malicious server attack clients? Perhaps expose a browser's cookie jar or other saved passwords in memory? The number of installed openssl clients across all devices and computers must be quite large.
- welder 12y agoYes, the vulnerable code is used by both client and server so any client using openssl is affected.
- biafra 12y agoWhich parts of Android really use OpenSSL to do TLS with this heartbeat feature enabled? The browsers? All Apps running on Dalvik? All apps running on ART?
- hrrsn 12y agoOpenSSL doesn't seem to be installed on my jailbroken iPhone.
- lxgr 12y agoIt seems that Android has dodged this bullet by compiling OpenSSL with NO_HEARTBEATS: https://twitter.com/agl__/status/453472368589942785 https://twitter.com/agl__/status/453472368589942785
- midas007 12y agoIf you'd like to update the keg-only OpenSSL brew on osx, and dont care for legacy and crap: ( export CONFIGURE_OPTS='no-hw no-rdrand \ no-sctp no-md4 no-mdc2 no-rc4 no-fips no-engine'; \ brew install https://gist.github.com/steakknife/8228264/raw/openssl.rb ) Beware, that by default on osx/ios, pretty much everything links to sketchy CommonCrypto or a crusty, quasi-deprecated 0.9.8.
- dijit 12y agoof course, anyone using 0.9.8 is fine.
- anaphor 12y agoIf one were using ASLR would this have mostly mitigated this? (I just rebuilt without the heartbeat extension but I'm curious). Also how exploitable is this?
- ceejayoz 12y agoIs this something I have to worry about as someone who uses AWS ELB SSL offloading? Hard to tell from the docs.
- trapexit 12y agoYes. https://forums.aws.amazon.com/thread.jspa?threadID=149690 https://forums.aws.amazon.com/thread.jspa?threadID=149690
- nicpottier 12y agoNote that until it gets patched, you can go to your ELB config and disable TLS support, which I believe (someone please correct me if not) will protect you from this particular attack. Whether the cure is better than the disease is up to you.
- ccpost 12y agoDisabling TLS in the ELB config seemed to work for me until AWS finishes the patch rollout. (Looks like they're partway on the rollout.)
- redbeard0x0a 12y agoUnfortunately, if you have been using an AWS ELB to terminate SSL traffic, they are vulnerable to this particular exploit. See this forum post: https://forums.aws.amazon.com/thread.jspa?threadID=149690 https://forums.aws.amazon.com/thread.jspa?threadID=149690
- zurn 12y agoGo C! Hope everyone had forward secrecy on by now.
- acqq 12y agoAnybody knows if the bug can be triggered in OpenSSH (I believe it uses the same lib?)
- mbq 12y agoMost likely no since SSH is a different protocol than TLS.