amuck-landowner

OpenSSL insecure and has been for two years.

drmike

100% Tier-1 Gogent
Should be new updates for OpenSSL pushed out today...  and other programs that depend on OpenSSL..

Source: http://arstechnica.com/security/2014/04/critical-crypto-bug-in-openssl-opens-two-thirds-of-the-web-to-eavesdropping/

The warning about the bug in OpenSSL coincided with the release of version 1.0.1g of the open-source program, which is the default cryptographic library used in the Apache and nginx Web server applications, as well as a wide variety of operating systems and e-mail and instant-messaging clients. The bug, which has resided in production versions of OpenSSL for more than two years, could make it possible for people to recover the private encryption key at the heart of the digital certificates used to authenticate Internet servers and to encrypt data traveling between them and end users. Attacks leave no traces in server logs, so there's no way of knowing if the bug has been actively exploited. Still, the risk is extraordinary, given the ability to disclose keys, passwords, and other credentials that could be used in future compromises.
 

splitice

Just a little bit crazy...
Verified Provider
FYI one of the discoverers of the bug isnt too worried about it.

Heap allocation patterns make private key exposure unlikely
https://twitter.com/neelmehta/status/453625474879471616
More information:

What if the requester didn't actually supply payload bytes, like she said she did? What if pl really is only one byte? Then the read from memcpy is going to read whatever memory was near the SSLv3 record and within the same process.

And apparently, there's a lot of stuff nearby.

There are two ways memory is dynamically allocated with malloc (at least on Linux): using sbrk(2) and using mmap(2). If the memory is allocated with sbrk, then it uses the old heap-grows-up rules and limits what can be found with this, although multiple requests (especially simultaneously) could still find some fun stuff1.

The allocations for bp don't matter at all, actually. The allocation for pl, however, matters a great deal. It's almost certainly allocated with sbrk because of the mmap threshold in malloc. However, interesting stuff (like documents or user info), is very likely to be allocated with mmap and might be reachable from pl. Multiple simultaneous requests will also make some interesting data available.

So what does this mean? Well, the allocation patterns for pl are going to dictate what you can rea
I would be suprised if any malicious exploits have been widely spread / used yet (well unless you count the NSA or similar as malicious). Thats not to say you shouldn't be patching your servers ASAP (All X4B servers are patched), just facts that you should take into consideration before stressing.
 

Hxxx

Active Member
You know what is wrong and epic about all of this?

What about all those EMR portals used in medical offices to enter patient records? All of them use SSL, and is not much different, than any other websites, other than the [ HIPAA] guidelines and recursive testing for vulnerabilities. All of them exposing data for years...

I'm impressed nobody has mentioned this, not even the organizations dedicated to this field.  

All of those companies should void Doctor and Assistants login credentials and provide new ones. Also enable 2nd authentication which is not common in the area, God knows why...

The internet is not ready for medical stuff yet. 
 

kaniini

Beware the bunny-rabbit!
Verified Provider
The OpenSSL bug is actually a result of their decision to cache memory chunks instead of immediately releasing them using free(2). Had they used free(2) on the memory chunks, the result would have been that the webserver crashed on an illegal memory access instead of key material compromise.

That is incidentally the change I made to OpenSSL earlier today in Alpine, so that any exposure to future OpenSSL bugs of this type will be limited. Just call it a hunch, but I am sure there's more defective code in there.
 
There is more defective code. You should see the results of coverity prevent against the openssl tree, quite a few theoretical null derefs, no bounds checking on some things, others.

They decided to avoid calling free() because of the slowdown it would cause, so they cached it. You can view this for yourself by profiling.
 

DomainBop

Dormant VPSB Pathogen
OpenSSL insecure and has been for two years.
Insecure for 2 years and the bug was first discovered 2 years ago by the NSA and they've been actively exploiting it for 2 years according to a report first published by Bloomberg. 

The U.S. National Security Agency knew for at least two years about a flaw in the way that many websites send sensitive information, now dubbed the Heartbleed bug, and regularly used it to gather critical intelligence, two people familiar with the matter said.

The NSA’s decision to keep the bug secret in pursuit of national security interests threatens to renew the rancorous debate over the role of the government’s top computer experts.
full story: http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html

RT's take on the Bloomberg story: http://rt.com/usa/nsa-knew-heartbleed-hacking-years-004/
 
Top
amuck-landowner