Heartbleed SSL exploit [CVE-2014-0160]

https://lastpass.com/heartbleed/?h=Commbank.com.au

Wonder what their plan is

 

related?

http://b.capitolhillconsultants.com/2014/04/blues-for-ssl-even-if-youve-been-hiding.html

 

the lastpass check seems to be pretty useless - doesn't check for the vuln, just the server version

when I actually checked commbank for the vuln yesterday morning, it was fine

so they patched quickly or weren't affected

 

actually the lastpass check is handy, it tells you when they last updated their cert quickly - if they've updated either they were worried or they were vulnerable and have now sorted their issue.

Also, trouble in Android land with one particular version vulnerable.


Google Services Updated to Address OpenSSL CVE-2014-0160 (the Heartbleed bug)

 

I've had one fellow on twitter say that some CA's are not updating the validBefore dates on certs that have been revoked/reissued. Is that really a sound strategy?

 

How does such an exploit go undiscovered in the open source world for so long?

Its been explained to me as the lack of a bounds check,

The client requests an echo and says its 64KB of data that is being sent
the Server responds with 64KB of data, no matter how long the original request was.

I would think something like this would be pretty glaring in the code that 'many eyes' are supposed to be ensuring is free of bugs like this.

 

It worries me when I see sites that LastPass has deemed as likely vulnerable with an old cert, but have cleared the Filippo site test. Have they patched but not revoked their certs?

That makes things even worse! How do you know for sure when its actually worthwhile resetting a password?

 

I actually asked a colleague who's pretty heavily involved in the FOSS world and got this as a response, nfi the validity of it but I found it interesting

 

Look, open sauce really, really isn't as good as people would like you to believe when it comes to security.

Its all fine and dandy to have the sauce available, but if no one actually feels like reading/auditing it - then its pointless.

I have a house mate who writes a vpn client which leverages off OpenSSL in some ways - they submit bug fixes (particularly when using OpenSSL on OSX/Windows) back up the chain - but they are never committed to the main trunk because the OpenSSL believes that Windows/OSX should fix their shit - not them make it work with Windows/OSX.

Even if you do start auditing the code - the Gubmint will get you with compilers (do YOU always build from Sauce?). And if they aren't getting you with compilers, they will simply poison the CPU's - yes all of this stuff is out of reach/scope of Joe Hacker around the corner working for anonymous - but when you have entities like the NSA/GCHQ who have a real vested interest in being able to read your shit - the sky is the limit.

 

Were this a proprietary technology made by Oracle, Microsoft or whoever would it be disclosed and fixed (properly) as soon as this will (should) be?

This is a genuine question btw, not flame bait.

 

If we are putting tinfoil hats on, why would the gubmint bother with engineering an exploit that reads memory 64KB at a time. If they are in a position to make unvetted code changes, why not just make OpenSSL email private keys to shadyguy@nsa.gov every time its used.

Plausible denial might come into it, but again, why choose 64KB at a time, 64MB or no upper bounds would be equally deniable.

 

Oracle's proof is in the pudding - see Java, make of that what you will - DHS recommends you piss it off entirely.

Microsoft has been pretty good at this of late - we've had a few out-of-band "patch this now before you get 0wned" bugs - mostly surrounding .net. They also had a pretty major one with the Microsoft Update and Clearinghouse CA.

Ummm, its worked for 2 years before anyone figured it out. 64KB is pretty unnoticeable bandwidth wise, cpu cycle wise, etc.

And its not unvetted at all - its open sauce and in plain sight. Pretty sure someone is going to see a sendmail, blat, or whatever setting up an SMTP session to #teamshady.

 

bit of a list, couple of high profile sites.

xda-developers.com

steamcommunity.com

https://github.com/musalbas/heartbl...ults-of-top-1000-websites-on-april-8-1600-utc

https://github.com/musalbas/heartbleed-masstest/blob/master/top10000.txt

http://www.cnet.com/how-to/which-sites-have-patched-the-heartbleed-bug/

 

For Microsoft, the disclosure would be less technical, and there would be no way of auditing if it was properly fixed, or just hacked around. (from my fading memory back in the days of winnuke, one of the patches looked specifically for the winnuke payload, and errored around it, instead of actually fixing the exploit that was causing the crashes).

But it would be 'fixed' in a timely manner, either Out of Band if its a 'your fucked' issue, or on the next patch tuesday.

 

schools.... don't they teach data types anymore?

is is 64KB because the data length variable for the payload is a 16 bit int

EDIT: unsigned int to be more specific

 

Before spouting unfounded rubbish please do some research.

It's 64kB because that's the maximum size of a TCP 'window'. To retrieve more than that, you need to make a second/third/fourth/etc. request (which for heartbleed you can).

But it's 64kB per response because that's the limit of TCP*.



*note: TCP window scaling is a newish (1992) feature of TCP that can expand the window to 1GB, but it's not always supported for clients/servers/routers etc. so isn't safe to use without prior checking everything your packets may traverse supports it too.

 

i lol'd.

 

I wouldn't trust Lastpass either....

https://www.ssllabs.com/ssltest/ - much better.

 

So our Shady Guys have enough sway over the OpenSSL developers to persuade them to omit a bounds check... but not enough to change the data type of the payload?

 

OpenSSL site is down