@StackExchange as usual, @XKCD provides an excellent visualization. In this case however, it glosses over some of the finer details, which makes this part of the madd meddia feedding frenzdy instead of contributing to rational anlaysis.... :-(
@DeerHunter or tweeted and redditted into a reptrain.
I recently looked at my local credit union bank and they said that their site is not vulnerable to heart bleed. However, I have used my credit card in many websites such as grubhub, amazon, some charity organizations, so the credit card data can be exploited. I want to have some expert opinion be...
@LucasKauffman where's that blogpost at?? We would be able to put up a system message pointing to that, to prevent these masses of "me too!" questions.
I don't think it was done deliberately. As if the NSA were using it, I'm sure it would of been leaked by Snowden fairly sharpish. But thats what I think…
@Adnan It comes down to platform-specific details and possibly timing. Heap typically grows forward (unlike stack) so if you just started up, then most of the heap is empty, and growing toward empty space. So most of the time if you allocate 1K and retrieve 30K, you'll get 29K of zeros.
But malloc often will quickly reclaim freed space if the sizes match. so you CAN allocate space behind something that was previously allocated
So what's the chances that you'll pull the priv. key into ram, and then free the thing that you put there right BEFORE the priv. key, and then get a HB req. that gets assigned the recently-freed space.
In most operations, it's surprisingly close to zero.
But you might be able to tease out special cases where it will work.
mostly involving hitting the server right after startup, case that's the only time it's in a remotely predicatable state.
:14869317 that's pretty typical. And you'll expect go get data pulled in from buffers involved with those connections
that's why you frequently see disclosed session keys, etc. If you have a vuln. server, you can test it yourself. MOST of the time, you'll see other request or responses
I would expect that apache will read the priv. key file exactly once at intial startup, parse it, store the details internally, and then discard the original PEM data. But that's up to apache, not openssl.
Typically it does that before shedding root perms.
More and more evidence seems to be surfacing that the Heartbleed vulnerability leaks the private key portion of the SSL certificate in use.
As such this can actually mean that if an attacker was also able to passively monitor SSL traffic, when they get hold of this key, they could decrypt an unl...
@TerryChia Naw, I've probably only made a few thousand out of it. Mostly when they want to take heroic measures and change EVERY DAMN PASSWORD ON THE SERVER.
@TerryChia yer not wrong, an easy $10k will likely motivate a lot of people to just hand bugs over to google and not either go 0-day with them or sell them on elsewhere...
@TerryChia true, but I guess impact isn't always considered. Also the OpenSSL project don't have the kind of money to pay bounties, so they're reliant on others to do it
I'm torn on reviewing security.stackexchange.com/questions/45170/… . On the one hand it's spam. On the other hand the second paragraph is relevant and wasn't made by other answers.
You can base yourself on earlier press work an the best short explanation to the spirit of the all the heartbeat/heartbreak issue you can compare them to collateralized debt obligations:
You get the riskiest part of the transaction
@TerryChia Have you been following his blog in the last 4-6 months?
> Be careful when uploading your java server application to [UNIVERSITY_SERVER]. If you store it in plain text, everybody can still know ur password. You should store it in a file with encrypted password, and then unencrypted it at runtime
@TildalWave I don't know that this is true. He might be trying to prompt @TerryChia to expand the answer, any why bcrpyt et al are strong than md5 et al.
@Xander It's not relevant to answering the question IMO and could then expand into an endless discussion in the comments. @Terry's link is a good solution, perhaps even better would be adding it to the answer itself?
On the 7th of April 2014 a team of security engineers (Riku, Antti and Matti) at Codenomicon and Neel Mehta of Google Security published information on a security issue in OpenSSL. OpenSSL is a piece of software used in the encryption process; it helps you in coding your computer traffic to ensure unauthorized people cannot understand what you are sending from one computer network to another. It is used in many applications: for example if you use on-line banking websites, code such as OpenSSL helps to ensure that your PIN code remains secret. …
@LucasKauffman You know what's really sad? We're probably going to end up going chip for our credit cards, but they'll almost definitely be signature instead of PIN.
Because our financial sector is completely staffed by fuckwits.
@ScottPack @LucasKauffman interestingly the bank I'm moving to at the moment won't let you get full access to their online service unless you use their 2FA
@TerryChia Clearly, it's not. OpenSSL has indeed released 1.0.1g which is patched. @Simon is complaining that it's the same version number, then you clearly asserted what he said (at least you didn't negate it).
@Adnan Interesting. If you go to / on that site, it looks like the Heartbleed challenge is to be the first of many. (Though the page is still titled "Heartbleed Challenge")
@Iszi I'm currently trying that challenge, but I could swear they're doctoring the responses. They're too different from any responses I got from the servers I tested. It's just a hunch, though.
I have a strong feeling it's one of those honeypots @RoryM posted about
You can base yourself on earlier press work an the best short explanation to the spirit of the all the heartbeat/heartbreak issue you can compare them to collateralized debt obligations:
You get the riskiest part of the transaction
