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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ