New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
CentOS and RHEL backported the fix to the version of OpenSSL currently shipped with 6.5. You can tell if you have the fixed version or not by checking the build date from "openssl version -a". It should be April 8, 2014.
A useful thread discussing the issue over on WHT, Steven at rack911 makes some useful points.
http://www.webhostingtalk.com/showthread.php?t=1364636
I doubt you can get 64kb of anything in the RAM.
However, you can get 64kb from the address space of a process that uses the vulnerable OpenSSL library.
Probably because you were.
Are you using cPanel? If so, it was automatically updated on Tuesday when the fix was released and just needed an Apache restart.
If you are using CentOS 5.x then you don't need to do anything.
Nope..Im not using cpanel..
thething that makes me confuse is, as far as I remember, I have not updated my server for quiet long time. and when I know about this exploit, I tried to update, but there is no openssl update available...
In some distros the patch was backported so you don't necessarily have to see an update in the openssl package version.
openssl version -aThe build date has to be >= April 7th
As long as you have a changelog entry dated 8th April regarding Heartbeat, you have the fixed version.
http://xkcd.com/1354/
if my site doesnt use https, is it can be affected too?
Obviously people can eavesdrop on data going to/from your server if they have access to the packets being transferred. But your web server/proxy won't leak memory contents if it's not using SSL (if :443 doesn't accept connections).
Note that it's not just 443 that can be an entry point for the attack. Anything that uses the vulnerable versions openssl is, e.g. mail
Saw it after the EFF linked to it on Twitter. XKCD couldn't have explained this more simply
Summary from major providers : http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/
Big surprise, everyone! The NSA knew about Heartbleed for two years!
http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html
The only evidence they mention is "two people familiar with the matter said". Very convincing!
This is Bloomberg, not the Daily Mail. Considering their myriad business interests and the reputation they want to uphold, they wouldn't move a story of this magnitude without having good sources behind it.
I have no idea if it's fact or not (quite frankly I won't be surprised if it is), but that statement is just . . .
I am not sure if I understand this correct. Certs and encryption keys switch. After OpenSSL update, restarts, etc... are old certs vulnerable only if someone exploited it already? I understand that there's no way to tell if this happened and it's smart to replace them, change passwords and so on.. but are old certificates and encryption keys still vulnerable after OpenSSL update or they are only potentially dangerous because someone may accessed memory before OpenSSL update (with related service restart)?
Yes.
That would mean they found out about it right from the start (the code in question was first available only 2.25 years ago), implying they have instant code audits which are more thorough than the ones of the OpenSSL developers. Not impossible, but is it very probable?
Agreed.
The source of the evidence doesn't sound very convincing, but I don't doubt a second of that actually having happened. It isn't that hard to monitor the overall OpenSSL development process
on their git repo; they only push commits every other day or so. As far as I know, there are only four active devs.
So all you'd have to do is to get a few well-trained analysts, then you've got instant supervision of the code base. Reviewing the code quickly, on a per-commit basis, most likely does not require a lot of time to those analysts, and it barely takes any resources. If the NSA were serious about monitoring everything - they were, they are, and they will be - there's hardly any way they could've ignored bugs in OpenSSL, considering that is a fantastic attack vector for them.
Lol...I knew someone desperate for clicks was going to try involve the NSA somehow. That is like catnip for some people. Humans really disappoint me sometimes.
Fully agree, but that would mean exactly what I described in the first section of my reply. In that case OpenSSL might want to consider outsourcing their reviews to the NSA