From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8442 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.kernel,gmane.comp.lib.glibc.alpha,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 20:39:27 -0700 Message-ID: References: <20150902025440.GG17773@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 1441165205 3040 80.91.229.3 (2 Sep 2015 03:40:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Sep 2015 03:40:05 +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: linux-kernel-owner@vger.kernel.org Wed Sep 02 05:39:59 2015 Return-path: Envelope-to: glk-linux-kernel-3@plane.gmane.org Original-Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZWyty-0006T6-Cn for glk-linux-kernel-3@plane.gmane.org; Wed, 02 Sep 2015 05:39:58 +0200 Original-Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752403AbbIBDjt (ORCPT ); Tue, 1 Sep 2015 23:39:49 -0400 Original-Received: from mail-oi0-f44.google.com ([209.85.218.44]:35891 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751184AbbIBDjr (ORCPT ); Tue, 1 Sep 2015 23:39:47 -0400 Original-Received: by oibi136 with SMTP id i136so11794285oib.3 for ; Tue, 01 Sep 2015 20:39:47 -0700 (PDT) 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=2wubbR2zWUm16agvbSW3Nw5EHxTypv+neZWKCiZiFiM=; b=auPSxS3tqB7FWcEeSIS7htWMZRTNKt0NZ/2f9idJH1fieZznGAeiq/IAxPEHOhOYAj 8l0ID1jQWAmzcR7SpTbTHZIUrNtTbu1gCn8d1C9f+G5dCsYH4lxGiTjGQIi/LzLkBC0s Sxi/Vm2uEsLYh+eAyrn8VRI+XryVd78WZjCDEJfMQtXcZY5npU1HKaH8EW44IAzVL3BI lZlj4fdG/iNardPJGtFKMww4CxSb6j5446c9JFH4RruHSAbDewYHAyc+AlJb8yYd55BW GDRDwRqeNm7pvsY7ZVIBjW5NBXok9ZJ8rOQ9XuFreCgu/tPbpkhqwwfP6sKFS060rPi9 xjZw== X-Gm-Message-State: ALoCoQmRAetLLKCkok0t2WeWGpUnccI4wV56akX8D9cTH/wbEi6LYL6YXW6PYN6qLgRJ/fShFdYw X-Received: by 10.202.219.67 with SMTP id s64mr16449133oig.25.1441165187084; Tue, 01 Sep 2015 20:39:47 -0700 (PDT) Original-Received: by 10.202.57.214 with HTTP; Tue, 1 Sep 2015 20:39:27 -0700 (PDT) In-Reply-To: <20150902025440.GG17773@brightrain.aerifal.cx> Original-Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Xref: news.gmane.org gmane.linux.kernel:2030640 gmane.comp.lib.glibc.alpha:55161 gmane.linux.lib.musl.general:8442 gmane.comp.gcc.devel:141121 gmane.comp.gnu.binutils:70931 Archived-At: 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 I'm also waiting for someone to find an exploit that uses one of the vsyscalls as a ROP gadget. > > 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. --Andy