From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8443 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.comp.lib.glibc.alpha,gmane.linux.kernel,gmane.linux.lib.musl.general,gmane.comp.gcc.devel,gmane.comp.gnu.binutils Subject: Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers? Date: Wed, 2 Sep 2015 00:18:15 -0400 Message-ID: <20150902041815.GH17773@brightrain.aerifal.cx> References: <20150902025440.GG17773@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1441167512 2039 80.91.229.3 (2 Sep 2015 04:18:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 04:18:32 +0000 (UTC) Cc: Kees Cook , "linux-kernel@vger.kernel.org" , libc-alpha , "musl@lists.openwall.com" , gcc@gcc.gnu.org, Binutils To: Andy Lutomirski Original-X-From: libc-alpha-return-62882-glibc-alpha=m.gmane.org@sourceware.org Wed Sep 02 06:18:31 2015 Return-path: Envelope-to: glibc-alpha@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZWzVE-0003kA-Uz for glibc-alpha@plane.gmane.org; Wed, 02 Sep 2015 06:18:29 +0200 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=Jbp4 IMZNMDRjCuCLOJwAHfp2f2F4+bK5Mh0RVWeuLQazmOQ1hQdlGii1IpRBCcroiaOO 69A6dwNB3avp8RH5a8WLEsHe0vOkSdCdQySmCSiNkb37BD8A8+SClx9ZwyM2rH3v Sd18P8l5ycHWtNcckApt76abbiff7NX+PXXFxNE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=E8W5SWI3U+ hSuxmZsF4ro7b4zbU=; b=UT9If0+sAhOsvBHT5/0LhoDkgLbFv56JQHBJwCjEog 9/ZFnZCZntiGuCUqXNvBOTJz+QoNrCIQfzQ4R00jw8BXHfgpockRLWqFZC0ld1KW qC8AbAeTecNTXVNSkFWC2nTaY2BF0GbzuPX4E0Ynaf7k81lowCvl08IdBWhFkK+I 8= Original-Received: (qmail 27300 invoked by alias); 2 Sep 2015 04:18:24 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Original-Received: (qmail 27281 invoked by uid 89); 2 Sep 2015 04:18:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: Yes, score=5.6 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,KAM_LIVE,RDNS_DYNAMIC,TVD_RCVD_IP,URIBL_BLACK,URI_BLOGSPOT autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: brightrain.aerifal.cx Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.comp.lib.glibc.alpha:55162 gmane.linux.kernel:2030647 gmane.linux.lib.musl.general:8443 gmane.comp.gcc.devel:141122 gmane.comp.gnu.binutils:70932 Archived-At: On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote: > On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote: > > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote: > >> Hi all- > >> > >> Linux has a handful of weird features that are only supported for > >> backwards compatibility. The big one is the x86_64 vsyscall page, but > >> uselib probably belongs on the list, too, and we might end up with > >> more at some point. > >> > >> I'd like to add a way that new programs can turn these features off. > >> In particular, I want the vsyscall page to be completely gone from the > >> perspective of any new enough program. This is straightforward if we > >> add a system call to ask for the vsyscall page to be disabled, but I'm > >> wondering if we can come up with a non-syscall way to do it. > >> > >> I think that the ideal behavior would be that anything linked against > >> a sufficiently new libc would be detected, but I don't see a good way > >> to do that using existing toolchain features. > >> > >> Ideas? We could add a new phdr for this, but then we'd need to play > >> linker script games, and I'm not sure that could be done in a clean, > >> extensible way. > > > > Is there a practical problem you're trying to solve? My understanding > > is that the vsyscall nonsense is fully emulated now and that the ways > > it could be used as an attack vector have been mitigated. > > They've been mostly mitigated, but not fully. See: > > http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html That looks like it would be mitigated by not having any mapping there at all and having the kernel just catch the page fault and emulate rather than filling it with trapping opcodes for the kernel to catch. > I'm also waiting for someone to find an exploit that uses one of the > vsyscalls as a ROP gadget. This sounds more plausible. gettimeofday actually writes to memory pointed to by its arguments. The others look benign. > > If this is not the case, I have what sounds like an elegant solution, > > if it works: presumably affected versions of glibc that used this used > > it for all syscalls, so if the process has made any normal syscalls > > before using the vsyscall addresses, you can assume it's a bug/attack > > and and just raise SIGSEGV. If there are corner cases this doesn't > > cover, maybe the approach can still be adapted to work; it's cleaner > > than introducing header cruft, IMO. > > Unfortunately, I don't think this will work. It's never been possible > to use the vsyscalls for anything other than gettimeofday, time, or > getcpu, so I doubt we can detect affected glibc versions that way. I thought the idea of the old vsyscall was that you always call it rather than using a syscall instruction and it decides whether it can do it in userspace or needs to make a real syscall. But if it was only called from certain places, then yes, I think you're right that my approach doesn't work. Rich