Heartbleed
 

I'm freaking out with this heartbleed bug (see here).

Eagerly waiting for a patch to come out for Slackware.

Thanks in advance to all the developers!

A patch came out about 8 hours ago.

http://www.linuxquestions.org/questi...ml#post5148304

My apologies. The OpenSSL patch came out 8 hours ago, not the Slackware patch.

Yes I know, I'm building a temporary package with the 1.0.1g source and the source package. Unfortunately the build fails at some point, though it is only for the documentation part (which I am disabling).

But not knowing all the implications (ie which other packages to rebuild), I will be much more confident when all PV's official patches are released.

I've successfully built openssl-1.0.1g-x86_64-1_slack14.1.txz and openssl-solibs-1.0.1g-x86_64-1_slack14.1.txz using the source package for openssl-1.0.1f. All it took was to remove the previous tarball (openssl-1.0.1f.tar.gz) and drop in the new one openssl-1.0.1g .tar.gz

I'd put it on a server for others to download, but right now I do not want to ssh into any server not yet patched... at least my client is already clean.

Now get all new passwords, ssl keys... what a nightmare!

AFAIK pretty much everything in Slackware linking the openssl libraries does it with the dynamic ones, so you should be safe upgrading the openssl and openssl-solibs packages.

FYI, waiting for the official packages, I tried here building from slackware64-current's and slackware64-14.1's sources just substituting the tarball file (well, I got also the signature) and everything seems to have went fine (no problems with docs building like metageek reported).

Thanks for the info, this sounds good. I did manage to build now that I used the source package in the 14.1 patch folder (rather than the one on the original 14.1 source).

Another example that the newest version isn't always the best version. Slackware 13.37 and below are not affected, because they use OpenSSL 0.9.8y.

well, to avoid misunderstanding I have to specify (for the ones that haven't read mancha's post or the dedicated site) that when I said "you should be safe" I meant on the software side: like the reporters say, every certificate (server-side and client-side) is potentially compromised and must be regenerated and so, still potentially, are passwords trasmitted on services using openssl...

Yes, all passwords, and ssl keys need to be reset, and this is only on the clients. Servers have further problems with certificates. And all the goodies they keep might already have been taken (password DBs, SSNs, credit card numbers, bitcoins, the whole lot).

Before updating passwords and ssl keys I am not loggin in to any site of importance (ie banks, etc). I'm physically copying the updated packages using USB memory stick, not daring using ssh (since machines receiving them through ssh would not have been patched yet).

After the upgrade, here is a check for processes that are still using the old version of SSL.

lsof -n | grep ssl | grep DEL

regarding that, consider that /usr/lib$LIBDIRSUFFIX/libssl3.so, provided by the mozilla-nss package, is not openssl...

I tried upgrading it, the build failed :/

You can also rebuilt the current version but add this parameter so that heartbeats module will not be built: -DOPENSSL_NO_HEARTBEATS

Worked for me. Try this sequence:

At the end you should find two packages in your /tmp directory: openssl-1.0.1g and openssl-solibs-1.0.1g.

metageek told me exactly the same thing, I was picking the slackbuild folder from source and not patches. It doesn't work.

EDIT: And by the way I learnt new things with your command thanks :)
http://explainshell.com/explain?cmd=...e%2Fopenssl%2F

Ok, cool. Glad you got there, even if I was a little slow! ;)

Well at least I was of some use! ;) As you can see I could have cut another directory but I wasn't sure (and didn't check) if the SlackBuild also creates a folder in /tmp called "openssl" during the build and packaging process. Just in case I decided not to cut the parent ("source") directory.

EDIT: I also didn't really need to explicitly set the recursion level to 2, since that is all there was in this case but it is a force of habit, having occasionally grabbed way too much in the past. :p

Well, lets say that the current usage of wget for me doesn't get past "wget -c" :P but I am learning

From http://slackware.osuosl.org/slackwar.../ChangeLog.txt
From http://slackware.osuosl.org/slackwar.../ChangeLog.txt
And from http://slackware.osuosl.org/slackwar.../ChangeLog.txt
Earlier versions of Slackware are not affected.

Eric

Did you do anything different other than using the same source directory and picking up the new tarball? Just to know if I can keep my package or if I should grab the official one.

I did not create them. I only mention their availability.
And: use the official packages where possible is my advice.

Eric

I am gonna use the official ones then.

We now have official packages, which I also prefer myself. So I am going to reinstall them.

I'm marking this as resolved.

As far as I can tell sshd does not use openssl.

Here is the blurb from the OpenBSD patch:

Good thing I'm still at 13.37 :D

Interesting discussion here http://www.reddit.com/r/linux/commen...e_openssl_how/

Ok, this sounds a lot better :) but I've still changed passwords, which is not a bad thing to do anyway.

US-CERT Alert (TA14-098A) OpenSSL 'Heartbleed' vulnerability (CVE-2014-0160)
 

The US-CERT notice arrived in my mail this morning (see https://www.us-cert.gov/ncas/alerts/TA14-098A). It includes a couple of points that weren't (at least to me) quite so obvious in other alerts from yesterday:

• 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.

Reading the Perfect Forward Security article (darned interesting) led to a reference link, https://community.qualys.com/blogs/s...orward-secrecy, that I found truly interesting.

I also found that I'm not that up on just how to regenerate all keys necessary and that implementing Perfect Forward Security might be a little beyond my skill levels.

So, I'm wondering, if someone with more knowledge than I might wish to add information here (or elsewhere) discussing the steps to take to accomplish both of the recommended steps? Reading the manual is one thing, actually doing it might just be another.

[EDIT]
The documentation (on my systems in /usr/doc/openssl-1.0.1g/doc/HOWTO) has clear instructions on generating keys and on generating certificates.

I'm thinking that's probably good enough.
[/EDIT]

It looks as though OpenSSL didn't actually leak private keys.

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

http://heartbleed.com/
http://blog.existentialize.com/diagn...bleed-bug.html

Now things are getting furry. Folk I pretty much trust, say, Bruce Schneier for example, say:
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

"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

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...)

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 :hattip:

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."

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.

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.

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.

try
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)

@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:
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?

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

yes, thanks. find out., that site, where i check, looks like keep my first check in cache. another site after shows actual - 1.0.1g - version.

---------- Post added 04-11-14 at 07:32 PM ----------

i do that. especially, my server uptime was only about 14 days, as so i do not lost any mega-uptime :)

I would do a full reboot of the system to make absolutely sure, that the vulnerable code is gone.

Robert Graham later recanted and upgraded his severity assessment slightly from <never> to <very unlikely> in terms of the risk of
having private keys stolen. In fact, his blog as late as 5AM UTC (20140412) still has the note "Thus, while your SSL certificates are
likely safe, your passwords aren't."

It's unfortunate there are people who claim to understand security whose knee-jerk reaction is to irresponsibly downplay vulnerabilities.

As it turns out, Graham was not just slightly wrong, he was entirely off-the-mark. So far two people have solved CloudFlare's
challenge and successfully stole their private key. One can only imagine what groups with significant resources might have been
able to do in the span of the two years and change the vulnerability has existed.

As I mentioned in my post the very day the vulnerability went public, the intelligent thing to do is assume all credentials (including
primary key material) that have been used in the context of [D]TLS transmissions involving affected client/servers are potentially
compromised.

--mancha

Those who do understand security missed this bug for 2 years. It merits attention and critical thought. I agree with you that the intelligent thing to do is to re-key and change passwords. It is interesting to consider applications like Chrome that apparently don't check for revoked certificates (no CRL nor OSCP).

http://arstechnica.com/business/2012...tion-checking/

You're confusing two issues: 1) the environment/processes that allowed for the flaw to get introduced and go unnoticed for 2+ years,
and 2) how we manage the vulnerability once it's known.

Regarding #2, the day heartbleed was made public a semi-detailed report, that explicitly says private keys are vulnerable, was
published.

In light of this, reporting that private keys can't be stolen (or that their theft is infinitely difficult) is as irresponsible as standing in the
hallway of a building, with fire alarms going off everywhere, and telling people to not worry about evacuating.

--mancha