LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 04-09-2014, 02:46 PM   #31
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,119

Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818

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.

Hope this helps some

Last edited by tronayne; 04-09-2014 at 02:48 PM.
 
Old 04-09-2014, 03:37 PM   #32
BenCollver
Rogue Class
 
Registered: Sep 2006
Location: OR, USA
Distribution: Slackware 14.1
Posts: 164

Rep: Reputation: 57
"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."

http://blog.erratasec.com/2014/04/wh...ivate-key.html
 
Old 04-10-2014, 02:49 AM   #33
nigelc
Member
 
Registered: Oct 2004
Location: Sydney, Australia
Distribution: Mageia 4
Posts: 309
Blog Entries: 4

Rep: Reputation: 52
There is an app for chromium that tells if sites are vulnerable.
https://chrome.google.com/webstore/d...cafdggilajhpic
 
Old 04-10-2014, 02:56 AM   #34
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 908

Rep: Reputation: 446Reputation: 446Reputation: 446Reputation: 446Reputation: 446
Quote:
Originally Posted by nigelc View Post
There is an app for chromium that tells if sites are vulnerable.
https://chrome.google.com/webstore/d...cafdggilajhpic
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...)

Last edited by jtsn; 04-10-2014 at 02:58 AM.
 
3 members found this post helpful.
Old 04-10-2014, 03:52 AM   #35
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 435
Blog Entries: 4

Rep: Reputation: 438Reputation: 438Reputation: 438Reputation: 438Reputation: 438
Quote:
Originally Posted by tronayne View Post
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
 
Old 04-10-2014, 08:46 AM   #36
BenCollver
Rogue Class
 
Registered: Sep 2006
Location: OR, USA
Distribution: Slackware 14.1
Posts: 164

Rep: Reputation: 57
http://blog.erratasec.com/2014/04/wh...ivate-key.html

" 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."
 
Old 04-10-2014, 08:51 AM   #37
BenCollver
Rogue Class
 
Registered: Sep 2006
Location: OR, USA
Distribution: Slackware 14.1
Posts: 164

Rep: Reputation: 57
Quote:
Originally Posted by 55020 View Post
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.
 
Old 04-10-2014, 05:21 PM   #38
Nh3xus
Member
 
Registered: Jan 2013
Location: France
Distribution: Slackware 14.1 32 bits
Posts: 190

Rep: Reputation: 56
Apparently, client-side applications are vulnerable too :

Like : wget, curl and git for example.

http://security.stackexchange.com/qu...ed/55250#55250

So, client machines have to be kept in mind.
 
Old 04-11-2014, 08:48 AM   #39
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,119

Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
Quote:
Originally Posted by 55020 View Post
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.

Thanks for the advice.
 
1 members found this post helpful.
Old 04-11-2014, 09:38 AM   #40
AlleyTrotter
Member
 
Registered: Jun 2002
Location: Coal Township PA
Distribution: Slackware64-14.1 (3.18.0) UEFI enabled
Posts: 360

Rep: Reputation: 77
Quote:
Originally Posted by tronayne View Post
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 10:15 AM. Reason: Legality of test
 
1 members found this post helpful.
Old 04-11-2014, 09:48 AM   #41
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,498

Rep: Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912
beware heartbleed vuln checking...
 
Old 04-11-2014, 10:34 AM   #42
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 400

Rep: Reputation: 113Reputation: 113
@tronayne:

Like all thinks.. After mass-media or general-bloge.. public got hold of it .. it all goes into deep misunderstanding..

One of the first links from the announcement of heartbleed: http://heartbleed.com/

Quote from them:
Quote:
What leaks in practice?

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 10:35 AM.
 
Old 04-11-2014, 11:29 AM   #43
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,119

Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
Quote:
Originally Posted by Smokey_justme View Post
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.

What the hell is there left to argue about?

Last edited by tronayne; 04-11-2014 at 11:32 AM.
 
1 members found this post helpful.
Old 04-11-2014, 12:25 PM   #44
WiseDraco
Member
 
Registered: Nov 2006
Location: Europe,Latvia,Riga
Distribution: slackware,slax, exMandriva
Posts: 401

Rep: Reputation: 41
i installed 1.0.1g throught slackpkg, but HTTP headers still show
Server: Apache/2.4.3 (Unix) OpenSSL/1.0.1e PHP/5.4.7

i must upgrade httpd too ? fear, after that something can stop work. slack64 14.0...
 
Old 04-11-2014, 12:28 PM   #45
NeoMetal
Member
 
Registered: Aug 2004
Location: MD
Distribution: Slackware
Posts: 106

Rep: Reputation: 19
Quote:
Originally Posted by WiseDraco View Post
i installed 1.0.1g throught slackpkg, but HTTP headers still show
Server: Apache/2.4.3 (Unix) OpenSSL/1.0.1e PHP/5.4.7

i must upgrade httpd too ? fear, after that something can stop work. slack64 14.0...


Did you restart httpd? The process has to restart to link in the updated lib
 
  


Reply

Tags
heartbleed


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT -5. The time now is 07:24 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration