"memcpy(bp, pl, payload);"
That’s the code that broke the camels back. Someone commented here: http://gizmodo.com/how-heartbleed-works-the-code-behind-the-internets-se-1561341209
what I was going to say anyway – that the reason the size of data may not have seemed like an important thing to verify was that it wasn’t coming from humans … it was coming from a trusted program which would never lie (until the protocol was exploited on purpose!)
“I’m not justifying, but I can understand why this went unnoticed for so long. Since it’s not input from dumb users that you’re validating, there’s no reason (other than “just in case” which obviously should have been good enough) that in a real-world scenario you would ever get an incorrect-length Heartbeat. The only time it’s an issue is when it’s being intentionally exploited. Obviously that should have been considered also but like I said I can see why it was overlooked.” — is what someone commented below the article.
An excellent video about this was also in the comments on the gizmodo.com article page – here it is embedded here from Youtube.com.
The HeartBleed Bug – http://heartbleed.com/ pretty much affects everyone. Did anything actually happen to you yet because of it? Probably not. So what is it and why do I care?
These guys http://vimeo.com/91425662 did a pretty good video explaining the how and why of it … and why it’s not a good thing. Supposedly it can be done TO either side … A Web Server (hopefully not the one you just transacted something on) or a Client (Web Browser) by a malicious web server.
Data gets delivered to the attacker from memory space used by the Web Servers OpenSSL library (program code)(or Client web program?) by tricking it during a “heartbeat” KEEP ALIVE type of protocol. The size of a heartbeat request’s payload can be falsified causing the other end to respond back with data from more of its memory than is necessary. And that memory can contain information that shouldn’t be divulged such as key codes that protect the Secure Web (SSL/TLS) session and up to an end users user and password data.
Web sites … everybody that is anybody is already (or has already) determined if their servers are vulnerable and are updating their OpenSSL software if necessary. So going forward there shouldn’t be many BIG COMPANY or BANK servers that are vulnerable … But smaller companies can still be vulnerable … which leaves YOU vulnerable.
Supposedly this bug has been around for about 2 years. No one discovered it until now. Wow! Just Wow!
So what should you do about this? Well change any online passwords you have … and probably change them again in about a week or so unless you know for sure that the web site in question has already fixed the problem or didn’t have the problem.
What about other hardware such as routers for cellular and WiFi and such? Well I have one vendor that has already sent out an email bulletin that just came in this evening saying that all affected products should get their firmware update when it comes out in a few days. MOST routers like this do not have an Internet facing web server anyway … and if it is capable of turning that on – make sure that it is off. That would be a SERVICES or ADVANCED setting somewhere like that. Requesting Updates from the device could be using SSL so that would be a no-no probably until you get a firmware update and manually install it to the device. If you use any advanced parts of a router – say it has built-in VPN capability you should check if the firmware should be updated to protect that functionality.
In summary … we will probably all be Ok. This is a lot of hype over this … but it needs it. Enough to wake up the people that need to fix the problem. Most end users don’t have much to do. If any of my customers has any questions – feel free to contact me. If you are considering purchasing products from me – feel free to contact me. I’m obviously not the authority on this problem – but I know enough from what I have read combined with my own personal knowledge base. I obviously cannot take public inquiries about this nor should I.
Alan Spicer Marine Telecom
communications @ marinetelecom.net
+1 954 683 3426