LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 04-08-2014, 12:10 PM   #1
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,106

Rep: Reputation: 805Reputation: 805Reputation: 805Reputation: 805Reputation: 805Reputation: 805Reputation: 805
CVE-2014-0160: Heartbleed Bug: OpenSSL Vulnerability


Quote:
The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.
See http://heartbleed.com/ for complete information and recommendations:
Quote:
What versions of the OpenSSL are affected?

Status of different versions:

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable

Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.
OpenSSL 1.0.1g is the upgrade that fixes the bug.

Hope this helps some.
 
Old 04-08-2014, 08:42 PM   #2
lleb
Senior Member
 
Registered: Dec 2005
Location: Florida
Distribution: CentOS/Fedora
Posts: 2,563

Rep: Reputation: 475Reputation: 475Reputation: 475Reputation: 475Reputation: 475
yup. good information to pass around. also good to see that companies like RedHat have already stepped up and not only fixed the bad code but removed several of the older encryption models to increase security.

https://securityblog.redhat.com/tag/tls/

in fact RedHat fixed it back in Dec of 2013.
 
Old 04-09-2014, 08:47 AM   #3
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,106

Original Poster
Rep: Reputation: 805Reputation: 805Reputation: 805Reputation: 805Reputation: 805Reputation: 805Reputation: 805
US-CERT Alert (TA14-098A) OpenSSL 'Heartbleed' vulnerability (CVE-2014-0160)

US-CERT published OpenSSL 'Heartbleed' vulnerability (CVE-2014-0160) (see https://www.us-cert.gov/ncas/alerts/TA14-098A), dated 04/08/2014 08:46 AM EDT.

The US-CERT Notice includes the following:
Quote:
... Any keys generated with a vulnerable version of OpenSSL should be considered compromised and regenerated and deployed after the patch has been applied.

US-CERT recommends system administrators consider implementing Perfect Forward Secrecy (http://en.wikipedia.org/wiki/Perfect_forward_secrecy) to mitigate the damage that may be caused by future private key disclosures.
Essentially, don't doddle, get on the stick, do it now.

Hope this helps some.

Slackware users: Slackware released upgraded packages for release versions 14.0, 14.1 and Current 04/08/2014 (prior releases are not affected).
 
Old 04-09-2014, 01:12 PM   #4
Habitual
Senior Member
 
Registered: Jan 2011
Distribution: Undecided
Posts: 3,566
Blog Entries: 1

Rep: Reputation: Disabled
I'm a little unclear on something, This issue only affects SSH keys, and NOT a site's SSL Certificate(s)?
Sorry if that's lame, but there's way too much "new" data for me to process my question atm.

I hope I don't have to re-key a hundred+ servers.

Thanks.
 
Old 04-09-2014, 01:45 PM   #5
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,106

Original Poster
Rep: Reputation: 805Reputation: 805Reputation: 805Reputation: 805Reputation: 805Reputation: 805Reputation: 805
Perhaps a look-see at https://www.schneier.com/ and an article he recommends as a worthwhile read, http://arstechnica.com/security/2014...oulette-style/ and http://www.openssl.org/docs/HOWTO/keys.txt as well as http://www.openssl.org/docs/HOWTO/certificates.txt.

Both the certificate and keys documents are found in doc/HOWTO in an installed OpenSSL.

Hope this helps some.
 
Old 04-09-2014, 01:46 PM   #6
Habitual
Senior Member
 
Registered: Jan 2011
Distribution: Undecided
Posts: 3,566
Blog Entries: 1

Rep: Reputation: Disabled
Thanks! Reading up now...

Edit:
Mass scanner

Usage: fill up a scan.txt file with target IPs or hosts and run
Code:
python file.py
any vulnerable hosts will have an ip.txt in the directory it was run from.

Last edited by Habitual; 04-09-2014 at 02:59 PM.
 
1 members found this post helpful.
Old 04-09-2014, 03:49 PM   #7
ntubski
Senior Member
 
Registered: Nov 2005
Distribution: Debian
Posts: 2,513

Rep: Reputation: 855Reputation: 855Reputation: 855Reputation: 855Reputation: 855Reputation: 855Reputation: 855
Quote:
Originally Posted by lleb View Post
https://securityblog.redhat.com/tag/tls/

in fact RedHat fixed it back in Dec of 2013.
I don't see evidence of that in the link you posted.
 
Old 04-09-2014, 09:42 PM   #8
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 539

Rep: Reputation: 51
Quote:
Originally Posted by Habitual View Post
Thanks! Reading up now...

Edit:
Mass scanner

Usage: fill up a scan.txt file with target IPs or hosts and run
Code:
python file.py
any vulnerable hosts will have an ip.txt in the directory it was run from.
the issue presents itself when a tls layer (aka ssl/tls library) is hooked into the listening port and a socket is made for the connection. the issue around certs is rather basic. server side has the private key which is used in the asymmetric process for securely exchanging the dynamic symmetric keys used to secure the communications. if the private key is exposed then the cert is now compromised and so are any additional data streams built using that cert. the PFS option helps but is not always used. but even having the private key does not mean the public at large can "see" anything, the hacker would need to be able to collect unicast data streams that are far away, etc, which is not so trivial.

the crux of the issue is, this tls issue exposes data from RAM, which could be parts of the unencrypted data from a TLS stream, which is a bad thing. the pita part is, after patching, new certs need to be generated using a new private key. some devices build an initial local CA during install time used for self-signing, this can be a pita to gen a new local CA and then redo the self-signed certs, and it gets more of a pita depending on if/how these self-signed certs were deployed, etc.

wow, some new "heartbeat" feature turned out to be not so good. in this day & age it baffles me why functions like this are not fuzz'd beyond the dead horse before being released.

well, on a cheery note, happy fixin.
 
Old 04-09-2014, 11:08 PM   #9
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 539

Rep: Reputation: 51
this is a good read.

http://article.gmane.org/gmane.os.openbsd.misc/211963

a blatant disregard for memory management? how so, this is a sensitive library used to ensure privacy, surely it was reviewed a zillion times before being compiled, and the fuzz'd for added assurance?,...... makes you wonder why it was done wrong, and why it took until now to catch.

if i am not mistaken, only the memory address space used by the process handling the tls library can be leaked. i do not believe its any random parts of all memory, but please correct me on this if need be........

Last edited by Linux_Kidd; 04-09-2014 at 11:09 PM.
 
Old 04-10-2014, 12:41 AM   #10
ziphem
Member
 
Registered: Feb 2004
Location: US / EU
Distribution: Fedora 20
Posts: 129

Rep: Reputation: 18
What do you think would be the best approach to fix this issue for users (particularly lesser experienced users) of EOL distros, such as Fedora 18? I don't think there will be any sort of fix pushed since those distros are EOL.

Thanks.
 
Old 04-10-2014, 01:52 AM   #11
ilesterg
Member
 
Registered: Jul 2012
Location: Philippines
Distribution: CentOS, Debian, Oracle Linux, AIX
Posts: 352

Rep: Reputation: 46
This caused quite a panic, with CloudControl sending out press releases to its customers as early as yesterday.
 
Old 04-10-2014, 08:38 AM   #12
angryfirelord
Member
 
Registered: Dec 2005
Posts: 499

Rep: Reputation: 59
Quote:
Originally Posted by Habitual View Post
I'm a little unclear on something, This issue only affects SSH keys, and NOT a site's SSL Certificate(s)?
Sorry if that's lame, but there's way too much "new" data for me to process my question atm.

I hope I don't have to re-key a hundred+ servers.

Thanks.
SSH and SSL are two different projects. OpenSSH is unaffected.
 
Old 04-10-2014, 08:42 AM   #13
Habitual
Senior Member
 
Registered: Jan 2011
Distribution: Undecided
Posts: 3,566
Blog Entries: 1

Rep: Reputation: Disabled
Quote:
Originally Posted by angryfirelord View Post
SSH and SSL are two different projects. OpenSSH is unaffected.
Yes, I got that "now" after much research in these last few days. Thanks!

Still a good time to review and update Security practices for remotely managed hosts.
 
Old 04-10-2014, 09:05 AM   #14
Linux_Kidd
Member
 
Registered: Jan 2006
Location: USA
Posts: 539

Rep: Reputation: 51
Quote:
Originally Posted by ziphem View Post
What do you think would be the best approach to fix this issue for users (particularly lesser experienced users) of EOL distros, such as Fedora 18? I don't think there will be any sort of fix pushed since those distros are EOL.

Thanks.
install new openSSL package (just because its not in a repository for the specific distro that doesnt mean you are stuck), or recompile with the heartbeat option disabled.

installing "new" doesnt mean you need to go "up" in version, you can also downgrade to get away from the heartbeat option, etc. one needs to ask themselves, other than security related fixes (which not every new version has), why are you upgrading the package? many time new versions have additional features, and in this case the new feature was, well, [fill in your words here].
 
Old 04-10-2014, 11:53 AM   #15
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,478

Rep: Reputation: Disabled
Quote:
Originally Posted by Linux_Kidd View Post
this is a good read.

http://article.gmane.org/gmane.os.openbsd.misc/211963

a blatant disregard for memory management? how so, this is a sensitive library used to ensure privacy, surely it was reviewed a zillion times before being compiled, and the fuzz'd for added assurance?,...... makes you wonder why it was done wrong, and why it took until now to catch.

if i am not mistaken, only the memory address space used by the process handling the tls library can be leaked. i do not believe its any random parts of all memory, but please correct me on this if need be........
Maybe it's time for a fork ...
 
  


Reply

Tags
cve-2014-0160, openssl


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


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: How to find out if your server is affected from Openssl Heartbleed vulnerability (CVE-2014-016 LXer Syndicated Linux News 0 04-08-2014 11:20 AM
LXer: Heartbleed: Serious OpenSSL zero day vulnerability revealed LXer Syndicated Linux News 1 04-08-2014 08:38 AM
CVE-2014-0038: Linux Kernel Remote Memory Corruption Vulnerability unSpawn Linux - Security 1 02-19-2014 02:05 AM
CVE-2014-0038: Linux Kernel Remote Memory Corruption Vulnerability unSpawn Linux - News 0 01-31-2014 11:09 PM


All times are GMT -5. The time now is 12:55 PM.

Main Menu
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