From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8444 Path: news.gmane.org!not-for-mail From: Andy Lutomirski 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: Tue, 1 Sep 2015 21:32:22 -0700 Message-ID: References: <20150902025440.GG17773@brightrain.aerifal.cx> <20150902041815.GH17773@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1441168371 14291 80.91.229.3 (2 Sep 2015 04:32:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 04:32:51 +0000 (UTC) Cc: Kees Cook , "linux-kernel@vger.kernel.org" , libc-alpha , "musl@lists.openwall.com" , gcc@gcc.gnu.org, Binutils To: Rich Felker Original-X-From: libc-alpha-return-62883-glibc-alpha=m.gmane.org@sourceware.org Wed Sep 02 06:32:50 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 1ZWzj7-00045r-PS for glibc-alpha@plane.gmane.org; Wed, 02 Sep 2015 06:32:50 +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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=gAYz OhZ2Ato5XupsHq2qOcJV3+IJ/AxxDeK84trp5+umCTsPkf7vQYRNJtx6+3nPe2M9 HFOSHFeQw589BmK4Wrs/5QadqzxZZK29WlWRCojMmAhdQN0wzA9nFMULIVaUE15y 0fxPnYREtGyNOMl7FA0yj+1ksAQRU/s9z2lNFrI= 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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; s=default; bh=HbvkCWesWZ 8i9aJXpu70fFgQ87Y=; b=LOqK3FbPlUHgMarg61hUAb4mzDK7uVTurWlE9gLCDn XZo3wEK5LSc8FRcoJtgsHYmzCfoONUk9XZghgG3oqkiZNl78Ib0d0n9dZn7/9iWW yHB2ojAGGsyk4T/SEZHo87JZ2kV7vZ327vYyRJWDdBZ9ZVG+Poiw/w6oTEyUkz+o c= Original-Received: (qmail 130882 invoked by alias); 2 Sep 2015 04:32:45 -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 130858 invoked by uid 89); 2 Sep 2015 04:32:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.4 required=5.0 tests=AWL,BAYES_50,KAM_LIVE,RCVD_IN_DNSWL_LOW,SPF_PASS,URIBL_BLACK,URI_BLOGSPOT autolearn=no version=3.3.2 X-HELO: mail-ob0-f169.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IhYCDby0QHqVBIAieqmj4VmugiWvCajVXPf+pXN/ve4=; b=N6nBx8EU+NKBGEEWkcCGmZAXTeiX9vt2oqpbYwpgEV32L1r6dKO/RQuLTeBRtGYBrw hG/UvoExAm7+yDyaUFm/axykDBD7HzNFi9GrEHrF0mKij87NZnWpw+PJMkCT2GxoXH6W jA+YaKwjvNPBPpgBxEMGM0KRbgEtuRCBgViDagTB20+vO6EdV6NUvWOG+D4DpuAbQ3bL rGT7FuBOVQgJqhcmPoFyqokFnf8JJXOquBgccl6QXG5xhRsBnXoGA/eWaROWwNt8X2zg JsToNTzoW9BzNzmOxc/41Lcq5cf8gqdawIrWHHsTMoXW3fG/HLZKk16fi8PIKnOak4gW Kl5w== X-Gm-Message-State: ALoCoQn9Kf9ixccyUCPA4X7oNYQ0ba967Wp7LDn9Fj5mYRB9hshg06ffRguACUvMo6yi58f13X2w X-Received: by 10.60.96.194 with SMTP id du2mr20834980oeb.2.1441168361765; Tue, 01 Sep 2015 21:32:41 -0700 (PDT) In-Reply-To: <20150902041815.GH17773@brightrain.aerifal.cx> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:55163 gmane.linux.kernel:2030649 gmane.linux.lib.musl.general:8444 gmane.comp.gcc.devel:141123 gmane.comp.gnu.binutils:70933 Archived-At: On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote: > 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. > Oddly, that causes a compatibility problem. There's a program called pin that does dynamic instrumentation and actually expects to be able to read the targets of calls. The way that Linux handles this now is to put a literal mov $NR, %rax; syscall; ret sequence at the syscall address but to mark the whole page NX so that any attempt to call it traps. The trap gets fixed up if the call looks valid (properly aligned, etc) and the process gets SIGSEGV if not. This caught me by surprise when I implemented vsyscall emulation the first time. >> 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. No, it's actually just three separate functions, one for each of gettimeofday, time, and getcpu. --Andy