SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Now things are getting furry. Folk I pretty much trust, say, Bruce Schneier for example, say:
Quote:
Basically, an attacker can grab 64K of memory from a server. The attack leaves no trace, and can be done multiple times to grab a different random 64K of memory. This means that anything in memory -- SSL private keys, user keys, anything -- is vulnerable. And you have to assume that it is all compromised. All of it.
"Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.
Half a million sites are vulnerable, including my own. Test your vulnerability here.
The bug has been patched. After you patch your systems, you have to get a new public/private key pair, update your SSL certificate, and then change every password that could potentially be affected.
At this point, the probability is close to one that every target has had its private keys extracted by multiple intelligence agencies. The real question is whether or not someone deliberately inserted this bug into OpenSSL, and has had two years of unfettered access to everything. My guess is accident, but I have no proof.
Other folk are saying, say, Errata Security, are saying, no, can't happen, don't bother regenerating keys (which is what I get from the article in a previous post). And different other folk are saying, well, here's the code, let's see, and there's no mention of keys (unless I missed something in there which is completely possible).
US-CERT is saying regenerate keys (and certificates) as is Heartbleed Bug.
Me? I think I'll regen the keys and certificates on my servers, desktop and lap top just to be on the safe side (found the how-to's in /usr/doc/openssl-1.0.1g/doc/HOWTO.
Can't hurt.
I'm also on a crusade to change all passwords for every Internet site where I have an account and password.
Can't hurt.
Might helps.
Don't know -- for absolute certain -- what's actually "true" and what's "gray" at this point and I'd rather not wait and get hit where it hurts.
"The upshot is this. What you can eavesdrop on with heartbleed hacks is dynamic stuff, stuff that was allocated only moments ago. What you probably can't get is static information. Certainly, you can't get any static information that hasn't been freed, and you probably can't get static information that was freed long ago, such as program startup. It's a great way to steal passwords from recent logins, but it's unlikely to give private keys."
Or it is just a trojan horse accessing all your SSL/TLS connections and leaking your private data to someone else.
C'mon, we're not the people, who install random stuff from the Internet without some due diligence, even if it's in the "Chrome Store". Where is the source code?
(Disclaimer: This is not about this specific extension or its author, but about the habit...)
I'm also on a crusade to change all passwords for every Internet site where I have an account and password. Can't hurt.
Yes it can. If you visit a site that hasn't been fixed yet and change your password, you're putting your old and your new password into the ram at a site where the bad guys could be snooping. And you're doing that for every site where you have an account and password, including the ones you almost never visit. That's about as bad as it gets really. Oh well, too late for you now
" I got this completely wrong! So as it turns out, I completely messed up reading the code.
Private keys are still not so likely to be exposed, but still much more likely than my original analysis suggested."
If you visit a site that hasn't been fixed yet and change your password, you're putting your old and your new password into the ram at a site where the bad guys could be snooping. And you're doing that for every site where you have an account and password, including the ones you almost never visit. That's about as bad as it gets really.
Best practice for passwords is to change them regularly, and to use a different one for each account. Even though a site has fixed a single vulnerability, it may still be compromised by blackhats.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Quote:
Originally Posted by 55020
Yes it can. If you visit a site that hasn't been fixed yet and change your password, you're putting your old and your new password into the ram at a site where the bad guys could be snooping. And you're doing that for every site where you have an account and password, including the ones you almost never visit. That's about as bad as it gets really. Oh well, too late for you now
Oh, before I do that, I'm looking for a tool that will identify whether or not the particular site is vulnerable -- so far, no good luck with that! Gone all day yesterday (450 mile round trip), today is a good day to find something that will identify-before-doing-anythng, kinda like ping. I'm scanning through the posts that include recommendations and won't touch a "bad" site until it's "clean."
The folks that discovered this problem (and attacked their own servers successfully) were pretty clear: it's a problem, it needs fixing right now and there's a chance that a whole lot of people have been compromised by bad actors that found the bug and did not tell anybody about it for their own purposes.
I'm taking it a step at a time, trying different methods of identifying unpatched sites (haven't had enough time to really report any results one way or the other).
I should have said developing a step-by-step plan for updating all passwords, not so much actually doing it until I can reliably identify whether a site is (still) vulnerable.
Oh, before I do that, I'm looking for a tool that will identify whether or not the particular site is vulnerable -- so far, no good luck with that! ...
try
Code:
https://lastpass.com/heartbleed/
for bad site identification.
HTH
John
"Testing to see what version of OpenSSL a site is running, and whether it is also supports the vulnerable Heartbeat protocol,would be legal" (From Ponce's referenced article)
Last edited by AlleyTrotter; 04-11-2014 at 09:15 AM.
Reason: Legality of test
We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.
So, if they managed to do it, why wouldn't anyone else?
Last edited by Smokey_justme; 04-11-2014 at 09:35 AM.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,541
Rep:
Quote:
Originally Posted by Smokey_justme
So, if they managed to do it, why wouldn't anyone else?
Yeah, that's exactly the point, a proof of concept: it's broke, we found it and we walked in and walked out with the keys to the kingdom and we're telling you about it. Oh, yeah, here's where to get the fix.
That's good enough for me (and probably ought to be good enough for anybody else, too, methinks).
One of the best things about Linux and the community of programmers and developers (and the community of researchers that identify errors and omissions) is that when a problem is found, it's corrected, folks are notified, and the notice and fix is propagated widely and quickly.
I know that I'm not smart enough to know how to identify unpatched sites and I know that I have to rely on other folks to tell me what to do about mitigating the impact of such. I also know that there's large communities of experts that, pretty much, donate their time and effort toward keeping things working properly (and adding improvements now and then, too); for them I am grateful. I know, too, that there are always naysayers, ready to pick nits, and, over the decades I've been doing this sort of work I've learned how to filter out the wheat from the chaff... I think.
This one, I'll take the experts' opinions to heart: is there a problem? Oh, yeah, sure looks that way (proof of concept and all). Is there a fix? Well, yeah. Are there recommendations to make some changes? Uh, yeah.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
