OpenSSL Bug Allows Attackers To Read Memory In 64k Chunks

Bismillah (993337) writes "A potentially very serious bug in OpenSSL 1.0.1 and 1.0.2 beta has been discovered that can leak just about any information, from keys to content. Better yet, it appears to have been introduced in 2011, and known since March 2012." Quoting the security advisory: "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." The attack may be repeated and it appears trivial to acquire the host's private key. If you were running a vulnerable release, it is even suggested that you go as far as revoking all of your keys. Distributions using OpenSSL 0.9.8 are not vulnerable (Debian Squeeze vintage). Debian Wheezy, Ubuntu 12.04.4, Centos 6.5, Fedora 18, SuSE 12.2, OpenBSD 5.4, FreeBSD 8.4, and NetBSD 5.0.2 and all following releases are vulnerable. OpenSSL released 1.0.1g today addressing the vulnerability. Debian's fix is in incoming and should hit mirrors soon, Fedora is having some trouble applying their patches, but a workaround patch to the package .spec (disabling heartbeats) is available for immediate application.

Comments

Gee, that's worse than no encryption isn't it?

[Anonymous Coward]

"We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication."

Yikes. And it's been known for 2 years. That's some shit!

Re:Gee, that's worse than no encryption isn't it?

[Anonymous Coward]

Existed != Known. Unknown if known until now.

Re:Gee, that's worse than no encryption isn't it?

[Lennie]

"known for 2 years"

No, no, this has been the code part of the stable release of OpenSSL for 2 years. The bug has only been known by non-blackhats for up to a few weeks.

If anyone else like a blackhats or NSA or whoever knew about the bug before hand, we don't know.

Re:Gee, that's worse than no encryption isn't it?

[Anonymuous Coward]

I wonder how used was that heartbeat extension.

Was it automatically enabled?

Not necessarily known since 2012

[skids]

Who knows who knew what and when, but the 2012 statement is a misinterpretation of TFA where they seem to be saying it essentially started "hitting the shelves" in distros about then, whereas before then it was mostly only distributed in beta builds and head code.

Re:Not necessarily known since 2012

[Bite The Pillow]

Context: "Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. "

After so many years of this shit, it has to be intentional, just so people will post corrections.

Re:Not necessarily known since 2012

[FriendlyLurker]

After so many years of this shit, it has to be intentional, just so people will post corrections.

Of course it is intentional, and yet no naming and shaming appears to be going on... why is that? Only a small handful of people are responsible for bringing this to our linux distros, and a few more responsible for keeping it there. Those people have lost the trust of the community and should never have any of their code submissions or bug priority lists accepted ever again, otherwise there is just no consequence for nefariously subverting the security of us all.

Re:Not necessarily known since 2012

[skids]

I don't think so in this case. I normally would have waited on the firehose for a submission with a better writeup, but this was relatively urgent news so I upvoted it anyway.

(Yes someone did understand you weren't talking about the potential intentionality of the bug, don't despair there are people capable of comprehension out there and you may even meet one face to face someday :-)

Thanks Jerks

[s.petry]

Now how are we supposed to collect people's private information without their knowledge? Think of the children and all of the terrorists captured with this exploit in the wild!

sincerely,
NSA

Re:Thanks Jerks

[TangoMargarine]

Disregard that; we suck cocks.

NSA

P.S.: All your accounts are belong to us.

No Problem Here

[sk999]

Never trusted openssl - only use GnuTLS.
http://www.theregister.co.uk/2...

Re:Ironic

[DigitAl56K]

Irony rears it's head on the day that patches for a Linux vulnerability are announced at the same time Microsoft ends its patching and update service for Windows XP.

How is a vulnerability in OpenSSL, which is a library that can be compiled for multiple platforms, a "Linux vulnerability"?

Let's keep this to ourselves

[HtR]

Nobody tell the NSA about this, okay?

git blame of the bug please

[Anonymous Coward]

can someone link to the git blame of the bug please?

Re:git blame of the bug please

[Anonymous Coward]

There's an analysis of the bug here.

Re:git blame of the bug please

[dkf]

Mod parent up; it's very informative and worth reading.

Whether you get anything truly interesting out of the attack is a separate matter. Fortunately, the attacker can't control where the read is from (just its length) so you're more likely to get the session key (which the attacker will have anyway) than the private key from this sort of poking around around.

Beware memcpy()! If you don't know exactly where you're reading from and writing to and that you've got big enough memory chunks at both ends, you've got trouble. (OK, beware with memmove(), strcpy(), etc. too.)

Is this for real?

[WaffleMonster]

Is there anyone on the planet using TLS heartbeats via TCP for anything except exploiting this bug? What is even the point of heartbeats without DTLS?

Bugs are bugs yet decision to enable a mostly useless feature for non-DTLS by default in my view is not so easily excusable.

Re:Is this for real?

[Anonymous Coward]

It's disabled in the base system OpenSSL in FreeBSD, so it can't be that critical.

Incidentally, that also means that the summary is ... imprecise: FreeBSD, by default, isn't vulnerable to this. If you have OpenSSL from ports installed, it is - though that also means the fix is a simple package/port upgrade. (The fixed version is in ports already, and packages are, I believe, being built.)

This is good

[steelfood]

Well, it's not good that almost every major audit-able crypto library has been found to have trivial exploits (still waiting on issues in the Chrome and Mozilla SSL libraries).

It's good that eyes are looking, and people are finding these things. I imagine that without Snowden's revelations, nobody would have bothered to check. And these bugs would have been found much later or not at all, allowing espionage organizations to compromise many more private communications in the interim.

While the idea that the NSA or some other agency had a hand in these bugs is largely a conspiracy theory, the answer to whether they knew about these flaws and exploited them should be pretty obvious. After all, the NSA has probably done the very same code audits for the purpose of finding holes they can exploit.

And before somebody says a closed-source implementation wouldn't suffer these problems, quite frankly, if all of these libraries were closed-source, we wouldn't know if there was a vulnurability at all, or for that matter if any found would be fixed. There needs to be more eyes auditing the security code, not fewer.

Re:I take it this is a server concern

[paskie]

I *think* it might be feasible to exploit your web browser to steal cookies or saved credentials if you connect to a rogue https site. Credentials are always nice for spamming. If you convince people to keep you open in another tab, you might get lucky and snoop some credit card numbers or banking credentials too. A regular person should fear mainly automated attacks like this.

(Please do prove me wrong if I didn't get the attack potential here right.)

Re:Things are starting to turn around

[mi]

But unfortunately open source is not written by professionals, but ideologically driven amateurs and other random hobbyists.

That's not a fair generalization. Though there are plenty of "ideologically driven amateurs" — especially in the Linux (compared to BSD) world — they are mostly found among the noisy advocates, rather than actual developers.

Fixing this bug will be humongous amount of work, and there are likely to be even more like it in OpenSSL

Somewhere higher up the bug is described as a "simple bounds check" — which would be easy to implement. The truth is, probably, in between somewhere.

I am sure NSA know several more bugs like this that remain undisclosed.

NSA, I am sure, know plenty of holes — if not custom-made by the authors doors — into proprietary software too.

I am disappointed at the quality of open source software — especially pieces as famous and fundamental as OpenSSL, and I agree, that open source's claimed advantage of there being "thousands of eyeballs" verifying its correctness is overblown.

But to declare it to be "losing" is a silly jump just as far in the direction opposite to the enthusiastic proclamations of the above mentioned ideology-driven advocates.

We're all fucked

[mveloso]

Any data kept in RAM on an open-ssl box has probably been compromised. It sounds like that includes private keys, root certs, passwords, etc.

This is why passwords etc should be encrypted in RAM. It's funny, there's a Security Technical Implementation Guides (STIG) on that very item. It always sounded sort of ridiculous, but now I know why it was there.

Re:We're all fucked

[r.freeman]

No, "just" memory of the program that runs with libssl and to which attacker connected via ssl.
There would need to be other exploits to cross program-program and user-user isolation.
(well and the data/mem mapped/read/accessed by the compromised program)

Re:We're all fucked

[cbhacking]

Don't just encrypt them - move them out of process entirely. Have a security broker that knows your secrets, but doesn't talk to *anything* except local clients (on the assumption that if the attacker has arbitrary code execution, it's game over anyhow). Use inter-process communication to get secrets when needed, but preferably don't *ever* hold sensitive data in memory (for example, instead of using your private key directly, you ask he broker process to sign a binary blob for you, and it does so using your key and returns just the signature). Use "secure buffers" in managed code, or "secure zero" functions otherwise, to eliminate any sensitive data from memory as quickly as possible.

Yes, this used to sound paranoid. Actually, it still does sound paranoid. But, there's now a great example of a scenario where this is a Good Idea.

Of course, you have to make sure that broker is Really Damn Secure. Keep its attack surface minimal, make sure the mechanism by which it identifies whose key to use is extremely robust, and if possible make it a trusted part of the OS that is as secure from tampering as possible (Microsoft already has something like this built into Windows). There's also a question of how far to take it. For example, you could have the broker handle the symmetric encryption and decryption of TLS data (the bulk data part, after handshaking is completed) but that could impact performance a lot. Keeping the symmetric key in memory isn't so bad, really; it's ephemeral. However, if an attacker has a vuln like this and wants to read the traffic of a target user, they could attack the server while the user is using it, extract the symmetric key, and use it to decrypt the captured TLS stream. Keeping the key in-memory only while actually losing and (securely) purging it between response and the next request might be a good middle ground, perhaps?

Chrome's SSL uses a lot of the OS certificate mana

[Myria]

Chrome just uses the operating system for a lot of the certificate validation of HTTPS, so it can be vulnerable to security holes that apply to the operating system. Chrome wasn't vulnerable to "goto fail", but presumably it has been vulnerable to others in Windows and Mac OS.

Re:Things are starting to turn around

[bouldin]

Shill much?

Two anonymous cowards with IDs less than 1000 digits apart write anti-open source posts at the same time?

All those links

[Arker]

But the actual announcement is not among them.

https://www.openssl.org/news/secadv_20140407.txt

Re:I take it this is a server concern

[cbhacking]

No, you got it quite right. A server could grab browsing history, JS memory contents, stored passwords, and authentication cookies from a browser. It's not just web browsers, though; a malicious server could also steal email (from other email accounts) out of a mail client, and so on. For the handful of services that use client certificates, a server could steal the *client's* secret key.

Browsers (or other clients) that use multiple processes have some degree of safety, as this exploit can't read across process boundaries. It's also completely passive; just because every Chrome tab *can* get the cookies that are currently being used in every other Chrome tab doesn't mean that they are always loaded in each tab's process' address space (though I don't know if they are in practice or not).

Still, this is a grade-A clusterfuck security-wise. The ability for an unauthenticated attacker (all you need is an open TLS connection; that could be the login screen) to read memory off the other side of the connection is the kind of exploit you can make movie-grade "hacker" scenes out of. For a simple example you might see somebody pulling, you could use this exploit to decrypt any connection you recorded, assuming the server hadn't rotated its private key since then. If you can be fast enough and are in an intercept (MitM) position rather than just monitoring passively, you could even grab the keys in real-time and have complete control, invisibly, over the connection. From there, you could even read memory from the client and (continue reading from) the server at the same time!

You could probably do it automatically using a Raspberry Pi hiding behind the flowerpot in a café. I'm not joking.

I've been in the security world for years and I don't think I've ever seen so bad a vuln. Yes, things like "goto fail" were mind-blowingly stupid, but they still only let you MitM connections if you were in the right place at the right time. This one is strictly better and enables a huge number of alternative attacks.

Re:Things are starting to turn around

[skids]

Somewhere higher up the bug is described as a "simple bounds check" — which would be easy to implement. The truth is, probably, in between somewhere.

It's not the fix of the code that's messy. It's the fix of the trusts using that code to function. They are all broken. After the upgrade keys need to be replaced, certificates re-issued, endpoints and clients reconfigured to trust new keys, and in some cases customers and end-users may need to be involved. For anything of CDE level security or higher, it's as big a cleanup job than the one that gave us openssl-blacklist, but the blacklist for this would be neither complete nor easy to assemble.

I predict a lot more interest in turning on CRL pathways in the future.

Windows

[Kaenneth]

Good thing I use WIndows, so I'm safe.

Re:Windows

[Anonymous Coward]

Unfortunately it is XP, so you are safe until 12:00.

Yet again C bites us in the ass

[rabtech]

Yet again, C's non-existent bounds checking and completely unprotected memory access lets an attacker compromise the system with data.

But hey, it's faster.

Despite car companies complaining loudly that if people just drove better there would be no accidents, laws were eventually changed to require seatbelts and airbags because humans are humans and accidents are inevitable.

Because C makes it trivially easy to stomp all over memory we are guaranteed that even the best programmers using the best practices and tools will still churn out the occasional buffer overflow, information disclosure, stack smash, or etc.

Only the smallest core of the OS should use unmanaged code with direct memory access. Everything else, including the vast majority of the kernel, all drivers, all libraries, all user programs should use managed memory. Singularity proved that was perfectly workable. I don't care if the language is C#, Rust, or whatever else. How many more times do we have to get burned before we make the move?

As long as all our personal information relies on really smart people who never make mistakes, we're doomed.

Re:Yet again C bites us in the ass

[Eravnrekaree]

Its probably possible to create a compiler mode that will compile bounds checking code into existing C programs. This would involve one compiler pass that would generate C output with the inserted code, and a second pass to generate the binary. This could be done with a new backend in Clang. It would also allow the inserted code to be easily seen since the source output could be dumped into a file. A good thing about this is that such a feature could be turned on or off in the compiler. This would be on by default in nearly all programs. Doing this is much more efficient than rewriting a lot of software in other languages.

Re:Yet again C bites us in the ass

[Anonymous Coward]

Because "bounds checking" is no silver bullet - it's an artificial limitation that DOES slow things down, unlike seatbelts and airbags, which have infinitesimal impacts on vehicle performance.

That's not true. Safety features like seatbelts, airbags, roll cage, etc. add an appreciable amount of weight to the car. "some hypermilers take it to the extreme, removing important safety features like rearview mirrors or even the car's airbags."

Either that, or you're too stupid to program successfully in C.

Apparently so are the OpenSSL developers, and all the other people who have been bitten by bounds errors over the years. Too bad there's no operating system written by perfect beings.

Re:Yet again C bites us in the ass

[istartedi]

Yes, bounds checking is a hassle in C but throwing out the whole language isn't necessary. We could default to smart pointers and add a new type qualifier for people who want the old behavior. Dangerous code would look like:

int unbound * foo=malloc(1024);

It might be required to have a compiler switch to avoid breaking ABIs that are expecting simple pointers. The bounded pointer would have to be a struct with a slim pointer and a size in it that gets updated whenever the pointer mutates, and raises a signal whenever you add or subtract too much or try to index outside of it. I'm just spintballing. I'm sure there are some detail devils but it doesn't seem impossible or even unworkable. It doesn't sound like an excuse to re-write everything. You could even do something like this as a non-standard extension RIGHT NOW.

For years people complained that C was actually slower than Fortran because of the aliasing problem, and we eventually got the restrict qualifier. So. Don't just dump the whole thing. Fix it.

Re:Yet again C bites us in the ass

[IamTheRealMike]

Blah blah blah.

Java 8 has a full SSL stack written in Java itself, so no buffer overflows there, and which uses AES-NI for hardware accelerated encryption if available. It also supports perfect forward secrecy and other modern features (no session tickets though).

If you look at the CVE history of JSSE what you will find is that occasional bugs like the Heartbleed attack (not checking length fields correctly) get reported as denial of service issues because they cause managed exceptions that might, if you wrote your code non-defensively, cause your server app to quit. Or they might just cause the connection to drop, which is the right behaviour.

It's about a million times safer than an ancient piece of 1980's style C like OpenSSL.

Yes!!!

[Areyoukiddingme]

*air-punch*

I knew procrastinating Debian upgrades for most of a decade would pay off! I am VINDICATED!

Re:Things are starting to turn around

[Anonymous Coward]

But unfortunately open source is not written by professionals, but ideologically driven amateurs and other random hobbyists.

That's not a fair generalization. Though there are plenty of "ideologically driven amateurs" — especially in the Linux (compared to BSD) world — they are mostly found among the noisy advocates, rather than actual developers.

...

systemd devs seem bound and determined to prove you wrong there...

Re:Chrome's SSL uses a lot of the OS certificate m

[steelfood]

My understanding is that Chrome and Mozilla both use NSS. It's a bit outdated, so I could be wrong (given that Google forked webkit, I can imagine them forking NSS too).

Actually, with a quick Google search, it seems that Chrome on Android uses (used?) OpenSSL for certain functions. I'm curious to know if secure communication via Android devices can be compromised via those functions. At first glance, I'd say no, but I don't have enough domain knowledge to make this assertion.

NSS is thus far secure, but I really, really would like to see the results of multiple full and independent audits. If there's a problem in NSS, that would be about as big as it can get.

Like I said, it's a bit frightening that there are such large and somewhat obvious holes in these major crypto libraries found within three months of each other, but it's good to know that they're being found and fixed.

original eyeballs meant the FIX to a known bug

[raymorris]

On a side note, regarding advantage of there being "thousands of eyeballs" verifying its correctness" -
ESR's famous quote is "with enough eyeballs, all bugs are shallow - the fix will be obvious to someone."

The quote doesn't say anything about correctness. It says that when strange behavior is noticed, someone will see a clear fix. A shallow bug is one that's right there on the surface, where you can see the source of the problem. That's in contrast to one where you have to spend hours searching for what's causing the problem. It makes no claim of how quickly or easily a bug will be discovered - just how it can be fixed once it's discovered.

It's really annoying

[mikein08]

There are security vulnerabilities seemingly EVERYWHERE. Do programmers not test their code anymore? Is there no testing protocol for security issues? Is no one embarrased to have released a piece of software that's so porous? I'm retired, and I can tell you that if I had written code with the security holes that modern programs and apps seem to have, I would have been unceremoniously fired very quickly by any and all of the several employers for whom I worked in my career. But that doesn't seem to happen today, unfortunately.

Re:It's really annoying

[skids]

There may seem to be more now because there is more auditing going on since the NSA revelations reminded people what had to be done, and also the slower trend of case law starting to punish mishandling of customer data. The halcyon days are over and the backlog is being cleared up.

Re:It's really annoying

[lennier]

This bug is almost 10 years old

Well look who natively counts in binary.

Hello Joshua! Give my regards to Dr Falken.

All these bugs are mind blowing

[93 Escort Wagon]

But, regardless of the root cause (intentional malice or just sloppiness) I'm glad eyes have been checking these code bases with more diligence over the past several months. In the end it means more security for us users, regardless of our platform of choice.

Thank you again, Edward Snowden, for the collective wake up call!

Now if we could just get our governing officials to fix some of these egregious laws...

Re:Is SSH affected?

[cbhacking]

Assuming it uses a version of openssl that supports the relevant TLS feature, SSH servers are absolutely vulnerable. Connect to one, carry out the attack while it waits for you to authenticate; now you can steal its secret key. This is also a way that a malicious SSH server could attack the client; possibly stealing things like the client private keys (SSH being one of relatively few places where asymmetric client authentication is common).

RHEL / CentOS / Fedora updates now available

[seifried]

RHEL updates are available:

https://rhn.redhat.com/errata/RHSA-2014-0376.html

CentOS updates are available:

http://lists.centos.org/pipermail/centos-announce/2014-April/020249.html

Fedora updates are available, hitting the mirrors, but you can get it earlier, instructions here:

https://lists.fedoraproject.org/pipermail/announce/2014-April/003205.html

https://lists.fedoraproject.org/pipermail/announce/2014-April/003206.html

Minimal jargon explanation

[cbhacking]

Basically, an attacker can connect to many secure Internet services - could be a banking website, or your email server, or a server hosting software updates, or possibly your corporate VPN - and learn everything that the server knows. This includes the private key (sort of like a super-complex and super-secret password) that is used to *make* the service secure. The attacker can then get all the data that the server sees, ranging from normal user passwords to all your emails and banking info.

This vulnerability is many, many kinds of bad. I'm simplifying a lot here. Basically, an awful lot of data is at risk right now, because of this bug.

This site has a pretty great explanation that most people likely to be found on /. will be able to follow, even if not normally security types: http://heartbleed.com/

Re:Is SSH affected?

[Anonymous Coward]

OpenSSH uses the libcrypto portion of OpenSSL for crypto primitives. It does not use TLS, and therefore SSH is not vulnerable to this attack.

Shut the fuck up when you don't know what you're talking about.

Re:Ironic

[kthreadd]

You're probably thinking of OpenSSH. OpenSSL is independent as far as I know.

Re:Is SSH affected?

[MikeBabcock]

As I understand it, this is a bug in a function of OpenSSL that is used in TLS sessions which isn't used by OpenSSH. OpenSSH does not use TLS.

Your webserver and mail server would though.

Re:Is SSH affected?

[Anonymous Coward]

Rather than get all aggro, I will state that I have tried to find a concrete answer to this question ("is OpenSSH vulnerable/impacted by this?"), and I still cannot. So before someone say "shut the fuck up when you don't know what you're talking about" to me, I'll provide the data (and references) I do have:

* OpenSSH links to the libcrypto.so shared library which is absolutely OpenSSL on most systems: ldd /usr/sbin/sshd followed by strings /whatever/path/libcrypto.so.X (you'll find OpenSSL references in there). Truth: because OpenSSH links to a cryptographic library that's part of OpenSSL doesn't mean it's necessarily using the code that's bugged (see below poster's sig and note function names are DTLS-related (keep reading)), but it also doesn't mean it isn't. When was the last time you ran truss/strace with all flags (for children, all syscalls, fd I/O, etc.) and looked at it closely?

* SSH, as a protocol, is not SSL (but keep reading): http://www.comforte.com/solutions/tls-vs-ssh/ and http://stackoverflow.com/questions/723152/difference-between-ssh-and-ssl (see replies to primary thumbs-up'd answer)

* However, SSH does rely on at least some part of TLS, the one that's known is X.509 (a form of PKI) (but keep reading): http://www.snailbook.com/faq/ssl.auto.html

* ...but then things like this seem to imply the OpenSSH folks don't use X.509 at all and that you have to run a special OpenSSH build for this to work: http://security.stackexchange.com/questions/30396/how-to-set-up-openssh-to-use-x509-pki-for-authentication

* ...but then you find things like this which are open-ended and seem to imply otherwise (and the link mentioned on that blog, by the way, is also worth skimming/reading to see what's being done): http://trueg.wordpress.com/2012/09/06/use-an-x-509-certificate-for-ssh-login/

* The "heartbleed" bug, which refers to RFC 6520, pertains to TLS: http://www.snailbook.com/faq/ssl.auto.html (yes same link)

* There are repeated/continual news references to "use of X.509" (which could apply to either SSH or SSL from the above references) in every single news announcement. I shouldn't need to link them all.

There is nothing even remotely definitive on either the OpenSSL or OpenSSH mailing list, and that's a bit shocking if you ask me. Therefore, to me, the OP's question is quite valid.

Does the answer to his/her question change the severity of the situation? Yes it does. Yes you should still upgrade OpenSSL, but what some of us senior system administrators are trying to figure out is whether or not we need to inform every employee that they need to generate new SSH keys. I think everyone at this point is aware webservers (ex. nginx, Apache, etc.) doing SSL need to have OpenSSL upgraded + the daemons restarted + keys re-generated + re-signed, but the concern here is whether or not any part of OpenSSH's function calls into the OpenSSL crypto library rely on anything related to RFC 6520.

My opinion: the reason nobody has definitive answer with references (and I hope this Slashdot post induces such) is because there's a serious disconnect between using security-focused software (end-users, SAs, companies using security software, etc.), the writing of cryptographic algorithms (cryptologists), and ac

Re:ASLR anyone? hype?

[AlphaBro]

This is a read overrun, so ASLR won't save you. Ignore the guy above who posted about ASLR bypasses--that's not really relevant to this.

Re:Ironic

[Mitchell314]

Silly, all "Open*" projects are owned by OpenBSD. Like OpenGL. And OpenOffice. :p

Re:I take it this is a server concern

[IamTheRealMike]

I don't think Chrome uses OpenSSL, although they are thinking about switching to it. They use NSS, same as Firefox. I'm not sure any browsers use OpenSSL - it's mostly used on the server.

Re:ASLR anyone? hype?

[Agent ME]

Read overruns causing occasional crashes isn't much of an issue for the attacker if the server is auto-restarting.

Re:Things are starting to turn around

[the_womble]

The SSL core team all appear to be professionals.

I have not checked, but most of the contributors probably are too.

The same is true of most big open source projects (like the Linux Kernel).

The differences are:

1) There is better disclosure of bugs in open source
2) some bugs can be discovered by third party audit (as the GNUTLS bug was)

It's sad no one agrees with this.

[Sanians]

I don't understand why this is controversial. People consider it a bad idea to roll your own encryption code. Why isn't it a bad idea to roll your own bounds checking? Because it's easy and you won't screw it up? I'm sure people writing their own hash functions feel the same way.

Do people seriously prioritize speed over security? Of all of the things my computer might squander its gigahertz on, squandering them by checking bounds on things that will never actually be out of bounds isn't something I can disagree with if it makes the software running on my computer more secure. It's kind of like how, when doing math problems on a test, you check your work to make sure you get the right answer. Technically it's a waste of time if you know what you're doing, but if you're concerned about your grade, you do it anyway just in case.

Besides, if you want to whine about unnecessary wasting of CPU cycles, just look at an assembly dump of floating-point equations being solved in C as compiled by GCC. Anyone who actually knows how to do floating point in assembly language will want to cry. The round() function is a good example, as the documentation declares a specific way of rounding half-way cases which isn't what the FPU does and which anyone who knows how to use floating point math correctly will realize is a complete fucking waste of time since what the FPU does do is 100% adequate.

Older Versions Safe

[StormReaver]

Distributions using OpenSSL 0.9.8 are not vulnerable

This is why I haven't upgraded my Linux servers in 23 years.

Re:1.0.1-4ubuntu5.12 still vulnerable

[kthreadd]

Running 12.04 LTS and updated openssl to 1.0.1-4ubuntu5.12

Which contains the patch.
http://changelogs.ubuntu.com/c...

System is still vulnerable. Seeing this reported on askubuntu as well. filippo checker confirms site is still vulnerable after upgrade

Make sure you restart the service. Any processes launched before installing the patch may still include the old version of the shared library.

Re:Is SSH affected?

[Anonymous Coward]

OpenSSL does many things.
It is both a crypto library (Access to ciphers) and a TLS protocol implementation, amongst other things (eg: PKI implementation)

This OpenSSL bug is in the TLS protocol implementation. TLS heartbeat is an optional extension to TLS.

OpenSSH uses the crypto library component for access to ciphers.
As OpenSSH does not use TLS, I can't fathom any reason it would be vulnerable to this particular bug.

Quick test shows Yahoo user passwords

[monkeyhybrid]

Filippo Valsorda's online tool for checking web servers for the Heartbleed vulnerability is quite an eye opener. As well as telling you whether the server is vulnerable, it displays a small snippet of the memory it retrieved (there are scripts on Github that will show you the whole 64KB I believe).

In the quick tests I did on login.yahoo.com (used for Yahoo's email and probably all other Yahoo services), I saw three different user's passwords and at least part of their usernames. And you can just sit there refreshing the page to see more! Madness!

Re:ASLR anyone? hype?

[BitZtream]

Read or write overruns will only throw an exception if they go beyond the bounds of the applications total allocated memory so they hit an unallocated page. (page fault)

If you simply read into some memory that has been allocated by some other component, no exception will be thrown.

Reading outside the bounds of the application application pages is unlikely as you'd have to be the last or close to the last allocated block (when the application space has to be grown, doesn't work if its a realloc of a previously allocated page, so lower in the address space and not near the end of allocated pages) and/or have a large overrun so you went through all the other allocated blocks.

Re:ASLR anyone? hype?

[benjymouse]

I've actually wondered about this too. Read overruns will crash a program just as badly as write overruns; Read AV in Windows [NT], Segmentation Fault in *nix (General Protection Fault in legacy Windows), etc. reading memory will tell you enough about the layout of memory to cherry-pick addresses pretty well, and probably to determine the ASLR mask, but you're still going to have the issue of what, within the heap, is allocated. You could probably do OK by starting from the stack (which is in a predictable enough location) and working from there, I guess?

ASLR was invented as a mitigation of "return oriented programming" which was itself a way to get around DEP/NX. As such, ASLR targets executable memory, making the memory addresses of candidate executable code fragments hard to guess. ASLR does not randomize data segments - there's no need since the original intent was to make executable locations hard to guess. Non-executable locations was not the problem ASLR tried to solve.

And in the case it would not matter at all if the location was randomized, since this bug is an unbounded offset to a memory location. The attacker does not need to know the actual memory location, he just needs to specify a too large or too small offset to read adjacent memory. Yes, going too far could trigger a segfault, but the attacker will have dumped all memory until then. So what? The attacker can just continue the attack once the service restarts.

The point is: The attacker does not need to know anything about the memory layout. The server already allows him to offset from a pointer to a known valid location.

Re:Things are starting to turn around

[gumpish]

Amusing fact: the primary author of systemd is the same guy that brought us pulseaudio. Why do we do this to ourselves?

Code Examples

[Sanians]

In other news, we can check everything quickly by not checking everything!

His comment is more interesting than your reply makes it out to be.

I've looked at a few disassemblies of compiled C code. GCC is already pretty good at understanding how variables interact within for() loops. If you make two nested loops, one for each index of a two dimensional array, it'll output code which simply uses a pointer that's incremented in a loop to access the array and check the pointer against a limit to determine when the loop is complete, such that the pair of for loops you wrote don't actually exist in the final code. It'll even switch the order of your nested loops if necessary to make this possible. If you perform a calculation inside of both loops that can be moved outside of one of them, it'll spot that and move the calculation outside of the inner loop. Write an equation in an unnecessarily verbose way that makes use of multiple unnecessary temporary variables? It'll notice and your temporary variables won't exist in the final code. Use the same sub-expression in multiple equations? It'll notice and calculate that sub-expression once and store it to a temporary variable. The compiler optimization isn't smart enough to turn your O(n^2) algorithm into an O(n*log(n)) algorithm, and indeed, what it does do is kind of basic, but it's still able to figure out quite a few of the more obvious optimizations, and in doing so it frees the programmer from having to worry about these more trivial things, which allows the programmer to focus their attention on things that computers aren't smart enough to do for us.

Thus, when it comes to code like this:

int a[100][100];
for (int y = 0; y < 256; y++) {
    for (int x = 0; x < 256; x++) {
        a[x][y] = x * y;
    };
};

GCC wouldn't even think about outputting code to check the array bounds. It would check them as it compiles and decide whether to output the code without bounds checking, or, as in the case above, report that this code will always exceed the array bounds.

GCC already looks at code in enough detail that, if you call a small function that exists in the same source file, it'll notice its small size and inline it. I once had a pair of functions that each called the other recursively and saw that it chose to inline one of them within the other. So it would likely notice that the array bounds will be just fine even if you put your loop in one function and access the array in another as long as both functions exist within the same source file so that it is able to examine both functions at the same time. So, for the most part, it would only generate bounds checking where it is actually necessary: In code where the array index comes from outside the program, or in code where the index comes from within the program but through a complex enough path that even a human couldn't safely assume that they're 100% certain the index will always be within bounds.

So, most of the time, the compiler would correctly determine whether or not bounds checking is even necessary. Sure, sometimes it might be wrong, but humans get this wrong as well. The difference is that when the compiler gets it wrong, it'll err on the side of performing the check even when it's unnecessary, whereas humans tend to often get it wrong by leaving out the check even when it is necessary, or by attempting to perform the check but writing the code incorrectly so that the check fails.

As long as our software is doomed be screwed up in some manner, I'd prefer it be screwed up by being a bit slower than necessary, rather than having it expose data on my computer to any web site I visit.

News cycle

[Indigo]

Does anyone else see anything odd about the search results for this story?

I Googled "heartbleed" around 15 minutes ago and looked through 13 pages of results. I was looking for some info a little on the hardcore side, and the Google results were kind of surprising. There were tons of big well-known sites at the very top of the list - Fox, CNN, BBC News, Reuters and Forbes, etc; then a whole lot of mainstream "tech news" sites (PC World, ZDNet and so on) and blogs (HuffPo for example), then finally some more tech oriented or actual tech ones (YCombinator, Netcraft, StackOverflow) with a tiny sprinkling of blogs and relevant support forums (Cisco). US-CERT's listing was down on page 3 or so and honestly there just were not that many "hardcore" sites to be seen.

Running the search again after clearing cookies, the layout has changed a lot. The big news sites hits have slid way down (Fox News is on p. 3 now, for instance) with tech news and blogs moving up. All in all, the harder tech sites are floating upward and the less so are moving down. It's like the lava lamp version of a security scare.

Wondered what other Slashdotters think, it just seems a bit... strange, somehow. Don't these things usually bubble around in the tech community for a bit before surfacing in the mainstream world? It's like every big news site on the planet picked it up simultaneously, followed by the mainstream tech news site, and finally it began to filter down into the tech world. Could just be an artifact of Google's update cycle, but it definitely piqued my curiosity.