Message-ID: <49340.1379013826@turing-police.cc.vt.edu>
Date: Thu, 12 Sep 2013 15:23:46 -0400
From: Valdis.Kletnieks@...edu
To: Steve Wray <stevedwray@...il.com>
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: Internet has vuln.

On Thu, 12 Sep 2013 08:57:55 +0800, Steve Wray said:

> In some cases it could be quite difficult to disengage from NSA-influenced
> projects, eg selinux. So far as I can tell this is pretty much everywhere
> now. Redhat embraced it ages ago, its been integrated in the kernel since
> 2.6, so how do we opt out of selinux?

Well, given that SELinux *did* come out of the NSA, but has had tons of code
review of the base code (which isn't really all that much) and the actual
policy files (which is where I'd hide a backdoor, they're a lot more obscure
than the actual kernel code), by lots of people who would have *loved* to be
the one who caught the NSA doing something underhanded, I think you're barking
up an entirely incorrect tree.

Sure, there *may* be a backdoor in there even after over a decade of
outside review and several code overhauls by non-NSA people.  But as
Bruce Schneier continually tries to remind us, security is tradeoffs.

What are the chances that the NSA will be targeting *your* box with
a code exploit?

What are the chances that *any hacker other than the NSA* (Chinese, Russian,
bored script kiddies in Boise Idaho, whatever) will target your box
with a code exploit?

Which one do you want to be defending against?  Yeah.  It's far more
likely that even with a hypothetical backdoor, SELinux will more likely
stop some other attacker than it will let the NSA in.

(For bonus points, the fact that SELinux is applied as a restrictive MAC
after the standard unix permissive DAC means that it can't give any access
you wouldn't have had *anyhow* if SELinux was entirely removed - about the
only way to leverage it into a compromise is to find a buggy userspace
program that misbehaves when you *remove* access, similar to the Sendmail
setUID bug from some years back).

Now, if you want to actually do something *USEFUL* to secure your RedHat
box, there's something you can do to minimize your attack surface against
an attack we *KNOW* the NSA is doing.

In other words, rebuild your damned OpenSSL so that the RedHat-supplied
.spec file doesn't intentionally go out of its way to disable elliptic
curve DH.  Google can deploy perfect forward security all it wants, it won't
do you squat unless your end plays along.

Patch attached.  It's about 43 times larger than it really needs to be,
except that turning on ECDHE also means you have to disable FIPS mode,
because the FIPS self-test is insanely brain-dead and checks that your
crypto library has *ONLY* FIPS-approved algos in it - and EC isn't on
the list.  Somebody figures out how to get EC and FIPS to co-exist, feel
free to post an improved patch.

Patch is against current Rawhide, but if you're clever enough to think about
turning off SELinux, you should be able to fit it onto any release of
OpenSSL recent enough to be safe to use....

And if you have a webserver, apply the matching patches for the server end.
There's patches out there for both Apache and nginx.

Oh, and if you use Firefox, you may want to go into about:config, enter 'rc4'
on the filter line, and turn all of them off, and only re-enable one if
you hit a website that is mandatory for you to use, and it insists on rc4 rather
than AES or something else less totally borken than rc4.


View attachment "openssl.spec.patch" of type "text/plain " (4651 bytes)

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists