Found a Python PoC: http://s3.jspenguin.org/ssltest.py Edit: and just used it to dump 64K from a known-vulnerable device we control. Got a session cookie. Jeez.
Works pretty well on openssl.org...
The Heartbleed Bug
391–400 of 547 posts
Re: The Heartbleed Bug
#392Some Facebook servers are vulnerable for the Heartbleed bug: http://pastebin.com/dmYYpx2y
Re: The Heartbleed Bug
#393Scary what the implications of this will be for OpenVPN traffic that has been captured and stored over the past 2 years.
None really.
Exploiting this requires a client that sends a malicious Heartbeat packet with a large payload size.
This is unlikely to have happened in the past without any malice.
Re: The Heartbleed Bug
#394Earlier quoted context omitted.
This is one reason I'd like to see the removed LLVM C backend brought back and modernized, with Rust as the source language. Rust is safe, has no mandatory garbage collector, and has a much lower impedance mismatch with C or C++ than most higher level languages, so it should work well for libraries that are expected to integrate with C code.
I'm not clear why you'd want to compile your rust down to C, only to then compile that C again? Surely you're better off with a single compiler invocation, and taking rust straight to object code? I know that historically it's been easier to write a code generator than a compiler backend, but with LLVM you get the backend just as cheaply as the code gen.
Makes it easier to target embedded arches. For example, LLVM doesn't target the MSP430 from TI, but there is a gcc fork for it. Sure, you can write a new backend for LLVM, but that's a whole different ballgame.
This way it would be Rust -> LLVM IR -> C -> GCC for MSP430.
Re: The Heartbleed Bug
#395Earlier quoted context omitted.
@stormbrew is correct about ubuntu, use -a or -v -b openssl version -v -b OpenSSL 1.0.1 14 Mar 2012 built on: Wed Jan 8 20:45:51 UTC 2014
I'm totally confused by this. I'm running ubuntu LTS 12.04 and did sudo aptitude update sudo aptitude upgrade openssl and then ran openssl version -a and got the same results as you. How can it be built on January 8th if the patch was just made today? [EDIT] running sudo aptitude upgrade upgraded properly and now I'm getting a version that was compiled earlier today. I'm guessing I needed to update another package as…
upgrade will work because it updates libssl1.0.0 which is the package you want upgraded :)
Openssl is the command line package and libssl1.0.0 is the library. i was able to upgrade openssl without upgrading libssl1.0.0.
ben@ip-10-0-0-76:~$ dpkg -s libssl1.0.0 |grep Version
Version: 1.0.1e-3ubuntu1
ben@ip-10-0-0-76:~$ dpkg -s openssl |grep Version
Version: 1.0.1e-3ubuntu1
ben@ip-10-0-0-76:~$ sudo apt-get install openssl
...
ben@ip-10-0-0-76:~$ dpkg -s libssl1.0.0 |grep Version
Version: 1.0.1e-3ubuntu1
ben@ip-10-0-0-76:~$ dpkg -s openssl |grep Version
Version: 1.0.1e-3ubuntu1.2
ben@ip-10-0-0-76:~$ openssl version -a
OpenSSL 1.0.1e 11 Feb 2013
built on: Mon Jul 15 12:44:45 UTC 2013
platform: debian-amd64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"
ben@ip-10-0-0-76:~$ sudo apt-get install libssl1.0.0
ben@ip-10-0-0-76:~$ dpkg -s libssl1.0.0 |grep Version
Version: 1.0.1e-3ubuntu1.2
ben@ip-10-0-0-76:~$ openssl version -a
OpenSSL 1.0.1e 11 Feb 2013
built on: Mon Apr 7 20:33:19 UTC 2014
platform: debian-amd64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"
Re: The Heartbleed Bug
#396Earlier quoted context omitted.
First, I do realize that rewriting the software stack from the ground up to have only managed code is a huge task. I do think that as an industry, we should set a goal of having at least one server implementation along these lines (where 'set a goal' may mean, say, grants or calls for proposals). Microsoft Research implemented an experimental OS like that, although it probably didn't have all the features a modern OS…
Do not like the term "C/C++", and especially in this context. Modern C++ makes avoiding this sort of bug as easy as doing so in the "managed" languages already discussed. This is as much a cultural as a technical problem; C really is in the last chance saloon for this sort of problem, we have the solution to hand, but a strong cadre of developers will still only consider C for this sort of work.
Thank you for pointing out that this is not an issue in C++, only in C. There are times when we need C and one can write C code and compile it with a C++ compiler. It's an option to help ease people to modern, idiomatic C++, but please don't lump the two together. C and C++ are two entirely different languages and C++ is much safer.
Re: The Heartbleed Bug
#397Earlier quoted context omitted.
This sort of argument is becoming something of a fashion statement amongst some security people. It's not a strictly wrong argument: writing code in languages that make screwing up easy will invariably result in screwups. But it's a disingenuous one. It ignores the realities of systems. The reality is that there is currently no widely available memory-safe language that is usable for something like OpenSSL. .NET and…
Other than C there is also C++ and D if you don't want to stray to far from C. The problem with C++ is that even though it is possible to adapt to a memory safe programming style with C++ the concepts are not prevalent in the community.
Secure coding is very prevalent in C++ (outside the group of old C programmers who write C++ code as if it were C). C++ is far safer than C.
Re: The Heartbleed Bug
#398Earlier quoted context omitted.
Other than C there is also C++ and D if you don't want to stray to far from C. The problem with C++ is that even though it is possible to adapt to a memory safe programming style with C++ the concepts are not prevalent in the community.
C++ does not have a reasonable memory safe subset. No, smart pointers do not provide real memory safety.
They are generally better than nothing, however. And they do generally offer better performance, better predictability, an a simpler implementation than other approaches to memory management and garbage collection.
Maybe a language like Rust will offer a safer alternative at some point, but that point surely isn't today, and probably not tomorrow, either. Maybe there are other languages that offer better safety, but they often bring along their own set of very serious drawbacks.
In terms of writing relatively safe code today, that performs relatively well, that can integrate easily with other libraries/frameworks/code, and can be readily maintained, the use of C++ with modern C++ techniques is often the only truly viable option.
Re: The Heartbleed Bug
#399Re: The Heartbleed Bug
#400Earlier quoted context omitted.
I agree entirely with your post, and I can't quite understand the hysteria in this thread. The odds of getting a key using this technique are incredibly low to begin with, let alone being able to recognize you have one, and how to correlate it with any useful encrypted data. Supposing you do hit the lottery and get a key somewhere in your packet, you now have to find the starting byte for it, which means having data…
I have successfully extracted a key and decrypted traffic in a lab. I'm refining my automatic process. You're forgetting analysis of the runtime layout of OpenSSL in RAM which is quite predictable on machines without defensive measures. I have a 100% success rate extracting memory and about a 20% success rate programmatically extracting the secret key of the server. I'm nearly 100% against a certain version of Apache…
runtime layout of OpenSSL in RAM which is quite predictable on machines without defensive measures
I think this is also part of the problem, if it's just storing the keys in plaintext. I've analysed some protection systems which have gone to great lengths to make sure that this isn't the case - where keys are permuted, broken up into randomly-sized chunks, and scattered amongst other randomly generated data, all of which gets moved around in memory in a random fashion periodically. Some of the state required to obtain the key is outside the process.
Obviously this makes encryption/decryption operations a lot slower. "Security costs speed. How safe do you want to be?"