Update to 1.0.1g, redo all crypto. That is, revoke certs and keys and regenerate.

What? ...As soon as the page loads it&#x27;s right there without having to scroll the page:<a href="http://i.imgur.com/ZwTclan.png" rel="nofollow">http:&#x2F;&#x2F;i.imgur.com&#x2F;ZwTclan.png</a>(What I want now is an exploit.c, PoC.py, pwnSSL.rb, etc... but I guess it would be irresponsible to provide that to the script-kiddies of the interwebz right now)

Writeup was too long. We need to know the short and sweet of what to fix.

What a great writeup. Comprehensive without being overly verbose, answers to &quot;what does this mean?&quot; and &quot;does this affect me?&quot;, and clear calls to action.While I&#x27;m not happy at having to spend my Monday patching a kajillion machines, I welcome more vulnerability writeups in this vein.

If you are using a HSM your long-term authenticity key won&#x27;t be in the memory space of the process with openssl inside it. So that should be OK.However, everything else in that process (like, all the traffic you were hoping to protect) is basically toast.

Whoa, this seems horrifying.One (selfish) question I have is whether this can affect primary key material stored in an HSM. I&#x27;m assuming not, but that the session key generated by the HSM would still be susceptible.

Likewise for Ubuntu 13.10: OpenSSL 1.0.1e 11 Feb 2013And the current beta of 14.04: OpenSSL 1.0.1f 6 Jan 2014

RHEL6 update announcement<a href="https://rhn.redhat.com/errata/RHSA-2014-0376.html" rel="nofollow">https:&#x2F;&#x2F;rhn.redhat.com&#x2F;errata&#x2F;RHSA-2014-0376.html</a>

I&#x27;ve built RPMs for 1.0.1g for CentOS 6. Based of 1.0.1e source rpms. <a href="https://www.dropbox.com/sh/7s1fiuvfwma16ra/iSz3Jfh1o-" rel="nofollow">https:&#x2F;&#x2F;www.dropbox.com&#x2F;sh&#x2F;7s1fiuvfwma16ra&#x2F;iSz3Jfh1o-</a>

Yeah, I haven&#x27;t seen any new RPMs for RHEL&#x2F;CentOS&#x2F;Fedora yet. Kinda concerning, since I&#x27;d expect vendors to be given advance notice and the chance to prep updates to coincide with the announcement.All my RHEL5 boxes are running 0.9.8, though, at least.

Unless you installed the macports version, which is 1.0.1f

Not affected directly on Mac OS:<pre><code> OpenSSL 0.9.8y 5 Feb 2013</code></pre>

apt-get update &amp;&amp; apt-get -t testing install openssl yields OpenSSL 1.0.1f on Debian sigh

To be clear, the Gentoo package is only in unstable. It hasn&#x27;t reached stable yet. (<a href="https://bugs.gentoo.org/show_bug.cgi?id=507074" rel="nofollow">https:&#x2F;&#x2F;bugs.gentoo.org&#x2F;show_bug.cgi?id=507074</a>)

It does take time for these things to be tested and deployed. Regardless of severity of bug, distributions must test packages before sending them out to all their users.It would be unfortunate if a new package were to be released immediately only to be soon masked&#x2F;recalled due to unforeseen consequences.Of note, the Gentoo package was bumped approximately 2 hours after the advisory was published.

The Arch package is available in Testing. <a href="https://www.archlinux.org/packages/testing/i686/openssl/" rel="nofollow">https:&#x2F;&#x2F;www.archlinux.org&#x2F;packages&#x2F;testing&#x2F;i686&#x2F;openssl&#x2F;</a>

Ubuntu (and I suppose Debian too), just released a fix in 13.10.

F20 and F19 updates are on their way to the updates repo.<a href="https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc20.1" rel="nofollow">https:&#x2F;&#x2F;admin.fedoraproject.org&#x2F;updates&#x2F;openssl-1.0.1e-37.fc...</a><a href="https://admin.fedoraproject.org/updates/openssl-1.0.1e-37.fc19.1" rel="nofollow">https:&#x2F;&#x2F;admin.fedoraproject.org&#x2F;updates&#x2F;openssl-1.0.1e-37.fc...</a>

A couple more data points:I&#x27;m running Fedora 19 and Arch on my main dev machines&#x2F;VMs and as of this posting are considered up-to-date. Both are vulnerable:<pre><code> [Fedora19] $ openssl version
 OpenSSL 1.0.1e-fips 11 Feb 2013

 [Arch] $ openssl version
 OpenSSL 1.0.1f 6 Jan 2014</code></pre>

I opened a support ticket, and Amazon just responded to say that yes, ELBs are vulnerable. I&#x27;ve posted their reply into that thread.

The forum thread has just been updated with this reply:&quot;We can confirm that load balancers using Elastic Load Balancing SSL termination are vulnerable to the Heartbleed Bug (CVE-2014-0160) reported earlier today. We are currently working to mitigate the impact of this issue and will provide further updates.&quot;

That is my concern as well. We are still running CentOS 6.4 which does not have the affected version of OpenSSL, but we terminate SSL at the ELB so if they are affected then are keys are not safe.Edit: I&#x27;ve posted on the support forum, hopefully they get back to us <a href="https://forums.aws.amazon.com/thread.jspa?threadID=149690" rel="nofollow">https:&#x2F;&#x2F;forums.aws.amazon.com&#x2F;thread.jspa?threadID=149690</a>

Rackspace guy here. We have been digging in and it appears that we did have the impacted version of openssl installed but the heartbeat extension was disabled. Regardless, we have updated everything on the Cloud Load Balancer side to 1.0.1g. I will update here if we find anything different.

Likewise, same question for Rackspace&#x27;s Cloud LBs.

Our AWS ELBs were compromised, but an hour or so ago we checked again and they were good. Now to regen the certs...

Does anyone know how Amazon&#x27;s Elastic Load Balancers are affected? I can&#x27;t find anything on the AWS site

Yes, this has been introduced in the original heartbeat extension commit (01-01-2012):<a href="http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=bd6941cfaa31ee8a3f8661cb98227a5cbcc0f9f3" rel="nofollow">http:&#x2F;&#x2F;git.openssl.org&#x2F;gitweb&#x2F;?p=openssl.git;a=commit;h=bd69...</a>

I&#x27;m very curious to see the change that introduced the bug in the first place. According to the announcement it was introduced in 1.0.1. That&#x27;s the version that added Heartbeat support, so maybe it was a bug from the beginning.

Probably to make it more clear what you&#x27;re referring to, and double-check yourself.  There are probably components that are 1 byte, 2 bytes, and 16 bytes long.  Writing it out makes it clear and eliminates a chance for human error in the sum, more than a magic 19 does.  (I guess 16 is pretty magical too, though.  At least it&#x27;s a &quot;round&quot; number, and in context may be a well-known field size of something in the protocol.)

Those numbers probably have some significance. `1` seems to be  &quot;heartbeat type&quot; and `2` seems to be &quot;heartbeat length&quot;.

if (1 + 2 + 16 &gt; s-&gt;s3-&gt;rrec.length)I don&#x27;t know C well - why write 19 like this?

Here&#x27;s the patch&#x2F;commit, I don&#x27;t know why it&#x27;s not linked form the OpenSSL changelog or heartbleed.com. A suspicious lack of transparency.<a href="http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3" rel="nofollow">http:&#x2F;&#x2F;git.openssl.org&#x2F;gitweb&#x2F;?p=openssl.git;a=commitdiff;h=...</a>

Remember to add it to &#x2F;etc&#x2F;portage&#x2F;package.use for a permanent fix (unless you use ~arch for which 1.0.1g is now available).

gentoo has a flag for the TLS heartbeat, so its easy to turn off.root# USE=&#x27;-tls-heartbeat&#x27; emerge openssl

If you&#x27;re running a vulnerable version of OpenSSL and want to be truly careful, assume your private keys (not just certs) are already compromised. Once new packages are available, you need to update and then re-roll your crypto.Also, if you&#x27;re using those keys to protect other secrets like passwords - say, DB credentials or AWS keys stored in an HTTP-hosted Git repo behind - you can&#x27;t really assume those are safe either.Fun times!

Great writeup but I guess I&#x27;m still a bit confused.  As someone responsible for rails servers I can see that I need to update nginx and openssl as soon as packages become available or compile myself.  What about keys though? Do I need to get our SSL certs re-issued? regenerate SSH keys? Anything else that I should be doing?

Does sshd only use TLS&#x2F;OpenSSL &quot;for crypto primitives&quot;? Or not use OpenSSL at all?

Sooo in layman&#x27;s terms - we only need to be worrying about HTTPS and not SSH ?

Ok, so is TLS Heartbeat accessible in every service that uses TLS?The big one that comes to mind aside from https is smtp&#x2F;tls, e.g. port 587Edit: Apparently a PoC on STARTTLS has already been written, so smtp&#x2F;tls is definitely vulnerable

The bug is in the handling of the TLS protocol itself (actually, in a little-used extension of TLS, the TLS Record Layer Heartbeat Protocol), and isn&#x27;t exposed in applications that just use TLS for crypto primitives.

Does SSH (specifically sshd) on major OSes use affected versions of OpenSSL? [answer pulled up from replies below: since sshd doesn&#x27;t use TLS protocol, it isn&#x27;t affected by this bug, even if it does use affected OpenSSL versions]What&#x27;s the quickest check to see if sshd, or any other listening process, is vulnerable?(For example, if &quot;lsof | grep ssl&quot; only shows 0.9.8-ish version numbers, is that a good sign?)

&quot;Is there a bright side to all this?&quot;&quot;Yes, we can sell you our software!&quot;

It was - registered 2 days ago by Marko Laakso from Codenomicon, the guys credited (by themselves it seems !) with finding the bug:<a href="http://www.networksolutions.com/whois/results.jsp?domain=heartbleed.com" rel="nofollow">http:&#x2F;&#x2F;www.networksolutions.com&#x2F;whois&#x2F;results.jsp?domain=hea...</a>

I&#x27;d be surprised if heartbleed.com was still available in 2014

Are people going straight to buying new domain names for every TLS bug discovered these days?

Thanks for the links. The big thing heartbleed.com is missing is what to do!

Basically yes. However, from my experience, package update urgencies are no good indicator of the updates&#x27;s actual priority.
It&#x27;s in the +*-security&quot; channels and you&#x27;re supposed to apply all updates from there.

Should the priority on the ubuntu-security page be higher than &quot;Medium&quot;?

OpenSSH != OpenSSL. Those upgrades are for a different vulnerability in OpenSSH.

Just got an openssl upgrade pushed by Ubuntu 12.04 as well.

I just did a apt-get update and apt-get upgrade and I saw upgrades for openssh-client and openssh-server.

1.0.1e-2+deb7u5	appearing now on security.debian.org.

Just saw the following updated when I did an &#x27;apt-get clean; aptitude dist-upgrade&#x27; on Debian Wheezy:libssl1.0.0 openssh-client openssh-server openssl ssh

You need to manually restart all processes linking libssl, too.Something like &quot;lsof -n | grep ssl | grep DEL&quot; can identify processes using the DELeted old version of libssl after apt-get upgrading.

Just received an upgrade on Ubuntu 12.04 LTS as well, apt-get clean issued before updating.EDIT: If you are using DigitalOcean, the update is not yet on their mirrors. Issue &#x27;sudo sed -i &quot;s&#x2F;mirrors\.digitalocean&#x2F;archive.ubuntu&#x2F;g&quot; &#x2F;etc&#x2F;apt&#x2F;sources.list;sudo apt-get clean;sudo apt-get update;sudo apt-get upgrade&#x27; to get the patch. Check the comment by 0x0 above ( <a href="https://news.ycombinator.com/item?id=7549842" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7549842</a> ) to find any services which need restarting.

I just installed update openssl_1.0.1e-2+deb7u5 and libssl1.0.0_1.0.1e-2+deb7u5 on debian wheezy, so it seems the fix is now available.

Ubuntu 12.04 patch ready <a href="https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12" rel="nofollow">https:&#x2F;&#x2F;launchpad.net&#x2F;ubuntu&#x2F;+source&#x2F;openssl&#x2F;1.0.1-4ubuntu5....</a>

As of now (21:04 UTC) this isn&#x27;t fixed in Debian <a href="https://security-tracker.debian.org/tracker/CVE-2014-0160" rel="nofollow">https:&#x2F;&#x2F;security-tracker.debian.org&#x2F;tracker&#x2F;CVE-2014-0160</a> nor Ubuntu <a href="http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-0160.html" rel="nofollow">http:&#x2F;&#x2F;people.canonical.com&#x2F;~ubuntu-security&#x2F;cve&#x2F;2014&#x2F;CVE-20...</a>Got a long night ahead :&#x2F;

Figured there might be more than just that flag you&#x27;d want to compile with.

says how to on the official notice: <a href="http://www.openssl.org/news/secadv_20140407.txt" rel="nofollow">http:&#x2F;&#x2F;www.openssl.org&#x2F;news&#x2F;secadv_20140407.txt</a><pre><code> recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS</code></pre>

Can some people who are smarter than me give us the flags we would like to compile this with manually?

How widely implemented is certificate revocation?

From what I understood, an attacker could get 64Kb chunks per one request.

The original article says:Can attacker access only 64k of the memory?
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....so I guess the answer to 2 is only limited by how frequently you can change the heartbeat settings, and how frequently OpenSSL will send a heartbeat packet.

One obvious - if slightly paranoid - answer is that this was a deliberate backdoor. There appears to be a length field specific to the heartbeat packet that&#x27;s used to determine how much data from the original packet is included in the response, isn&#x27;t checked against the actual packet length, and allows lengths up to 64k which is unnecessarily generous for the intended purpose but very useful for this attack.

Thanks. That lines up with what I&#x27;ve seen elsewhere too. I think the main thing I was missing was that this is not a sniffing attack, but rather an active attack where you talk to a peer over SSL and basically trick it into sending you some content from its memory.

I&#x27;ll give it a shot. Quoting a poster above.&gt;&gt;&gt; TLS heartbeat consists of a request packet including a payload; the other side reads and sends a response containing the same payload (plus some other padding).So, what happens is that the payload comes in as a pointer and a size (up to 64kb). The server then prepares a response and copies the memory block [pointer, pointer+payloadSize] into the request.The attack happens when the payload is smaller than the payload size passed in the request. This results in the response preparation dumping the memory block [pointer+realPayloadSize, pointer+payloadSize] into the response.Any data in this block is now exposed to the callee; and could contain any data from the process.

I don&#x27;t quite understand how this bug works. I would appreciate any input from someone knowledgeable.It sounds like the heartbeat code is sending some data in the handshake. That data should be harmless (padding? zeroes?) but the bug results in reading off the end of an array and from whatever other data happens to be there. Someone sniffing the connection can then see those bytes fly by. If they happened to contain private info, game over.Is that a correct read on the situation? If so, my followup questions are: 1) Why is there any extra data being sent at all beyond a simple command to &quot;heartbeat&quot;? 2) How much data is being leaked here and at what rate? Is it a byte every couple of hours, is it kilobytes per minute, or what?I am particularly interested in #1, since that&#x27;s the part I really don&#x27;t get at the moment. I suspect the answer to #2 will be implied by the answer to #1.

In addition to that, it obviously disables the TLS heartbeat extension, which would break existing code that uses it.

&gt; Recovery from this bug could benefit if the new version of the OpenSSL would both fix the bug and disable heartbeat temporarily until some future version... If only vulnerable versions of OpenSSL would continue to respond to the heartbeat for next few months then large scale coordinated response to reach owners of vulnerable services would become more feasible.This sounds risky to me. I&#x27;m afraid attackers would benefit more from this decision than coordinated do-gooders.

Answers in sibling threads suggest ssh&#x2F;sshd is not affected, as ssh uses its own protocol other than TLS.

You&#x27;ll need to replace them ASAP, once github updated their version of ssh . But if they run on 0.9.8 branch, you don&#x27;t have to worry.

No, but your github.com password may be compromised.

Is it a problem for those using ssh keys on github ?

That&#x27;s not correct. One of the individuals who discovered the bug contacted us as a large provider of SSL termination services. We were asked not to further disclose the details until it was officially patched and announced by OpenSSL. The official announcement occurred today after which we put up a post to let our customers know that they were protected.

I believe the reason they got access was one of their customers found it and reported it to them, and they reported it to OpenSSL, and then it somehow leaked (either with the OSSL release, or someone else) and then they posted their now-public writeups of it.

How did Cloudflare get access to this bug a week before it was made public, yet no distro has a package ready?How&#x27;s that for responsible disclosure?

they did not try to &quot;weaken RSA&quot;, as in the RSA algorithm. They paid off and&#x2F;or infiltrated RSA the corporation. You were not attacked, your posts simply contained wrong information and useless speculation.Screaming about the NSA every time a security bug comes up is not interesting, productive, insightful, or useful, please stop.

It is evil to make totally unsupported accusations, even against the NSA. I&#x27;ve downvoted you, twice.

I knew I was going to be attacked for saying this, but isn&#x27;t it a real possibility? We already know that they tried to weaken RSA.

It&#x27;s not an accusation, it&#x27;s a speculation. I don&#x27;t have the ability to judge it for myself, i.e. &quot;a simple review of the code change&#x2F;patch&quot;. That&#x27;s why I put it out there. I don&#x27;t mind being refuted, but I wish it would be refuted rather than just downvoted blindly.P.S. I think your quote doesn&#x27;t capture the situation properly when someone is known to have malicious intent.

I don&#x27;t know -- why don&#x27;t you try reasoning it out since you&#x27;re the one lobbing the accusation. Upon a very simple review of the code change&#x2F;patch, one can see this is a relatively new feature, agreed upon and passed by the publicly available IETF, implemented naively.&quot;Never attribute to malice that which can be adequately explained by incompetence&quot; -- slightly-butchered quote, from someone smarter than me.

I don&#x27;t think so - while the NSA would dearly like to have the access that this vulnerability would allow, they would dislike even more if anyone could have it. If they&#x27;re going to insert a backdoor they&#x27;re going to be damn sure only they have the key.

Any chance this bug originated with the NSA? It seems like it would fall under their goal of subverting the infrastructure that keeps secrets on the internet. Of course this is exactly why such a goal is a bad idea - an unprotected internet causes widespread damage.

Shouldn&#x27;t Perfect Forward Secrecy protect against exactly this kind of scenario where the server&#x27;s primary keys are compromised?

Not again. GAH. I just did this after GnutlsGate.

How do you suggest going about finding out if a bank updated the OpenSSL version in its DMZ?

Worse, it&#x27;s retroactively unfixableThat&#x27;s slightly misleading. Every private key disclosure leads to decryption of past traffic unless forward secrecy is used.However, if you switch to a fixed version of OpenSSL now, then an attacker cannot retroactively exploit this bug even if they have recorded all your past traffic, because exploiting the bug requires a live connection.(Of course, this only applies to attackers who did not know about the bug before it was publicly released, so some worry is still justified. I only wanted to point out that the &quot;retroactively unfixable&quot; is a misleading exaggeration.)

Worse, it&#x27;s retroactively unfixable: Even doing all this [revoking certs, new secret keys, new certificates] will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption.So it would be a good idea to change all your passwords to critical services like email and banks, once they have issued new certs and updated their openssl.

It&#x27;s extremely easy to exploit once it is known. The question is simply: Did people know about it and not disclose so they could keep exploiting it?

&gt; And what does this imply?To me, this implies that it&#x27;s not too easy to exploit, or we would&#x27;ve seen it fixed much sooner.

This thing has been in the wild for two years. What are the odds it hasn&#x27;t been systematically abused? And what does this imply?To me it sounds kind of like finding out the fence in your backyard was cut open two years ago. Except in this case the backyard is two thirds of the internet.

Sidenote, OS X machines, by default, are not affected by this bug.$ openssl version -a
OpenSSL 0.9.8y 5 Feb 2013

Web browsers all by default use other crypto libraries. (Chromium can be linked to OpenSSL, some distros may ship this — I haven&#x27;t looked.)Email clients may be more vulnerable — Thunderbird doesn&#x27;t, Mail.app doesn&#x27;t, but I&#x27;m unaware what most use.

Imagine you&#x27;ve got a script that, among other things, does a &#x27;wget&#x27; against some innocent plain HTTP URL. But an attacker intercepts your request, and redirects you to an HTTPS URL of their choosing.Yes, wget uses OpenSSL, and follows redirects silently by default.Now that server uses heartbleed to x-ray your client process memory, collecting all sorts of confidential information, including perhaps credentials to other services.This bug has a lot of nasty, unintuitive permutations and repercussions that will take time to fully grasp.

How would a client be compromised? I mean I guess a malicious server could send these bad heartbeat packets and sniff the keys, but if the server is pwned then your secrets are already revealed, right?

What popular SSL client software uses the vulnerable OpenSSL? (Any web browsers, for example on popular linuxes? How about &#x27;curl&#x27; when connecting to HTTPS sites?)

Isn&#x27;t there any memory protection on Linux? Something running as www-data shouldn&#x27;t be able to read the ssh-server&#x27;s RAM?So it&#x27;s bad, but it&#x27;s not that bad unless something exposing this bug (webserver with ssl, vpn, or other service) runs as root?

Unless you used forward secrecy, which you should anyway in case of a key compromise. Key compromises can happen in many ways.

Oh it&#x27;s even worse, basically every secret you had in your server processes&#x27; RAM was potentially read in real-time by an attacker for the last 2 years.

Holy shit. That seems worse than the debian openssl debacle.If i got that right ALL openssl private keys are now potentially compromised.I hope vendors push fixes soon, and then I guess I&#x27;m busy for a few days regenerating private keys.

This is the standard command:<pre><code> $ openssl version

 &gt; OpenSSL 1.0.1f 6 Jan 2014</code></pre>

On my CentOS boxes I ran &#x27;yum list | grep openssl&#x27;

Agreed. They should reorder their headings, first should be What is it? and second should be How to stop it?

Ok, anyone could assist me on how to update openssl without breaking anything? I&#x27;ve fetched newest sources from openssl.org and compiled them, but &quot;make install&quot; doesn&#x27;t actually install it, it only got compiled, but issuing &quot;openssl version&quot; still gives me the old version.What I want to do is to patch it so our webserver uses new version.

Not to sound like a commercial for Cloudflare or anything. But putting your infrastructure behind their services can protect users while they perform their patching. According to their latest blog post <a href="http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerabilities" rel="nofollow">http:&#x2F;&#x2F;blog.cloudflare.com&#x2F;staying-ahead-of-openssl-vulnerab...</a>

Agree. This needs a big fat the world is coming to an end stlye of warning.I&#x27;ve just shut down the webservers running SSL that I can control.
If you are vuln and don&#x27;t want to build openssl from source and can afford the outage. I&#x27;d reccomend to do the same.OTHERWISE BUILD FROM SOURCE IMMEDIATELY, PATCH, AND GET NEW KEYS!Let&#x27;s hope CA&#x27;s don&#x27;t get swamped by all the CSR&#x27;s. Or rather let&#x27;s hope they do so we see people are doing something...For me right now these are just my hobby projects. So I don&#x27;t care if they&#x27;re down. But I imagine it will be fun tomorrow.And when it&#x27;s fixed, get new keys.Btw: I&#x27;m a dev. Not a sysadmin though :PEdit: Debian is patched. I&#x27;m online again \o&#x2F;

On a linux box:
[For each set of certs used for each of your public facing sites...]1. Open a terminal[cd into] &#x2F;etc&#x2F;path_to_ssl_certs_folder[per site].Ex. &#x2F;etc&#x2F;ssl&#x2F;nginx2. Regen the certs [example nginx mail server]openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:4096 -keyout mailkey.pem -out mailcert.pem[this command generates a private key and server cert and outputs to pem&#x27;s]
[Note also the key sizes are 4096, you may want 2048. AND I use -sha256, as sha1 is considered too weak nowadays. These certs are valid for 3650 days...10 years]Since the command overwrites certs&#x2F;keys in the current directory of the same name as the outfiles...that&#x27;s it...you&#x27;re done. Just restart nginx.If you change a self-signed cert, like above, expect a new warning from the client on the next connection...this is just your new cert being encountered. Click permantly accept..blah blah.------------------------------------------------------------------------On a Windows box:1. open an admin cmd window and run &#x27;mmc&#x27;.2. Add a new snap-in for Certificates as local machine.3. Find and &#x27;Disable all purposes for this cert&#x27;.4. Import your new certs from your 3rd party or that you rolled yourself from your enterprise CA.5. Test new cert.6. Delete old cert.[If you run your own CA, you should already know what to do...]

Given the severity of this bug, the UX of the site is failing anyone who isn&#x27;t a fulltime sysadmin.Suggestion: big, bold TLDR (&quot;The sky is falling. Check your OpenSSL version right now&quot;) with a link on what to do sorted by OS vendor.Step 1:
Here&#x27;s a command to spit out your OpenSSL version. If it is the following string, go to step 2.Step 2:
Here&#x27;s how to update your OpenSSL. Here are links to guides on reissuing keys.Probably OK the whole remediation bit links to a wiki that gets updated as the various vendors push their patches.

Well someone was able to give Cloudflare a heads up last week [1].It would have been nice if the package maintainers could have had time to build ready-to-roll solutions with Heartbeat compiled out prior to the official OpenSSL fix.[1] <a href="http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerabilities" rel="nofollow">http:&#x2F;&#x2F;blog.cloudflare.com&#x2F;staying-ahead-of-openssl-vulnerab...</a>

Because it was already disclosed the instant the OpenSSL release went out and the fix was public.

This doesn&#x27;t sound like &quot;responsible disclosure&quot; to me - how can Codenomicon dump this news when all the major Linux vendors don&#x27;t have patches ready to go ?

Is openssl in nginx statically linked by default? If so: ouch.

I&#x27;ve posted this link in a separate article but I think it is more useful here.
<a href="https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx_configuration_details" rel="nofollow">https:&#x2F;&#x2F;wiki.mozilla.org&#x2F;Security&#x2F;Server_Side_TLS#Nginx_conf...</a>How to build openSSL statically into a source build of Nginx, just finished running this with nginx-1.4.7 and openSSL-1.0.1g and it compiled just fine. You&#x27;ll have to tweak it to your environment of course.

Testing my externally-accessible OpenVPN server revealed that it is indeed vulnerable. I just powered the box off, going to be a long day at work before I can get home and fix it :&#x2F;

It seems that this is likely to impact OpenVPN too, since it uses TLS - <a href="https://openvpn.net/index.php/open-source/337-why-openvpn-uses-tls.html" rel="nofollow">https:&#x2F;&#x2F;openvpn.net&#x2F;index.php&#x2F;open-source&#x2F;337-why-openvpn-us...</a>Using a tls-auth key may help mitigate this (especially if you use UDP) since it should stop anything reaching the TLS handshake layer. <a href="https://openvpn.net/index.php/open-source/documentation/howto.html#security" rel="nofollow">https:&#x2F;&#x2F;openvpn.net&#x2F;index.php&#x2F;open-source&#x2F;documentation&#x2F;howt...</a>

All references I see recommend (for 1.0.1-series) to move to 1.0.1g - but the OpenSSL homepage[0] says that 1.0.1g is a Work in Progress. There is a download[1] link for it though. Anybody have definitive answer for what&#x27;s going on here? It&#x27;s a little confusing.<pre><code> [0] http:&#x2F;&#x2F;www.openssl.org&#x2F;news&#x2F;state.html
 [1] http:&#x2F;&#x2F;www.openssl.org&#x2F;source&#x2F;</code></pre>

This argument came up in the thread from a few years ago. It is quite wrong-headed. I would like to give a clear answer to it:Virtual machines and runtimes may be vulnerable to malicious CODE. That&#x27;s bad. Programs written in unmanaged languages are vulnerable to malicious DATA. That&#x27;s horrible and unmitigatable.Vulns to malicious code are bad, but they may be mitigated by not running untrusted code (hard, but doable in contexts of high security). They are also mitigated by the fact that the runtime or VM is a small piece of code which may even be amenable to formal verification.Vulns to malicious data, or malicious connection patterns, are impossible to avoid. You can&#x27;t accept only trusted data in anything user-facing. Also, these vulnerabilities are spread through billions of lines of application and OS code, as opposed to core runtime&#x2F;VM.

In keeping with the tradition of bad car analogies, that&#x27;s like saying &quot;Driving cars with automatic traction control won&#x27;t make accidents go away, so automatic traction control is pointless&quot;.Languages with bounds checks on array accesses don&#x27;t solve everything, but that doesn&#x27;t mean that they don&#x27;t work. They do remove entire classes of silent failures that can potentially slip through the cracks in C-like languages. VMs aren&#x27;t needed for this -- most of the strongly typed functional languages, D, Go, Rust, and others all compile down to native machine code.Careful API design, discipline, and good coding in C can also mitigate this sort of problem manually, although (like most things in C), it&#x27;s extra work, and needs careful thought to ensure correctness.

VMs generally do not have this type of vulnerability (buffer overrun).Also, most vulnerabilities in (e.g.) the JVM can only be exploited by running malicious code inside the VM. Here, the attacker is supplying data used by OpenSSL, but is not able to supply arbitrary code.

So reducing the attack surface isn&#x27;t a laudable goal in your book, because hey the VM itself can have vulnerabilities so there isn&#x27;t a point? I think the point is that programmers will always make these mistakes and we should limit as much as possible the type of unsafe code that is written to as small an attack vector as possible. You&#x27;re never going to eliminate vulnerabilities, but we sure can try and reduce the likelihood of them occurring. If there is some objective measurement to be made that says this isn&#x27;t the case, i.e. the number of JVM vulnerabilities like this outstrip or is on par with client side vulnerabilities that occur in purely C&#x2F;C++ applications I would love to see it.Ultimately, I think the better answer will ultimately be a language that inherently provides the primitives for safe memory management but that&#x27;s low-level and highly peformant, i.e. Rust or something like it.

If that would work Virtual Machines and runtimes wouldn&#x27;t have vulnerabilities.So uhm. Yeah, that doesn&#x27;t work either.Edit: Btw since HN has this obessions with Tarsnap, it&#x27;s written in C btw. So you should stop obessing about it and downvote me some more.

I&#x27;ve felt that C makes this code easy to write because it makes doing the right thing hard. What you are describing is just a lot of work in C, compared to a language with something akin to Java&#x27;s generics, which are in turn an afterthought in the ML family of languages. What we&#x27;re asking for is not that complicated from a PL standpoint. A generic streams library?Economics plays an invisible part here. Someone writing a library has a limited amount of time to implement some set of features, and to balance that against other needs, like making the code &quot;clean&quot;&#x2F;pretty and secure. In this case, pretty code and secure code are akin. Consumers would likewise have to balance out feature needs with how likely the code is going to explode. What it comes down to is that you aren&#x27;t likely to have secure, stable code in a language that doesn&#x27;t inherently encourage it.It starts to be clearer then, that the more modern, &quot;prettier&quot; languages offer material benefits in their efforts to be more elegant.

It is indeed astonishing how simple-minded this bug is. But these bugs come in all levels of complexity, from simple overstuffed buffers to logical ping-pong that hurts your brain when you try to follow it. We need to get rid of them once and for all. If the whole world can&#x27;t use a certain tool effectively, then the whole world isn&#x27;t broken; the tool is bad.

Thanks for this. How is this reading arbitrary memory locations though? Isn&#x27;t this always reading what is near the pl? As in, can you really scan the entire process&#x27;s memory range this way or just a small subset where malloc (or the stack, whichever this is) places pl?

I agree that this seems like an abstraction for this is missing, but I always have the feeling that what you&#x27;re doing in covering holes in a leaking dam you might get good at it, but you&#x27;ll always have leaks.

This reminds me of what another programmer told me a long time ago when we were discussing C; &quot;The problem with C is that people make terrible memory managers.&quot;.  So true.

I have always detested C (also C++) because it&#x27;s so unreadable... the snippets of code you cite are just so dense ie. a function like n2s() gives pretty much no indication of what it does to a casual reader. Just reading the RFC (it is pretty much written in a C style) gives me the creeps.The RFC doesn&#x27;t mention why there has to be a payload, why the payload has to be random size, why they are doing an echo of this payload, why there has to be a padding after the payload. If this data is just a regular C struct like the RFC makes it out to be (I didn&#x27;t know you could have a struct with a variable size, but apparently the fields are really pointers or it&#x27;s just a mental model and not a real struct).Apparently the purpose of the payload is path MTU discovery. Something that is supposed to happen at the IP layer, but I don&#x27;t know enough about datagram packets. I guess an application may want to know about the MTU as well...I&#x27;m not here to point fingers, I&#x27;m just saying C is a nightmare to me and a reason for me to never be involved with system programming or something like drafting RFC&#x27;s ;-).But if one can argue that C is a bad choice for writing this stuff, then that is not an isolated thing. &quot;C&quot; is also the language of the RFCs. &quot;C&quot; is also the mindset of the people doing that writing. After all, the language you speak determines how you think. It introduces concepts that become part of your mental models. I could give many examples, but that&#x27;s not really the point.And it&#x27;s about style and what you give attention to. To me, that RFC is a real bad document. It starts to explain requirements to exceptional scenario&#x27;s (like when the payload is too big) before even having introduced and explained the main concepts and the how and why&#x27;s.So while you may argue that this is a C problem and not a protocol problem, it is really all related.And you may also say, in response to someone blaming these coders, that blame is inappropriate (and it is) because these are volunteers and they are donating their free time to something to find valuable, the whole distribution and burden of responsibility is, naturally, also part of the culture and how people self-organize and so on.As someone else explained (<a href="https://news.ycombinator.com/item?id=7558394" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7558394</a>) the protocol is real bad but it is the result of more or less political limitations around submitting RFCs for approval. There is no reason for the payload in TLS (but apparently there is in DTLS) but my point is simply this:If you are doing inelegant design this will spill over into inelegant implementation. And you&#x27;re bound to end up with flaws.Rather than trying to isolate the fault here or there, I would say this is a much larger cultural thing to become aware of.

From a quick reading of the TLS heartbeat RFC and the patched code, here&#x27;s my understanding of the cause of the bug.TLS heartbeat consists of a request packet including a payload; the other side reads and sends a response containing the same payload (plus some other padding).In the code that handles TLS heartbeat requests, the payload size is read from the packet controlled by the attacker:<pre><code> n2s(p, payload);
 pl = p;
</code></pre>
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:<pre><code> &#x2F;* Enter response type, length and copy payload *&#x2F;
 *bp++ = TLS1_HB_RESPONSE;
 s2n(payload, bp);
 memcpy(bp, pl, payload);
</code></pre>
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.I find it hard to believe that the OpenSSL code does not have any better abstraction for handling streams of bytes; if the packets were represented as a (pointer, length) pair with simple wrapper functions to copy from one stream to another, this bug could have been avoided. C makes this sort of bug easy to write, but careful API design would make it much harder to do by accident.

I&#x27;m excited about Rust for this reason as well, but in practice I find myself thinking a lot about data moving into and out of various C libraries. The great but inevitably imperfect theory is that those call sites are called out explicitly and should be as limited as possible. It works well but isn&#x27;t a silver bullet. I&#x27;m hopeful that as the language ecosystem matures there will be increasingly mature C library wrappers and (even better!) native, memory-safe, Rust replacements for things.

I&#x27;d disagree about C++. In my experience, the only things it adds is (1) a false sense of security (since the compiler will flag so many things which are not really big problems, but will happily ignore most overrun issues), (2) lots of complicated ways to screw up, such as not properly allocating&#x2F;deleting things deep in some templated structure, and (3) interference with checking tools - I got way more false positives from Valgrind in C++ code than in C.I wish godspeed to Rust and any other language which doesn&#x27;t expose the raw underlying computer the way C&#x2F;C++ does, which is IMO insane for application programming.

That&#x27;s why I have high hopes for Rust. We really need to move away from C for critical infrastructure. Perhaps C++ as well, though the latter does have more ways to mitigate certain memory issues.Incidentally, someone on the mailing list brought up the issue of having a compiler flag to disable bounds checking. However, the Rust authors were strictly against it.

If you have a char* buf; block you got from network stack and you have to copy buf[3] bytes from the position buf+15 then the compiler doesn&#x27;t know what to check for if you don&#x27;t cross the boundary of that buffer.

Unrestricted pointer arithmetic is indeed incompatible with memory safety. You set a pointer to point to one structure, then you change it and it now points to another structure or array. The compiler doesn&#x27;t know the semantics of your code, so how can it tell if you meant to do that? And malloc&#x2F;memcpy is way too low to check this stuff. It only sees memory addresses; it has no idea what variables are in them. Tightly coupled would mean passing information like &quot;variable secret_key occupies address such-and-such&quot; into the libc, which does violate POSIX standards, and will result in lots of code breaking. I don&#x27;t see why we wouldn&#x27;t just write in C# or Java or Rust, instead of a memory-safe subset of C (and it would have to be a subset).Edit: here&#x27;s one project for making a memory-safe C: <a href="http://www.seclab.cs.sunysb.edu/mscc/" rel="nofollow">http:&#x2F;&#x2F;www.seclab.cs.sunysb.edu&#x2F;mscc&#x2F;</a> . Interesting, but (a) it is a subset of C, (b) it doesn&#x27;t remove all vulnerabilities, and (c) I still don&#x27;t grok the advantage of using this over a language actually designed for modern, secure application programming.

C language environments that worked like this have been commercially available in the past: Saber-C in the &#x27;90s, and perhaps earlier, was one example.One problem is that the obvious implementation technique is to change the representation of pointers (to include base and bounds information, or a pointer to that), which means that you need to redo a lot of the library as well. (Or convert representations when entering into a stock library routine, and accept that whatever it does with the pointer won&#x27;t get bounds-checked.)But it&#x27;s certainly doable.

I implemented this once in my C interpreter picoc. Users hated it because it also prevented them from doing some crazy C memory access tricks, so I ended up taking it out.

Oncoming Intel memory protection extensions: 
<a href="http://software.intel.com/en-us/articles/introduction-to-intel-memory-protection-extensions" rel="nofollow">http:&#x2F;&#x2F;software.intel.com&#x2F;en-us&#x2F;articles&#x2F;introduction-to-int...</a>&quot;Intel MPX is a set of processor features which, with compiler, runtime library and OS support, brings increased robustness to software by checking pointer references whose compile time normal intentions are usurped at runtime due to buffer overflow.&quot;

I think clang&#x27;s AddressSanitizer gets pretty close to what you want.  It misses some tricky cases on use-after-return, but other than that it offers pretty robust memory safety model for bounds checks, double free, and so on.

Nothing in the standard prevents a C compiler + tightly coupled malloc implementation from implementing bounds checks. Out-of-bounds operations result in undefined behavior, and crashing the program is a valid response to undefined behavior. If your malloc implementation cooperates, you can even bounds-check pointer arithmetic without violating calling conventions.It&#x27;s quite a shame that there isn&#x27;t a compiler that does this, and it&#x27;s a project I&#x27;ve considered spending some time on if I can find a big enough block of that to get a solid start.

They are still making breaking changes to the language so I really doubt it.

Why port all the security vulns over to Rust? There are already a handful of SSL implementations, it isn&#x27;t horribly hard to do. Maybe start with <a href="http://hackage.haskell.org/package/tls" rel="nofollow">http:&#x2F;&#x2F;hackage.haskell.org&#x2F;package&#x2F;tls</a>

Is anyone working on an OpenSSL port in rust, which lacks the memory vulnerabilities of C?

Why not write the code in C# (for example) and extract it to $SYSTEM_PROGRAMMING_LANGUAGE? It wouldn&#x27;t be much different than what Xamarin are doing now for creating iOS and Android apps with C#.

&gt;Additionally, although the parsing portions of OpenSSL need not deal with the hardware directly, the crypto portions do. So your memory-safe language needs some first-class escape hatch to unsafe code. A few of them do have this, others not so much.For the other points there is some debate, but don&#x27;t most serious languages have a C FFI?

I believe Haskell could be up to the job, but I heard that there were some difficulties in guarding against timing attacks. However those could have just been noise. I know that a functional (I believe and haha) operating system was made in Haskell.Aren&#x27;t Operating Systems lower level than OpenSSL?

We might be stuck with C for quite a while but then maybe the more interesting question is &#x27;how does this sort of thing get past review?&#x27;. It&#x27;s not hard to imagine how semantic bugs (say, the debian random or even the apple goto bug) can be missed. This one, on the other hand, hits things like &#x27;are the parameters on memcpy sane&#x27; or &#x27;is untrusted input sanitized&#x27; which you&#x27;d think would be on the checklist of a potential reviewer.

First, I do realize that rewriting the software stack from the ground up to have only managed code is a huge task. I do think that as an industry, we should set a goal of having at least one server implementation along these lines (where &#x27;set a goal&#x27; may mean, say, grants or calls for proposals). Microsoft Research implemented an experimental OS like that, although it probably didn&#x27;t have all the features a modern OS would need. I don&#x27;t know if we need a new language, but we do need a huge rethink of the server architecture, and not just a piece-by-piece rewrite, which I think will founder on the interface issues that you mentioned.Anyway, I am quite realistic about the prospect of my comment having that kind of effect on the industry - I don&#x27;t suffer from delusions of grandeur. I was aiming the comment more at people who choose C&#x2F;C++ for no good reason to write a user-level app; that app is nearly certain to have memory use errors, and if it has any network or remote interface, chances are they can be easily exploited. I&#x27;d like as many people as possible to understand that they can&#x27;t expect to avoid such errors, any more than one of the most heavily audited pieces of software avoided them. We have had decades of exploits of this vulnerability, and yet most programmers are oblivious to it, or think only bad programmers are at risk. So just as tptacek goes around telling people not to write their own crypto, I go around telling people - with less authority and effectiveness, unfortunately - not to write C&#x2F;C++ code unless they really need to.As for the performance issues forcing OpenSSL to use C, well, we apparently exposed all our secrets in the pursuit of shaving off those cycles. I hope we are happy.

How about Ada? It is time tested! GNU&#x27;s Ada shares the same backend as GCC so it can be pretty fast. Good enough for DoD. =PEdit: I say this having used VHDL quite a bit. I appreciate its type strictness and ranges.

&gt;This sort of argument is becoming something of a fashion statement amongst some security people.Just the ones who don&#x27;t understand how good API designs can work well to solve these problems, don&#x27;t worry not all of us are like that :)

Other than C there is also C++ and D if you don&#x27;t want to stray to far from C. The problem with C++ is that even though it is possible to adapt to a memory safe programming style with C++ the concepts are not prevalent in the community.

What about ADA?  GNAT looked pretty good a few years back when I was trying to get into that sort of thing.

There are several languages that do fill that gap, but security people never use it. For example, Cyclone is pretty good. (<a href="http://cyclone.thelanguage.org/" rel="nofollow">http:&#x2F;&#x2F;cyclone.thelanguage.org&#x2F;</a>).

&quot;Rust has a lot of promise, but even now it keeps changing every other week...&quot;A larger problem, in my opinion, is that things like OpenSSL are used (And should be!) from N other languages. As a result, calling into the library requires almost by definition lowest-common denominator interfaces. Which is C.C code calling into Rust can certainly be done, but I believe it currently prohibits using much of the standard library, which also removes a lot of the benefits.C++ doesn&#x27;t, I think, have as much of a problem there, but I&#x27;m somewhat skeptical of C++ as a silver bullet in this case.I don&#x27;t know about Ada and any other options.[ATS, anyone?]

What you say can easily be disproved, and you are simply asking for too much if you ask for something to be a drop-in replacement for OpenSSL. Some re-architecting is requred simply because of the insecurity of C.For example, a shared library that implements SSL would have to be a shim for something living in a separate process space.<a href="http://hackage.haskell.org/package/tls" rel="nofollow">http:&#x2F;&#x2F;hackage.haskell.org&#x2F;package&#x2F;tls</a>That is a Haskell implementation of TLS. It is written in a language that has very strong guarantees about mutation, and a very powerful type system which can express complex invariants.Yes, crypto primitives must be written in a low level language. C is not low level enough to write crypto, neither securely nor fast, so that&#x27;s not an argument in its favor.

This sort of argument is becoming something of a fashion statement amongst some security people. It&#x27;s not a strictly wrong argument: writing code in languages that make screwing up easy will invariably result in screwups.But it&#x27;s a disingenuous one. It ignores the realities of systems. The reality is that there is currently no widely available memory-safe language that is usable for something like OpenSSL. .NET and Java (and all the languages running on top of them) are not an option, as they are not everywhere and&#x2F;or are not callable from other languages. Go could be a good candidate, but without proper dynamic linking it cannot serve as a library callable from other languages either. Rust has a lot of promise, but even now it keeps changing every other week, so it will be years before it can even be considered for something like this.Additionally, although the parsing portions of OpenSSL need not deal with the hardware directly, the crypto portions do. So your memory-safe language needs some first-class escape hatch to unsafe code. A few of them do have this, others not so much.It&#x27;s fun to say C is inadequate, but the space it occupies does not have many competitors. That needs to change first.

&gt;The problem with C is that a lot of people don&#x27;t write it well.There are languages that make it very very hard to write bad code. Haskell is a good example of where if your program type-checks, there&#x27;s a high chance it&#x27;s probably correct.C is a language that doesn&#x27;t offer many advantages but offers very many disadvantages for its weak assurances. Things like the Haskell compiler show that you can get strong typing for free, and there&#x27;s no longer many excuses to run around with raw pointers except for legacy code.

Agreed. Simple code is easy to understand and just as easy to find any bugs in. After looking at the heartbeat spec and the code, I can already see a simplification that, had it been written this way, would&#x27;ve likely avoided introducing this bug. Instead of allocating memory of a new length, how about just validating the existing message fields as per the spec:&gt; The total length of a HeartbeatMessage MUST NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066].&gt; The padding_length MUST be at least 16.&gt; The sender of a HeartbeatMessage MUST use a random padding of at least 16 bytes.&gt; If the payload_length of a received HeartbeatMessage is too large, the received HeartbeatMessage MUST be discarded silently.Then if it&#x27;s all good, modify the buffer to change its type to heartbeat_response, fill the padding with new random bytes, and send this response. No need to copy the payload (which is where the bug was), no need to allocate more memory.(Now I&#x27;m sure someone will try to find a flaw in this approach...)

My favorite is that  the Morris worm dates back to late 1988 when MS was starting the development of OS&#x2F;2 2.0 and NT. Yea, I am talking about the decision to use a flat address space instead of segmented.

&gt; The problem with C is that a lot of people don&#x27;t write it well.Including people responsible for one of the most important security-related library in the world. No matter how good and careful a programmer is, they are still human and prone to errors. Why not put every chance on our side and use languages (e.g. Rust, Ada, ATS, etc.) that make entire classes of errors impossible? They won&#x27;t fix all problems, and definitely not those associated with having a bad code base, but it&#x27;d still be many times better than hoping people don&#x27;t screw up with pointers lifetime.

&gt; C and other languages without memory checks are unsuitable for writing secure codeI vehemently disagree. Well-written C is very easy to audit. Much much moreso than languages like C# and Java, where something I could do with 200 lines in a single C source file requires 5 different classes in 5 different files. The problem with C is that a lot of people don&#x27;t write it well.Have you looked at the OpenSSL source? It&#x27;s an ungodly f-cking disaster: it&#x27;s very very difficult to understand and audit. THAT, I think, is the problem. BIND, the DNS server, used to have huge security issues all the time. They did a ground-up rewrite for version 9, and that by and large solved the problem: you don&#x27;t read about BIND vulnerabilities that often anymore.OpenSSL is the new BIND; and we desperately need it to be fixed.(If I&#x27;m wrong about BIND, please correct me, but AFICS the only non-DOS vulnerability they&#x27;ve had since version 9 is CVE-2008-0122)&gt; but we can plug this seemingly endless source of bugs which has been affecting the Internet since the Morris worm.If we&#x27;re playing the blame game, blame the x86 architecture, not the C language. If x86 stacks grew up in memory (that is, from lower to higher addresses), almost all &quot;stack smashing&quot; attacks would be impossible, and a whole lot of big security bugs over the last 20 years could never have happened.(The SSL bug is not a stack-smashing attack, but several of the exploits leveraged by the Morris worm were)

If you haven&#x27;t seen it already, check out Cryptol from Gallois: <a href="http://corp.galois.com/cryptol/" rel="nofollow">http:&#x2F;&#x2F;corp.galois.com&#x2F;cryptol&#x2F;</a>It&#x27;s a crypto DSL that I believe is implemented in Haskell (it compiles to Haskell, C, C++ and a few others).

Virtually all code exposed to the Internet is security critical, however.

Particularly relevant example: TLS&#x2F;SSL implementation in Haskell.<a href="http://hackage.haskell.org/package/tls" rel="nofollow">http:&#x2F;&#x2F;hackage.haskell.org&#x2F;package&#x2F;tls</a>

Speaking of proofs, how about we write security critical code in haskell? You need a very simple runtime, but beyond that it would work pretty much wherever.Most memory-related bugs are automatically eliminated, and security proofs are easier.

Isn&#x27;t this basically the whole point of QuickCheck-like testing frameworks? They&#x27;re basically a specification that is attempted to be falsified in some way by a fuzzer. I don&#x27;t see why most C projects couldn&#x27;t be doing this.

The defined behaviour would be to discard the packet. In a secure language, the buffer would have had a &quot;length&quot; property, and the code would have crashed when a read beyond the buffer&#x27;s end was attempted. But in C, buffers are just pointers, so there is fundamentally nothing wrong with reading beyond the end of the buffer. So instead of a crash, we get silent memory exposure.

&gt; This vulnerability is the result of yet another missing bound check. It wasn&#x27;t discovered by Valgrind or some such tool, since it is not normally triggered - it needs to be triggered maliciously or by a testing protocol which is smart enough to look for it (a very difficult thing to do, as I explained on the original thread).You could also look at this bug as an input sanitization failure. The author didn&#x27;t consider what to do when the length field in the header is longer than what comes over the wire (even when writing the code in a secure language, this case should be handled somehow, maybe by logging or dropping the packet).

Java, yes, hmmm.. Oh wait, but Java VM is written in C and is a host to some of the worst web browser zero days we know of.Fundamentally, I think we&#x27;re going to have to give up on security and start handing out drivers licenses to anyone who wants to use the internet.

Fortran was not meant to be a systems programming language. The fact that it did not have memory management does actually make sense in scientific applications, where you typically know your problem size in advance or can just recompile before a day long computation.

Agree a bazillion times.Go or Java on top. Coding in C is like juggling chainsaws to say you can juggle them. C is certainly better than old school Fortran where memory management wasn&#x27;t developed until later, but platforms like Erlang, Go and JRuby are really hard to beat.The only problem is convincing people to migrate to different tools and transition codebases to another language. It would take a large project like FreeBSD, LLVM or the Linux kernel to move the needle.

You make good points.However, qmail is written in C and has a very good record. So I would disagree with The fact is that no programmer is good enough to write code which is free from such vulnerabilities.There seem to be at least two programmers who are capable of that.

&quot;The fact is that no programmer is good enough to write code whic is free from such vulnerabilities.&quot;&quot;...you are kidding yourself if you think you can handle this better than the OpenSSL team.&quot;Well, I can think of at least one example that counters this supposition. As someone points out elsewhere in this thread, BIND is like OpenSSL. And others wrote better alternatives, one of which offered a cash reward for any security holes and has afaik never had a major security flaw.What baffles me is that no matter how bad OpenSSL is shown to be, it will not shake some programmmers&#x27; faith in it.I wonder if the commercial CA&#x27;s will see a rise in the sale of certificates because of this.Sloppy programmer blames language for his mistakes. News at 11.

we can plug this seemingly endless source of bugs which has been affecting the Internet since the Morris worm. It has now cost us a two-year window in which 70% of our internet traffic was potentially exposed. It will cost us more before we manage to end it.Could one make a new kind of OS where C programs are compiled to some intermediate representation then when run this is JIT compiled within a managed hypervisor sandbox? Could Chrome OS become something like this? Does this already exist? MS had a managed code OS called Singularity.

&gt; My opinion, then and now, is that C and other languages without memory checks are unsuitable for writing secure code.I think they can be used to write secure code, but it has to be done carefully, with really thorough checks and unit tests, and a constant awareness of the vulnerabilities.Everything I&#x27;ve heard about OpenSSL so far, suggests it was done by a bunch of cowboys who don&#x27;t care about code quality. Those people shouldn&#x27;t be writing C, but a safer language.

I don&#x27;t think C should be blamed for the HeartBleed bug. Please see <a href="http://www.pixelstech.net/article/1397465547-HeartBleed%3A-Should-C-be-blamed-for-the-HeartBleed-bug-" rel="nofollow">http:&#x2F;&#x2F;www.pixelstech.net&#x2F;article&#x2F;1397465547-HeartBleed%3A-S...</a>

There was a discussion here a few years ago (<a href="https://news.ycombinator.com/item?id=2686580" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2686580</a>) about memory vulnerabilities in C. Some people tried to argue back then that various protections offered by modern OSs and runtimes, such as address space randomization, and the availability of tools like Valgrind for finding memory access bugs, mitigates this. I really recommend re-reading that discussion.My opinion, then and now, is that C and other languages without memory checks are unsuitable for writing secure code. Plainly unsuitable. They need to be restricted to writing a small core system, preferably small enough that it can be checked using formal (proof-based) methods, and all the rest, including all application logic, should be written using managed code (such as C#, Java, or whatever - I have no preference).This vulnerability is the result of yet another missing bound check. It wasn&#x27;t discovered by Valgrind or some such tool, since it is not normally triggered - it needs to be triggered maliciously or by a testing protocol which is smart enough to look for it (a very difficult thing to do, as I explained on the original thread).The fact is that no programmer is good enough to write code which is free from such vulnerabilities. Programmers are, after all, trained and skilled in following the logic of their program. But in languages without bounds checks, that logic can fall away as the computer starts reading or executing raw memory, which is no longer connected to specific variables or lines of code in your program. All non-bounds-checked languages expose multiple levels of the computer to the program, and you are kidding yourself if you think you can handle this better than the OpenSSL team.We can&#x27;t end all bugs in software, but we can plug this seemingly endless source of bugs which has been affecting the Internet since the Morris worm. It has now cost us a two-year window in which 70% of our internet traffic was potentially exposed. It will cost us more before we manage to end it.

Someone wrote this: <a href="http://filippo.io/Heartbleed/" rel="nofollow">http:&#x2F;&#x2F;filippo.io&#x2F;Heartbleed&#x2F;</a>

That can false-positive, for what it&#x27;s worth, in servers with fixed TLS heartbeats (instead of removing them).

echo -e &quot;quit\n&quot; | openssl s_client -connect &lt;HOSTNAME&gt;:443 -tlsextdebug 2&gt;&amp;1| [ &quot;` grep -c &#x27;TLS server extension \&quot;heartbeat\&quot; (id=15), len=1&#x27;`&quot; -gt 0 ] &amp;&amp; echo &#x27;Vulnerable&#x27;

Is there a way to tell if a third-party site has patched the bug? (Upgraded to 1.0.1g) Not much point in changing your password on that site before the vulnerability is fixed.

&quot;goto fail;&quot; doesn&#x27;t seem that bad now huh.
Lovely how these GNU&#x2F;Linux freedom fighters were LOLling their asses off earlier, but when it happens to them they sweat themselves and cry for spoon-fed instructions to compile a software package from its sources.- sent from my Mac

UPDATE: I&#x27;ve found one! Shouts to the venerable FiloSottile!<a href="https://github.com/FiloSottile/Heartbleed/blob/master/bleed/heartbleed.go" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;FiloSottile&#x2F;Heartbleed&#x2F;blob&#x2F;master&#x2F;bleed&#x2F;...</a>

Has anybody seen or created a PoC for this yet?

Note that distributions usually don&#x27;t change the library version, they just apply the fix. Look for distribution-specific sub-version.

<a href="https://access.redhat.com/security/cve/CVE-2014-0160" rel="nofollow">https:&#x2F;&#x2F;access.redhat.com&#x2F;security&#x2F;cve&#x2F;CVE-2014-0160</a><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1084875" rel="nofollow">https:&#x2F;&#x2F;bugzilla.redhat.com&#x2F;show_bug.cgi?id=1084875</a>

Apparently Red Hat, Debian, and Ubuntu weren&#x27;t (from what I gather from reading mailing list posts) -- no idea who else.That&#x27;s not responsible at all, IMO. Whoever was in charge of this (NCSC-FI?) isn&#x27;t very good at coordinating.

From the CloudFlare blog: &quot;This bug fix is a successful example of what is called responsible disclosure&quot;.I just discovered this now and<pre><code> yum info openssl
</code></pre>
Yields 1.0.1e as available package which is vulnerable. I guess not all &quot;stakeholders&quot; have been warned properly - or am I jumping to conclusions?

So, many certificate authorities will need to re-issue certificates?

&gt; I would not be surprised if people at the NSA, GHCQ and most state security services are going into overdrive right now to get access to anything and everything that is vulnerable to this bug.I assume the NSA has known about this bug for a long time and has been actively exploiting it.

We really need to see some of the big companies take down their services until they&#x27;ve fixed this and call out for every company out there to audit themselves and confirm to users that this is serious and should be checked and that no service should stay online until they&#x27;ve patched their systems. This should get attention beyond just techies. Business as usual is not acceptable since every day that goes by is the opportunity for someone to take advantage of this and get the keys to your service and all past traffic.I would not be surprised if people at the NSA, GHCQ and most state security services are going into overdrive right now to get access to anything and everything that is vulnerable to this bug.

Ah, the old middle-management excuse: &quot;We don&#x27;t have time to write tests!&quot;

What worries me about this is that the commit that fixes it [0] doesn&#x27;t include any tests. Is that normal in crypto? If I committed a fix to a show-stopper bug without any tests at my day job I&#x27;d feel very amateur.[0] <a href="http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3" rel="nofollow">http:&#x2F;&#x2F;git.openssl.org&#x2F;gitweb&#x2F;?p=openssl.git;a=commitdiff;h=...</a>

There are open support tickets in both Heroku and AWS about the impact of this bug but no answers yet.I hope folks will promote a warning if either platform is effected both on HackerNews and twitter.

I don’t; but I do not know how I could ever be sure. I’m a generalist sys admin and my knowledge of crypto is limited to the basics. That being said my understanding is that this vulnerability is in the code that creates the sessions not in the certificates themselves. The risk is that my key already was compromised when I was using the vulnerable version. For me this means two things:1) There is no easy way for me to confirm or deny the CA is fixed short of attempting to exploit them.2) Even if the CA is not fixed the vulnerability appears to in the routines used for session management not in the SSL certificate itself. While there is cc information and other stuff I would not like to be leaked, the CSR itself only contains my public key not my private key. As long as my servers are patched and I have a SSL cert using a new keypair that I know has not being compromised; I am not sure if the CA&#x27;s version of openssl maters or not.I am in no way trying to pretend I am an expert. I am sure there are problems with my analysis but it still feels like its time to be pragmatic and get a fix in place before asking all the what-ifs. Not that those questions should not be asked but it’s a mater of prioritizing.

How do you know your CA isn&#x27;t vulnerable?

OK well I just updated about 40 servers.  Has anyone started working with CAs to reissue SSL certificates signed with a new key? Are they willing to do the reissue for free? In particular I use RapidSSL for most things and Verisign for a few bigger clients who prefer it.

What are the odds that the NSA didn&#x27;t already know about it? Even if you don&#x27;t think they would have deliberately monkeywrenched OpenSSL (as they are widely believed to have done with RSA&#x27;s BSAFE), they certainly have qualified people poring over widely used crypto libraries, looking for missing bounds checks and all manner of other faults --- quite likely with automated tooling.As to CAs, there have been enough compromises already from other causes that serious crypto geeks like Moxie Marlinspike are trying to change the trust model to minimize the consequences --- see <a href="http://tack.io" rel="nofollow">http:&#x2F;&#x2F;tack.io</a>

Also the NSA gets advanced notice of bugs like this, so they&#x27;ve likely had it for a week. Enough time to steal the SSL keys from some juicy targets.

What are the chances that the NSA is having a field day with this in the 24-48 hours that it will take everyone to respond? Also, is it possible that CA&#x27;s have been compromised to the point where root certs should not be trusted?

Note that this bug affects way more programs than just Tor — expect everybody who runs an https webserver to be scrambling today.&quot;If you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle.&quot; - torProject

Yes, why doesn&#x27;t the same thing exist for SSL? The fact that quark was funded by the NSF means that there is interest in actually doing stuff like this.

You may be interested in Quark, which is a browser kernel written using Coq <a href="http://goto.ucsd.edu/quark/" rel="nofollow">http:&#x2F;&#x2F;goto.ucsd.edu&#x2F;quark&#x2F;</a>

Honestly, why aren&#x27;t the formal verification people jumping on this? I keep hearing about automatic code generation from proof systems like Coq and Agda but it&#x27;s always some toy example like iterative version of fibonacci from the recursive version or something else just as mundane. Wouldn&#x27;t cryptography be a perfect playground for making new discoveries? At the end of the day all crypto is just number theory and number theory is as formal a system as it gets. Why don&#x27;t we have formal proofs for correct functionality of OpenSSL? Instead of a thousand eyes looking at pointers and making sure they all point to the right places why don&#x27;t we formally prove it? I don&#x27;t mean me but maybe some grad student.

The Heartbleed Bug