[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5482DD31.3080409@yahoo.fr>
Date: Sat, 06 Dec 2014 11:40:49 +0100
From: Lionel Debroux <lionel_debroux@...oo.fr>
To: oss-security@...ts.openwall.com
Subject: Re: How GNU/Linux distros deal with offset2lib attack?
Hi,
> As you know Hector Marco disclosed a new attack targeting the
> GNU/Linux mitigation defensive technology earlier this week:
As pointed out by spender, this attack is not quite new, given that
PaX/grsec has defended against it for over a decade :)
> 1, Use Grsecurity/PaX. Afaik, Gentoo and Debian Mempo has long-term
> maintenance for Grsecurity/PaX patch. But the Grsecurity/PaX is not
> part of linux kernel mainline that'd be a problem to the most
> distros. I think linux kernel upstream won't accept PaX patch only
> because of this *kind* of issue.
Indeed, mainline won't accept a ~4 MB, ~130K-line patchset providing
dozens of configuration options and touching a couple thousand files,
even though it repeatedly protects from pretty much every published
privilege escalation exploit involving kernel holes. Often, published
exploits fall afoul both MEMORY_UDEREF and other protections (KERNEXEC,
RANDSTRUCT, etc.).
Such a huge patchset might be accepted only after being split down into
many chunks. And maybe mainline doesn't want all (or even much) of that
patch in the tree, to begin with. Multiple important mainline developers
repeatedly dismiss "security circus".
The problem is... who has time, money, interest to perform the public
service work of contributing PaX/grsec to mainline (assuming mainline
wants so, again), or even having all important mainline submissions be
implemented securely before they can go in (which didn't occur for e.g.
the eBPF interpreter, it's insecure according to spender, who had made
some code to harden the older BPF interpreter) ?
That is, who to go through:
* splitting from PaX e.g. the x86_64 PCID bits made in 2013, PAGEEXEC (&
32-bit-x86-specific SEGMEXEC), KERNEXEC, MPROTECT, MEMORY_UDEREF (which
PaXTeam repeatedly points out as a strict superset of Broadwell's SMAP,
and has worked across multiple ISAs for years), MEMORY_STACKLEAK,
MEMORY_SANITIZE (which has already pinpointed bugs later fixed in
mainline), REFCOUNT (there have also been multiple refcount-based holes
on mainline), CONSTIFY_PLUGIN, USERCOPY, SIZE_OVERFLOW, why not
LATENT_ENTROPY;
* splitting from grsec e.g. RAND_THREADSTACK, KSTACKOVERFLOW,
JIT_HARDEN, RANDSTRUCT*, CHROOT* (a whole range of improvements for
making Linux's weaker chroots closer to *BSD jails), HARDEN_IPC, DENYUSB
(which predates BadUSB being published, AFAICS);
* testing the individual pieces before submission;
* submitting to mainline;
* adjusting depending on feedback;
* submitting again;
* etc. ?
That's a time-consuming process, hard for volunteer contributors to go
through. It's easy to understand why PaXTeam, spender, ephox and others
either don't go through it and focus on improving PaX/grsec, or only
submit few, small bits (e.g. minipli submitting the constification of
three structs in the IPC system for 3.17; there are several dozens of
similar chunks in PaX, totaling hundreds of lines).
Some sizable chunks were split and contributed to mainline in the past,
e.g. constification of a number of structs containing function pointers
and which have no business being rewritable. ephox spent some time on
the splitting + submission, but many arch / driver maintainers didn't
pick up the pieces in the end...
Since then, PaX replaced manual constification (~700 KB in the patch)
with a GCC plugin + manual marking of pieces that can't be const.
And the above was only for the kernel side. Without significant work on
userspace, mainly improving / fixing (which is hard for e.g. JIT
engines...) application code + integrating PaX xattr marking into the
(all too many, redundant) packaging systems, PaX/grsecurity can't be as
usable - and therefore as used - in the real world for improving actual
end user security.
The performance cost of security can be offset by using newer generation
hardware, but inconvenience due to insufficient integration turns people
away from security-enhanced software. Last time I tried, several months
ago, booting a grsec kernel on a LMDE box, in enforcing mode, failed to
bring up a X server + desktop environment, even with FLOSS drivers, due
to various bits of MPROTECT-triggering code...
Using a grsec-hardened kernel in whitelist mode (pax.softmode=1 +
protection disabling on the executables which can't cope with e.g.
MPROTECT) is clearly much more secure than running a mainline kernel,
but not as secure as running a grsec-hardened kernel in blacklist mode.
People from Gentoo, Arch and openSUSE (that I know of) have already done
part of the work integrating PaX protections into the whole distro.
Outside of packaging system integration, solutions such as paxd do the job.
But their full potential can be reaped only when a majority of users use
them, which is not about to happen, especially if PaX/grsec remains
outside of mainline...
> 2, ASLRv3? Hector Marco( the dude who disclosured offset2lib attack)
> sent a patch to the upstream:
> https://lkml.org/lkml/2014/12/4/839
>
> Even the upstream don't accept the patch, is this possible to backport
> it & maintain it for distro community?
>
> 3, RenewSSP? IMHO, this is a solution for the way of exploit like:
> http://phrack.org/archives/issues/67/13.txt
>
> It'd be workaround for another mitigation to prevent offset2lib
> attack though. But the authors of RenewSSP don't even send a patch
> to GCC community yet. At least I can't search anything about RenewSSP
> in GCC ml.
>
> It seems ASLRv3 is the best option we have? Or anything else?
For defense in depth, all of those.
In the short term, 2) whatever expands the mainline ASLR entropy well
beyond the current state. i.e. ASLRv3/PAX_ASLR (the best of the two) +
RANDKSTACK, RANDMMAP, RAND_THREADSTACK and possibly others I forgot.
In the mid-long term, simultaneously
3) various ways of improving hardening through built-in GCC and Clang
features (more sanitizers, stronger stack protections, etc.), expanded
by kernel-specific GCC and Clang plugins. PaX and grsec have been using
GCC plugins for years
1) having a number security experts paid to work on the integration of a
meaningful subset of PaX/grsec to both mainline Linux and the userspace
of most important distros.
4) intensify efforts pinpointing, fixing, replacing userspace programs
containing memory errors and other bits of insecure coding.
Who to pay extra toolchain maintainers, extra security experts ? Perhaps
the usual suspects: RedHat, SUSE, the Linux Foundation, Google, others.
Who to train application developers and end users ?
Bye,
Lionel.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
