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-07-2014, 02:16 PM   #121
mancha
Member
 
Registered: Aug 2012
Posts: 292

Original Poster
Rep: Reputation: Disabled

Update 20140407-1
  1. Linux kernel

    A flaw in the Linux kernel DCCP network code allows remote (or local) attackers to cause a system crash (DoS) or potentially
    execute arbitrary code via crafted DCCP packets (CVE-2014-2523).

    The vulnerable code is in the kernel's DCCP connection tracker helper which Slackware builds as a module (both generic and
    huge). In other words, if the DCCP conntrack module is not loaded (or not run via NOTRACK targets for example), the attack
    vector is non-existent (see Prophylaxis).

    Solution(s):

    • Re-build kernel 3.10.17 after applying upstream fix (for 14.1 users)
    • Upgrade to 3.10.36 (for current or 14.1 users on the latest 3.10.x)
    • Upgrade to 3.2.57 (for 14.0 users; not yet released)

    Prophylaxis:

    If you don't want to worry about patching or upgrading your kernel, you can remove the attack vector by ensuring the DCCP
    conntrack helper module never loads:
    Code:
    # echo "install nf_conntrack_proto_dccp /bin/true" > /lib/modprobe.d/CVE-2014-2523.conf
--mancha

Last edited by mancha; 04-08-2014 at 12:04 AM.
 
2 members found this post helpful.
Old 04-07-2014, 02:45 PM   #122
mancha
Member
 
Registered: Aug 2012
Posts: 292

Original Poster
Rep: Reputation: Disabled
Update 20140407-2
  1. OpenSSL

    Issues:

    1. A flaw in the TLS heartbeat extension code (introduced in version 1.0.1) can be exploited by attackers to reveal memory
      connected to either a client or server using a vulnerable version (CVE-2014-0160 aka "heartbleed").

    2. A design flaw in the way elliptic scalar multiplication is computed on curves defined over GF(2ᵐ) allows the recovery of
      ECDSA nonces via flush+reload (CVE-2014-0076).

    Solution: Upgrade to OpenSSL 1.0.1g (sig).

    Notes: For the "heartbleed" bug, affected versions include 1.0.1-beta1 through 1.0.1f (inclusive) and 1.0.2-beta1. The 0.9.8
    and 1.0.0 branches are not affected.
--mancha

========

Update #1

My initial report might not have transmitted the severity of the heartbeat vulnerability. At this point, any service linking a vulnerable
OpenSSL (1.0.1+) might have had its primary key material compromised. In other words, if you run such services you might need to
replace existing key material (e.g. web certificates, etc.). If your certificates are signed by an established CA, contact them about
the procedure for revocation and re-issuance of certificates. If you run a certificate authority yourself, take the necessary steps.

Client-side, credentials (or other private information) submitted by clients to vulnerable servers (login/password) are potentially
compromised.

Interested parties can read this rather good explanation: http://heartbleed.com/

Update #2

The good folks at Nmap (specifically Patrik Karlsson) have written a "heartbleed" detection script based on Jared Stafford's reproducer.

I've made minor tweaks and placed it at the vault for people wishing to test their systems: ssl-heartbleed.nse

Update #3

There is secondary public confirmation white hats have succeeded in stealing private keys using heartbleed.

Last edited by mancha; 04-12-2014 at 12:27 AM. Reason: Add link to CloudFlare challenge
 
4 members found this post helpful.
Old 04-08-2014, 08:59 AM   #123
moisespedro
Member
 
Registered: Nov 2013
Location: Brazil
Distribution: Slackware and LFS
Posts: 892

Rep: Reputation: 93
Hi mancha, I am trying to rebuild the new openssl version and it doesn't work

Code:
created directory `/tmp/package-openssl/etc'
created directory `/tmp/package-openssl/etc/ssl'
created directory `/tmp/package-openssl/etc/ssl/man'
created directory `/tmp/package-openssl/etc/ssl/man/man1'
created directory `/tmp/package-openssl/etc/ssl/man/man3'
created directory `/tmp/package-openssl/etc/ssl/man/man5'
created directory `/tmp/package-openssl/etc/ssl/man/man7'
installing man1/CA.pl.1
installing man1/asn1parse.1
installing man1/ca.1
installing man1/ciphers.1
installing man1/cms.1
cms.pod around line 457: Expected text after =item, not a number
cms.pod around line 461: Expected text after =item, not a number
cms.pod around line 465: Expected text after =item, not a number
cms.pod around line 470: Expected text after =item, not a number
cms.pod around line 474: Expected text after =item, not a number
POD document had syntax errors at /usr/bin/pod2man line 71.
make: *** [install_docs] Error 1
Any idea/fix?

EDIT: I commented all the parts related to documentation on the slackbuild file but that is a bit annoying imo

Last edited by moisespedro; 04-08-2014 at 09:03 AM.
 
Old 04-08-2014, 09:05 AM   #124
metageek
Member
 
Registered: Jun 2007
Location: manchester, uk
Distribution: Slackware
Posts: 118

Rep: Reputation: 24
Use the source package in patches, not the one in the original source tree. That has worked for me without any issues. You need to remove openssl-1.0.1f.tar.gz and replace it with openssl-1.0.1g.tar.gz.
 
Old 04-08-2014, 09:44 AM   #125
moisespedro
Member
 
Registered: Nov 2013
Location: Brazil
Distribution: Slackware and LFS
Posts: 892

Rep: Reputation: 93
Thanks metageek, it worked
 
Old 04-08-2014, 03:03 PM   #126
willysr
Senior Member
 
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 2,555

Rep: Reputation: 424Reputation: 424Reputation: 424Reputation: 424Reputation: 424
Official updates from slackware also arrived today
 
Old 04-13-2014, 12:48 AM   #127
Mercury305
Member
 
Registered: Jul 2012
Location: Rockville, MD
Distribution: CrunchBang / Ubuntu
Posts: 540

Rep: Reputation: Disabled
Quote:
Originally Posted by mancha View Post
Update 20140214
  1. GnuTLS

    It was discovered version 1 intermediate certificates were being incorrectly considered CA certificates by default since
    version 2.11.5. Systems with CAs in their trusted root certificate store, which issue X.509 version 1 certificates, are
    potentially vulnerable. [CVE-2014-1959 / GNUTLS-SA-2014-1]

    Solution: Upgrade to GnuTLS 3.1.21 or apply this fix.
--mancha
No way! they still had the GnuTLS in there? What about OpenSSL I haven't yet installed my new slack sys yet haven't had the time so can't check. Niether will I be running a server so it doens't affect me but just curious... Which openssl patch did you guys use. Hopefully .g and not .f
.f got an F as a security patch.
 
Old 04-13-2014, 02:43 AM   #128
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,255

Rep: Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050
Quote:
Originally Posted by Mercury305 View Post
Which openssl patch did you guys use. Hopefully .g and not .f
.f got an F as a security patch.
Just in case you didn't look yet at the Slackware's Security Advisories and ChangeLogs, openssl and openssl-solibs where upgraded to version 1.0.1g on Tue Apr 8, as already stated by Willy.

See also updates in post #122 of this thread from Mancha.

Last edited by Didier Spaier; 04-13-2014 at 04:18 AM. Reason: Typos corrected
 
Old 04-14-2014, 12:25 PM   #129
mancha
Member
 
Registered: Aug 2012
Posts: 292

Original Poster
Rep: Reputation: Disabled
Update 20140414
  1. rsync

    Slackware 14.1's rsync 3.1.0 is vulnerable to a local/remote resource consumption denial of service attack (CVE assignment
    pending). I've not personally checked other Slackware versions but a lightning code review suggests to me vulnerable code
    exists since rsync 3.0.5 (i.e. Slackware 13.0).

    Solution: Re-build rsync with upstream's fix [1] which I've mirrored at the vault.

    PoC:

    /etc/rsyncd.conf
    Code:
    [pub]
     comment = PoC for DoS
     path = /tmp
     read only = yes
     list = yes 
     uid = nobody
     gid = nobody
     auth users = *
     secrets file = /etc/rsyncd.secrets
    /etc/rsyncd.secrets
    Code:
    bob:1337
    As bob: everything's OK
    Code:
    $ RSYNC_PASSWORD=1337 rsync rsync://bob@127.0.0.1/pub
    As non-existent user "dos": 100% CPU usage
    Code:
    $ RSYNC_PASSWORD=1337 rsync rsync://dos@127.0.0.1/pub
--mancha

[1] https://git.samba.org/?p=rsync.git;a...f;h=0dedfbce2c
 
1 members found this post helpful.
Old 04-14-2014, 02:47 PM   #130
mancha
Member
 
Registered: Aug 2012
Posts: 292

Original Poster
Rep: Reputation: Disabled
Update 20140414-1
  1. OpenSSL

    A use-after-free race condition has been discovered in OpenSSL's read buffer (CVE-2010-5298). Under certain
    circumstances, this flaw may permit an attacker to inject data from one connection into another.

    Solution: Re-build OpenSSL 1.0.1g with this fix.
--mancha

Note: This might be a NOP when OpenSSL is not built with OPENSSL_NO_BUF_FREELIST. Nevertheless, my strong
recommendation is that everyone apply the fix.

========

Update #1

The OpenSSL 0.9.8 branch is unaffected by this issue (vulnerable code was introduced in OpenSSL 1.0.0). Systems
running Slackware 13.37 and earlier require no action (unless they run a non-stock OpenSSL 1.0.0+).

Last edited by mancha; 04-14-2014 at 05:54 PM. Reason: Mention 0.9.8 is unaffected
 
2 members found this post helpful.
Old 04-16-2014, 01:04 PM   #131
number22
Member
 
Registered: Sep 2006
Location: Earth
Distribution: Slackware 14.1 Slackware64-current multilib
Posts: 183
Blog Entries: 1

Rep: Reputation: 38
Quote:
Originally Posted by mancha View Post
Update 20140407-1If you don't want to worry about patching or upgrading your kernel, you can remove the attack vector by ensuring the DCCPconntrack helper module never loads:
Code:
# echo "install nf_conntrack_proto_dccp /bin/true" > /lib/modprobe.d/CVE-2014-2523.conf
--mancha
what is difference between this code with just plain blacklist this modules in the file?
Thanks
 
Old 04-16-2014, 01:27 PM   #132
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 336

Rep: Reputation: 99
Basically, if you don't know what DCCP is, you should be save to blacklist it.. If that's what you asked.. (I've understood the question after metaschima's answer below)

Last edited by Smokey_justme; 04-16-2014 at 01:45 PM.
 
Old 04-16-2014, 01:33 PM   #133
metaschima
Senior Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 1,202

Rep: Reputation: Disabled
Technically there usually in no need to blacklist the conntrack dccp module unless you specifically load it yourself, and in this case simply don't load it. It is NOT loaded automatically, and NOT loaded by Alien Bob's firewall script.
 
Old 04-16-2014, 02:02 PM   #134
mancha
Member
 
Registered: Aug 2012
Posts: 292

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by number22 View Post
what is difference between this code with just plain blacklist this modules in the file?
Thanks
"Blacklisting" prevents a kernel module from being auto-loaded. However, I also want to prevent the vulnerable code from loading
via two additional methods: 1) accidental manual loading and 2) indirectly via a non-blacklisted kernel module that depends on it.

The solution I posted handles all three cases.

--mancha
 
2 members found this post helpful.
Old 04-16-2014, 02:23 PM   #135
number22
Member
 
Registered: Sep 2006
Location: Earth
Distribution: Slackware 14.1 Slackware64-current multilib
Posts: 183
Blog Entries: 1

Rep: Reputation: 38
thanks mancha for explaining.
for further references, checking modprobe manual.

Last edited by number22; 04-16-2014 at 02:27 PM.
 
  


Reply

Tags
exploit, security, slackware


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
[Slackware Security]: Some pending vulnerabilities... mancha Slackware 7 08-22-2013 09:08 AM
[Slackware security] GnuTLS multiple vulnerabilities + (un)lucky-13 mancha Slackware 1 06-20-2013 12:40 PM
Security Advisories and the 64-bit Kernel vulnerabilities njb Slackware 1 11-17-2010 08:27 PM
Has Centos 4.3 Security Vulnerabilities? Seregwethrin Linux - Server 3 02-29-2008 09:48 AM
LXer: Top FOSS security vulnerabilities LXer Syndicated Linux News 0 12-13-2007 07:41 PM


All times are GMT -5. The time now is 10:07 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