linux-kernel - Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 Sep 2015 08:48:21 -0400
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	Andy Lutomirski <luto@...capital.net>,
	Rich Felker <dalias@...c.org>
Cc:	Kees Cook <keescook@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	libc-alpha <libc-alpha@...rceware.org>,
	"musl@...ts.openwall.com" <musl@...ts.openwall.com>,
	gcc@....gnu.org, Binutils <binutils@...rceware.org>
Subject: Re: [musl] RFC: adding Linux vsyscall-disable and similar
 backwards-incompatibility flags to ELF headers?

On 2015-09-02 00:32, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker <dalias@...c.org> 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 <dalias@...c.org> wrote:
>>>> 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.
Did the old versions of glibc always use vsyscall calling for these 
syscalls?  If they did, then we could (probably) safely disable the 
vsyscall stuff the first time we see any of these called through the 
normal syscall paths.



Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)