Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenSSL Bug Allows Attackers To Read Memory In 64k Chunks

Unknown Lamer posted about 4 months ago | from the check-your-bounds dept.

Security 303

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.

cancel ×

303 comments

Sorry! There are no comments related to the filter you selected.

Gee, that's worse than no encryption isn't it? (5, Informative)

Anonymous Coward | about 4 months ago | (#46689601)

"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!

Linux is illegal! You are breaking the law, and hu (-1, Flamebait)

Anonymous Coward | about 4 months ago | (#46689985)

Linux is illegal! You are breaking the law, and hurting yourself and your family with your ILLEGAL SOFTWARE. Your ip has been noted and is being forwarded to the SPA with a reccomendation that they investigate your CRIMINAL ACTIVITY. Please destroy all your unpatriotic linux software before the government finally cracks down on you people and you all end up as lampshades or soap.

ASLR anyone? hype? (1)

pikine (771084) | about 4 months ago | (#46690815)

With address space layout randomization, I can't imagine how you could probe memory for sensitive information without causing the process to randomly crash. Given how polished the website publicizing the vulnerability is, I think they're more interested in creating hype.

Re:ASLR anyone? hype? (0)

Anonymous Coward | about 4 months ago | (#46690991)

And if that's defeated? http://www.fireeye.com/blog/technical/cyber-exploits/2013/10/aslr-bypass-apocalypse-in-lately-zero-day-exploits.html What then?

Not necessarily known since 2012 (5, Informative)

skids (119237) | about 4 months ago | (#46689605)

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 (4, Insightful)

Bite The Pillow (3087109) | about 4 months ago | (#46690979)

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.

Thanks Jerks (5, Funny)

s.petry (762400) | about 4 months ago | (#46689633)

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 (1)

AlphaBro (2809233) | about 4 months ago | (#46690837)

NSA here, posting from another of our sockpuppet accounts. Disregard the prior post; we've Linux so thoroughly backdoored we refer to it as "the bottom" around these parts.

Sincerely,

The Lords of Information

Re:Thanks Jerks (0)

Anonymous Coward | about 4 months ago | (#46691017)

You should post that as AC. Isn't it illegal pretending to be a federal agent, even if it is obvious (to non-lawyers) that it's a joke?

sincerely,
NSA

Ironic (0, Interesting)

Anonymous Coward | about 4 months ago | (#46689671)

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.

Re:Ironic (5, Insightful)

DigitAl56K (805623) | about 4 months ago | (#46689709)

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"?

Because nobody even attempts to run secure applica (1)

Anonymous Coward | about 4 months ago | (#46689869)

Because nobody even attempts to run secure applications on any other platform...

Re:Ironic (0)

Anonymous Coward | about 4 months ago | (#46690859)

Consider it's an OpenBSD project.

definitely news for nerds (0)

turkeydance (1266624) | about 4 months ago | (#46689681)

jargon away!

Re:definitely news for nerds (1)

skids (119237) | about 4 months ago | (#46689799)

Basically it means if you know any UNIX sysadmins, they'll be pretty cranky for the next week or so as they've been busy trying to put the poop back in the baby.

Oh yeah, and lots of your gadgets and favorite cloud services may be vulnerable, so anything stored on them may be in the hands of others.

Minimal jargon explanation (4, Informative)

cbhacking (979169) | about 4 months ago | (#46690929)

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/ [heartbleed.com]

No Problem Here (5, Funny)

sk999 (846068) | about 4 months ago | (#46689705)

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

Re:No Problem Here (-1, Redundant)

DarwinSurvivor (1752106) | about 4 months ago | (#46689797)

Well, I wouldn't say no problem [slashdot.org] ...

Um, whoosh? (1, Funny)

cbhacking (979169) | about 4 months ago | (#46689925)

How the fuck did this get modded up? Idiot mods (and "DarwinSurvivor", apparently) can't read a link, I guess...

The only way this could have been stupider is if it was actually the same link, instead of merely being a link that I could tell, just from the URL, was about exactly the same issue.

Morons.

Re:No Problem Here (0)

Anonymous Coward | about 4 months ago | (#46689953)

I think you missed the sarcasm. He even included a link..

Things are starting to turn around (-1, Troll)

Anonymous Coward | about 4 months ago | (#46689737)

Open source is losing. Its merits used to be performance, stability and security. In all of these three areas, the benefits today are far less convincing than a decade ago.

Re:Things are starting to turn around (-1, Flamebait)

Anonymous Coward | about 4 months ago | (#46689829)

Agree. This pretty much drives the final nail to the coffin of open source in security critical applications. The bug is a simple bounds check, which a professional security programmer should have gotten right. But unfortunately open source is not written by professionals, but ideologically driven amateurs and other random hobbyists. Fixing this bug will be humongous amount of work, and there are likely to be even more like it in OpenSSL. I am sure NSA know several more bugs like this that remain undisclosed.

Re:Things are starting to turn around (4, Insightful)

mi (197448) | about 4 months ago | (#46689899)

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.

Re:Things are starting to turn around (5, Insightful)

skids (119237) | about 4 months ago | (#46690079)

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.

Why doesn't the DNS distribute public keys? (0)

Anonymous Coward | about 4 months ago | (#46690787)

Turning DNS registrars into CAs would be great because everyone knows exactly who owns yourbank.com. Key revocation would be easy, just publish a new key in your DNS record. Get a SSL page with the wrong key? Check the DNS record.

Re:Things are starting to turn around (5, Insightful)

Anonymous Coward | about 4 months ago | (#46690215)

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...

original eyeballs meant the FIX to a known bug (3, Informative)

raymorris (2726007) | about 4 months ago | (#46690297)

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.

Re:Things are starting to turn around (0)

skids (119237) | about 4 months ago | (#46689931)

While you're right this was very negligent for a project of the stature and importance of openssl, merely discovering this bug in closed source software would have required a fuzzer and much luck, leaving it unfixed for whoever had managed to get a a copy of the source to exploit for much longer.

All I can say personally is I sure picked the right two years to get lazy about patching up.

Re:Things are starting to turn around (1)

AlphaBro (2809233) | about 4 months ago | (#46690989)

Fuzzing isn't the only way of finding vulnerabilities in closed source software, not even close. And are you saying that source is required for exploit development? That's simply not the case.

Re:Things are starting to turn around (2, Interesting)

bouldin (828821) | about 4 months ago | (#46689977)

Shill much?

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

Re:Things are starting to turn around (0)

Anonymous Coward | about 4 months ago | (#46689983)

At the same time? The posts were 12 minutes apart.

Re:Things are starting to turn around (1)

SpankiMonki (3493987) | about 4 months ago | (#46690195)

Shill much?

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

LOL!

Re:Things are starting to turn around (1)

bouldin (828821) | about 4 months ago | (#46690239)

Yeah, sometimes I say things so stupid, it amazes me, too

Re:Things are starting to turn around (1)

SpankiMonki (3493987) | about 4 months ago | (#46690505)

Heh, I also suffer from foot-in-mouth disease from time to time. And look - you got modded up! : )

Re:Things are starting to turn around (1)

bouldin (828821) | about 4 months ago | (#46690621)

Figures - I write a dozen thoughtful posts that get no love, but when I take a brain shart on a post, that gets the mod points.

Re:Things are starting to turn around (0)

Anonymous Coward | about 4 months ago | (#46690435)

Wow a whole two posts within 15 minutes of eachother (and around 1000 posts in between) that are critical of the value placed on the open source model with respect to security?! They must be being paid to have that opinion! Nevermind the fact that we have seen several years-old bugs across security libraries, application frameworks and the kernel itself in recent times. The idea that it is safer because it's open is fantasy, if anything these bugs are directly exposed and remain that way until there is some responsible disclosure. Now the idea that they can be fixed and pushed to all customers in a timely manner is another story, though even then it depends on the situation - take Android or Tivo for example.

Both models have advantages and disadvantages depending on what the product is, the size of its market, the type of market, etc. and sometimes those advantages can't even be realized (again, see Android or Tivo) so anybody espousing one over the other as the one true model is a short-sighted idiot.

Re:Things are starting to turn around (1)

AHuxley (892839) | about 4 months ago | (#46690549)

Re " both models have advantages and disadvantages depending on what the product is, the size of its market, the type of market, etc. and sometimes those advantages can't even be realised"
The problem with a closed source effort is what we saw with Prism http://www.theguardian.com/wor... [theguardian.com]
The legal system and dev staff stay with the closed source product.
With open source code - when an issue is found days, months, years later it can be corrected, fully understood and fed back into further world wide crypto education.
The other option is to trust known weakened corporate encryption over many new versions and have faith in their legal teams ... just like you did the first few times...
The other emerging aspect is that of US National Security Letters (NSL) for ongoing bulk collection 'efforts' vs a more global open source code.
After Snowden many more people will be looking at crypto, with open source code someone might be able to offer reviewed, tested fixes to junk standards.

Re:Things are starting to turn around (0)

Anonymous Coward | about 4 months ago | (#46690975)

this is another example of open source advocates trying justify their idea of it being the one true model by attempting to solve the problem in the middle, rather than at the source. ultimately if they want to spy on you they will, one way or another and just securing your own computer wont help you.

this problem is at the legislative government level and that is where it needs to be solved, not at chasing your tail trying to secure your computer because as we have seen the vulnerabilities run rampant for years anyway. same thing goes for the DRM/copyright issues, the problem needs to be solved at the content production level, creating a free system in the middle doesnt help when the content producers wont permit you to have their content and infringing on DRM/copyrights only makes for a more hostile environment.

What? (0)

Anonymous Coward | about 4 months ago | (#46690131)

Man you're clueless. This is a case of open source fixing a security issue as soon as it's recognized, and you call it a downside?

Hint: closed source code probably contains hundreds or thousands of these holes and they hang around unfixed for decades.

I take it this is a server concern (1)

msobkow (48369) | about 4 months ago | (#46689747)

As I can't imagine the servers I connect to being interested in snooping on my client data, I presume this bug is only a real concern for systems running services, not acting as clients.

Re:I take it this is a server concern (2)

paskie (539112) | about 4 months ago | (#46689895)

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:I take it this is a server concern (5, Interesting)

cbhacking (979169) | about 4 months ago | (#46689999)

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:I take it this is a server concern (1)

skids (119237) | about 4 months ago | (#46689947)

You really think the guy behind hotgritsnatalyportmanphotos.org is trustworthy?

Re:I take it this is a server concern (1)

GigaplexNZ (1233886) | about 4 months ago | (#46690251)

If you store data on servers (hello cloud) then as a client you should be concerned.

Re:I take it this is a server concern (1)

AHuxley (892839) | about 4 months ago | (#46690645)

It really depends on the end game for *you*.
Client data might be used for "full spectrum" efforts e.g. propaganda, deception, mass messaging, pushing stories, spoofing, alias development or psychology.
i.e. the service you use is weekend.
The other aspect is how many groups knew of this crypto trick? The US and just a few friendly govs, their staff, their contractors and any ex staff or staff open to faith or cash needs.
Just another way in :)
http://www.businessweek.com/ar... [businessweek.com]

Ubuntu (1)

goodgod43 (1993368) | about 4 months ago | (#46689803)

sudo apt-get update && sudo apt-get upgrade.
Generate and distribute new keys.
Problem soved.

Re:Ubuntu (1)

rubycodez (864176) | about 4 months ago | (#46690295)

nope.

you have to reboot after update for this one. but thanks for playing

no (0)

Anonymous Coward | about 4 months ago | (#46690657)

you need to assume that your private keys and other SSL artifacts have been compromise. have fun regenerating your certs and getting them re-signed.

I do impressions (0)

Tablizer (95088) | about 4 months ago | (#46689817)

Bill Gates as a hacker:

"64k chunks ottah be enough for anyone."

Theo? (1, Funny)

Anonymous Coward | about 4 months ago | (#46689819)

Could someone please give Theo a heap of grief over this from me? He's always so quick to bag out GnuTLS and others when they have an issue. Only fair he gets a share of what he dishes out. Besides, this seems to be even worse than a "goto fail"...

Re:Theo? (1)

Lunix Nutcase (1092239) | about 4 months ago | (#46689987)

I can only hope this is a clever attempt at whooshing people. Otherwise...

Re:Theo? (1)

Anonymous Coward | about 4 months ago | (#46690759)

Could someone please give Theo a heap of grief over this from me? He's always so quick to bag out GnuTLS and others when they have an issue. Only fair he gets a share of what he dishes out. Besides, this seems to be even worse than a "goto fail"...

Ummm, you do know that there is no relation between OpenBSD and OpenSSL, right?

They have a slightly similar name, but that's it

OpenSSH on the other hand, is an OpenBSD project.

Let's keep this to ourselves (2)

HtR (240250) | about 4 months ago | (#46689835)

Nobody tell the NSA about this, okay?

git blame of the bug please (5, Interesting)

Anonymous Coward | about 4 months ago | (#46689843)

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

Is this for real? (5, Interesting)

WaffleMonster (969671) | about 4 months ago | (#46689849)

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.

This is good (2)

steelfood (895457) | about 4 months ago | (#46689857)

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.

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

Myria (562655) | about 4 months ago | (#46689975)

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:Chrome's SSL uses a lot of the OS certificate m (3, Informative)

steelfood (895457) | about 4 months ago | (#46690283)

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.

Re:This is good (0)

Anonymous Coward | about 4 months ago | (#46690039)

"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" No, you'd know they wouldn't be.

Got the update... (1)

Eggplant62 (120514) | about 4 months ago | (#46689903)

Linux Mint, and I'd assume Ubuntu too, has already pushed the updates out. Happy happy. Joy joy.

Re:Got the update... (1)

ewhac (5844) | about 4 months ago | (#46689959)

For Linux Mint v17 (Qiana), maybe. However, Mint v15 (Olivia) got EOLed in January, so it may not get an update.

We're all fucked (5, Interesting)

mveloso (325617) | about 4 months ago | (#46689943)

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.

STIGS are pretty good. (0)

Anonymous Coward | about 4 months ago | (#46689981)

I started being annoyed at having someone else tell me how
to set up security, but taken one at a time they almost all
make sense.

Re:We're all fucked (2)

r.freeman (2944629) | about 4 months ago | (#46690021)

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)

Passwords in RAM (1)

Anonymous Coward | about 4 months ago | (#46690139)

Keeping the passwords encrypted in RAM doesn't help all that much if you also have the decryption key in RAM. Which you do, because you need to use the password. Right?

Having said that; a server should (ideally) never have a plain-text password anyway.

Re:Passwords in RAM (0)

Anonymous Coward | about 4 months ago | (#46690411)

Yes, but it makes it more difficult because instead of looking for a possibly-human-readable char[], now they have to find both the encrypted password and the hard-coded decryption key, which will be difficult given just a memory dump.

Please note I said difficult, not impossible. It's security through obscurity so it makes things that much more difficult but not impossible for someone with time and skills.

Re:We're all fucked (4, Interesting)

cbhacking (979169) | about 4 months ago | (#46690651)

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?

All those links (3, Interesting)

Arker (91948) | about 4 months ago | (#46689997)

But the actual announcement is not among them.

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

Good thing.. (0)

Anonymous Coward | about 4 months ago | (#46690019)

..it was not in 640k chunks!

You Fail it (-1)

Anonymous Coward | about 4 months ago | (#46690027)

downward Spi8al. In

Windows (5, Funny)

Kaenneth (82978) | about 4 months ago | (#46690091)

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

Re:Windows (0)

Anonymous Coward | about 4 months ago | (#46690257)

"so I'm safe." -Airplane engine breaks off and hurtles through space, whistling.

Is SSH affected? (1)

Eravnrekaree (467752) | about 4 months ago | (#46690133)

Does this effect SSH at all? It seems more likely this would effect TSL servers such as Apache and stunnel.

Re:Is SSH affected? (1)

skids (119237) | about 4 months ago | (#46690219)

For sshd there was possibly some protection afforded by the privilege separation model. I'd store your old keys and wait to see something from someone who knows it cold.

Re:Is SSH affected? (2)

cbhacking (979169) | about 4 months ago | (#46690707)

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).

Yet again C bites us in the ass (4, Insightful)

rabtech (223758) | about 4 months ago | (#46690135)

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 (-1)

Anonymous Coward | about 4 months ago | (#46690167)

You didn't even name the silver bullet language that has no such flaws. STFU, moron.

Re:Yet again C bites us in the ass (1)

Anonymous Coward | about 4 months ago | (#46690487)

"moron" is uncalled for.

The point is that we need a certain capability, we can either write it ourselves, or choose to leverage significant shared effort and troubleshooting to adopt already proven code by using a library.
Yes, you can write your own SSL stack from scratch, but most people wisely choose not to, because it would probably be full of holes.

SO, It's a very similar situation between using a library and using managed code. What does managed code do that good C doesn't??? Nothing. So you can either implement all "that stuff" in C, or trust that someone else has done it more consistently than you will.

And using libraries and managed code both have their downsides as well, so sometimes it's best to go "raw". I've done both, though the need for pure C in modern PC is getting pretty tiny.

So yeah, the OP has a point, and is not a moron. Managed code doesn't have "zero flaws" but statistics clearly point out that the chances of a buffer overflow vulnerability will be vastly less in managed code than "manually managed" C. Managed/Unmanaged is a decision that should be thought through during the design phase by a smart software architect and a smart InfoSec guy, not made by "what we always do" and emotional name-calling.

Re:Yet again C bites us in the ass (0)

Anonymous Coward | about 4 months ago | (#46690173)

I agree!

We should all use Java.

But Java is written in C.

So we should use a Java interpretter written in Java.

And for Ultra Speed and Security, we can have recursion. A java machine, running on a java machine, running on a java machine written in java.

Who needs speed when you have security. Sure my machine takes 3 weeks to boot, but hey, it's secure.

Re:Yet again C bites us in the ass (-1)

Anonymous Coward | about 4 months ago | (#46690289)

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.

Oh, great. A car analogy from a moron.

You don't really understand how computers work, do you? 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.

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

Because, yeah, with C you do have to understand everything you do. I can tell from your one post that you find that difficult. Your car analogy was like a Thalidomide baby trying to throw a hand grenade.

Re:Yet again C bites us in the ass (0)

Anonymous Coward | about 4 months ago | (#46690595)

Your nuclear detonation of a post doesn't make me feel any more warm and fuzzy about C.

No, bounds checking DOES work, and the best way to deal with it is to just FAIL HARD and lock up. This is the kind of tough love needed, not ONE MUST BE A MASTER OF EVERYTHING about C before you release a single line of code.

Re:Yet again C bites us in the ass (2, Insightful)

Anonymous Coward | about 4 months ago | (#46690635)

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." [howstuffworks.com]

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 (0, Flamebait)

santax (1541065) | about 4 months ago | (#46690449)

Hi, if you don't mind, I like to do with my computers what I want. Including direct memory access. If I want to be limited I would buy something from Apple. Thanks.

Re:Yet again C bites us in the ass (0)

Anonymous Coward | about 4 months ago | (#46690643)

Hi, if you don't mind, I like to do with my computers what I want. Including direct memory access. If I want to be limited I would buy something from Apple. Thanks.

Apple? Who used openssl for how many years? I can't tell if you're trying to be funny or not.

Re:Yet again C bites us in the ass (1)

msauve (701917) | about 4 months ago | (#46690469)

MS-BASIC, FTW!

Re:Yet again C bites us in the ass (2)

Eravnrekaree (467752) | about 4 months ago | (#46690501)

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 (1)

skids (119237) | about 4 months ago | (#46690555)

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.

My computer is too busy calculating an MD5 in a managed memory VM that doesn't even have an unsigned or sized integer types and thus must perform basic left barrel roll operations in about 50 opcodes worth of abstraction container dereferencing, to allow me to respond to this post appropriately.

Re:Yet again C bites us in the ass (0)

Anonymous Coward | about 4 months ago | (#46690747)

Oh, come off it! It is perfectly possible [twmacinta.com] to write a fast MD5 implementation in a bounds checked language - most of the checks will even be compiled away. Even if it wasn't, we could write our super-fast MD5 in assembly or whatever and call it when needed, just like we do with other stuff.
This bug was not in a performance critical piece of code. You could have written it in anything from Ada to Haskell or Lisp. Yes, it would have added some extra bounds checks. Which is great, because that's just what this code was missing.

Re:Yet again C bites us in the ass (1)

AlphaBro (2809233) | about 4 months ago | (#46691021)

Don't use Java and its shitty VM; there are better managed languages out there.

Re:Yet again C bites us in the ass (0)

Anonymous Coward | about 4 months ago | (#46691009)

I agree that C isn't really appropriate for a lot of these tasks, especially when security is crucial. However, managed memory doesn't have to be the alternative. It's perfectly possible to have a language that requires explicit memory management but does bounds checking. Many such languages have been created, in fact, although C has outlasted nearly all of them.

Yes!!! (5, Funny)

Areyoukiddingme (1289470) | about 4 months ago | (#46690145)

*air-punch*

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

It's really annoying (2)

mikein08 (1722754) | about 4 months ago | (#46690395)

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 (1)

Anonymous Coward | about 4 months ago | (#46690461)

This bug is almost 10 years old, are you sure that YOU didn't write it?

Re:It's really annoying (3, Insightful)

skids (119237) | about 4 months ago | (#46690619)

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 (0)

Anonymous Coward | about 4 months ago | (#46690835)

No offense, but I doubt you've ever written code that comes under the level of scrutiny of something like openssl.

All these bugs are mind blowing (3, Insightful)

93 Escort Wagon (326346) | about 4 months ago | (#46690473)

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:All these bugs are mind blowing (0)

Anonymous Coward | about 4 months ago | (#46690953)

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...

Can we please stop crediting the NSA leaks for (among other things) security researchers looking for bugs in obscure things like... commonly used crypto libraries? It's starting to sound a little pathetic. This is what these people do for their day jobs, and it's hardly the first time we've had to run around patching our OpenSSL libraries.

US-CERT [us-cert.gov]

Who committed the code? (1)

Anonymous Coward | about 4 months ago | (#46690785)

Any word on who was responsible for this bug?

RHEL / CentOS / Fedora updates now available (4, Informative)

seifried (12921) | about 4 months ago | (#46690841)

RHEL updates are available:

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

CentOS updates are available:

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

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 [fedoraproject.org]

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

The problem is C (0)

Anonymous Coward | about 4 months ago | (#46690987)

How much more of this has to happen before people admit that C is not an appropriate language for writing security-critical software?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>