Update 20140407-1
|
Update 20140407-2
======== 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. |
Hi mancha, I am trying to rebuild the new openssl version and it doesn't work
Code:
created directory `/tmp/package-openssl/etc' EDIT: I commented all the parts related to documentation on the slackbuild file but that is a bit annoying imo |
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.
|
Thanks metageek, it worked :)
|
Official updates from slackware also arrived today
|
Quote:
.f got an F as a security patch. |
Quote:
See also updates in post #122 of this thread from Mancha. |
Update 20140414
[1] https://git.samba.org/?p=rsync.git;a...f;h=0dedfbce2c |
Update 20140414-1
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+). |
Quote:
Thanks |
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)
|
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.
|
Quote:
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 |
thanks mancha for explaining.
for further references, checking modprobe manual. |
All times are GMT -5. The time now is 12:11 AM. |