Flutterby™! : Heartbleed OpenSSH bug

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

Heartbleed OpenSSH bug

2014-04-07 22:22:12.276763+00 by Dan Lyke 12 comments

Huh. Heartbleed Bug is a vulnerability in OpenSSH OpenSSL that, from my reading, says that in theory, if you connect to a compromised server, the server server can potentially read memory, including possibly private key information from your client server HTTPS machine.

No indication of an actual exploit in the wild, but you should make sure your SSH is up-to-date, and think about multi-layered security.

Apparently there are exploits in the wild, update your OpenSSL clients, and, yes, pay your CA to re-auth new keys.

Speaking of which, I realized recently that because I'm using my GPG and SSH keys without a passphrase, I'm at the mercy of anything I run as my primary user on my hardware.

Careful, kids...

[ related topics: Children and growing up Interactive Drama Cryptography ]

comments in ascending chronological order (reverse):

#Comment Re: made: 2014-04-08 15:23:57.17824+00 by: Dan Lyke

existential type crisis : Diagnosis of the OpenSSL Heartbleed Bug

What should a website operator do about the Heartbleed OpenSSL exploit?

#Comment Re: made: 2014-04-09 13:34:08.832974+00 by: meuon [edit history]

In that linked article where three points:

  1. Pay money for security audits of critical security infrastructure like OpenSSL
  2. Write lots of unit and integration tests for these libraries
  3. Start writing alternatives in safer languages

I agree with the first one, although I know a lot of work is done there, more is better.

#2 and #3 seems to be the mantra of a new generation that think XXX language is the cure-all, without understanding that C and libraries written in it are the core of almost everything. Core stuff is written in C (C++?) or maybe assembler.. is there a new option?

The unit/integration tests would have passed.. because it worked as expected. Close examination and breaking it with a sledgehammer is how you find these things.

#Comment Re: made: 2014-04-09 15:35:46.316011+00 by: TheSHAD0W

Core stuff is currently written in C/ASM for efficiency purposes, but in this day and age it may be worthwhile to sacrifice some of that efficiency for the sake of security. I can envision a language based on C where memory allocation is specifically managed and pointers can no longer be manually defined, which would cause a performance hit but would reduce the chance of this sort of bug appearing.

(I'm sure such languages already exist, but building a new one based on C would make it easier to port existing code to it. Note: Not "easy", but "easier".)

#Comment Re: made: 2014-04-09 16:02:46.83174+00 by: Dan Lyke

So the issue of the other language is interesting: Java? How many security patches have we seen for that? JavaScript? Mayyyyybe. Python? Perl?

I think the real language that's going to supersede the modern crop is going to be one that lends itself to strong static code analysis. That may just mean better code analyzers for C++.

And as I noted somewhere and can't find right now, for a long time I've been reading crypto folks talk about things like minimizing the amount of time that passwords and raw keys are in memory, and flushing that memory before freeing it.

The more abstract the interface to the hardware, the more possibility that something else is going to get in the way of good practices: Were these blocks of uninitialized data from buffers left lying around by using things like the buffered fopen()/fread() functions rather than going straight to the the kernel with open() and read()? What happens when you're 14 levels of abstraction deep into buffer management code that's automatically resizing on the fly?

#Comment Re: made: 2014-04-09 16:08:55.81226+00 by: Dan Lyke

https://xkcd.com/1353/ and as usually, the mouseover text wins.

#Comment Re: made: 2014-04-09 20:29:33.729685+00 by: John Anderson

My tiny little toe dip into the area leads me to say, Go is quite nice and has a lot of the types of things you'd want in a "safe" systems-level language.

#Comment Re: made: 2014-04-09 22:36:15.854075+00 by: Jack William Bell

Go bothers me.

Why? Because, well, Google. If someone were to do a separate open-source clean-room implementation from the spec (like Mono was SUPPOSED to be for .NET) maybe it wouldn't be an issue to me.

That said, I really like Goroutines.

#Comment Re: made: 2014-04-10 01:11:30.822815+00 by: meuon

I only remember this from dating a redhead that was an Ada programmer... but wasn't Ada supposed to be a capable, but safer replacement for C. I know she was coding for the Javelin missile project... That's what she said, anyway.

#Comment Re: made: 2014-04-10 22:22:23.494205+00 by: Dan Lyke [edit history]

This is worth reading: Theo de Raadt on why OpenSSL's coding style deliberately worked around OpenBSD's attempts to detect flaws like this.

#Comment Re: made: 2014-04-11 13:31:19.129443+00 by: Dan Lyke

http://www.tedunangst.com/flak...alysis-of-openssl-freelist-reuse

#Comment Re: made: 2014-04-11 22:33:39.04131+00 by: spc476

There's an article about using ATS to fix OpenSSL issues. You can embed untrusted C code in ATS, and slowly replace it with new code, so you won't have to start over completely from scratch.

#Comment Re: made: 2014-04-12 15:17:44.987291+00 by: TheSHAD0W

http://www.theverge.com/us-wor...o-retrieve-private-security-keys