[colug-432] Heartbleed Heartburn

[R P Herrold]

On Thu, 10 Apr 2014, Rick Troth wrote:

> One colleague said that there is a lot of over-reaction.

I think I disagree here.  The commit in question exposed 
several things:

	- Openssl was so special in the pursuit of 
'efficiency' that they re-invented MALLOC and FREE, and did so 
less well than the reference (but corect and potentially 
slower) implementations they displaced, that would have 
provided 'cleared' buffers

	- Openssl decided to trust input received from 
multiple, un-authenticated, and unknown counter-party, without 
checking lengths received against lengths promised, in 
asynchronous, threaded code.  Hard in any event, and not well 
done

	- Openssl decided to trust input NOT protected by a 
working TLS was not tampered by a MitM

	- Openssl decided to NOT add rate limiting, or even 
logging, of keepalive renegotiations, and so encouraging brute 
force attacks [compared with quench and fallback algorithms 
commonly used elsewhere in the stack]

Schneier reposted a quip that on a scale of ten, it was an 
eleven.  Think of all the new keys, changed passwords, changed 
salts, changed shared secrets, CA certificates, more that need 
to be replaced as no-one can truly KNOW if they have been 
trawled unless they have logged every packet, ever to a given 
host, on selected ports (essentially all as one could not 
predict ... )

Also vulnerable on a local C 6.5 box beyond apache / httpd, 
and the sshd are each of these:
	sendmail when STARTTLS is offered; 
	[dovecot appears to NOT link openssl, so not there]; 
	vsftpd (sftp); 
	mysql (server and CLI clients); 
	php; 
	zabbix (which binds BOTH NSS and OpenSSL !); 
	the libvirtd (again both); 
	the wpa_supplicant (wireless NICs)

Ever used a laptop at a COLUG meeting, geek convention or a 
coffee shop?

Each of those could be induced to enter into anonymous 
keepalive ('heartbeat') discussions at the DH key negotiation 
phase (so, pre TLS secured) with strangers, and to repeatedly  
expose more and more of the heap.  With multiple inquirants, 
one can examine many 64k segments in parallel, and gather 
session IDs, session keys post DH exchange, the private keys 
themselves duly unlocked of a pass-phrase [host and mod_ssl], 
more

... I recall reporting a core that fetchmail left when 
properly provoked with cleartext passwords long ago, to ESR, 
when trawling through 'side channel leaks'

Apache is a real problem point because of site designers 
having been conditioned to not consider remote hostile parties 
being able to gather GET / POST content, and the Apache 
'efficiency' consider of using multiple long lived child 
processes, communicating through shared memory.  Arghhh.  We 
use hashes and a off host database a lot to enqueue and 
dequeue transactions with pmman, and in light of this added 
some more this week

The approach I would follow to identify success is to 
pre-fill memory with one or more readily recognizable 
patterns (canaries) such as: 
	deadbeef
and have at it [1]  It jumps out at the eye in the wire trace 
cited

-- Russ herrold

[1] http://www.owlriver.com/tips/tcpdump-tech/