Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 24 Nov 2015 21:54:27 +0100
From: Florian Weimer <>
Subject: Re: System call interface changes

On 11/24/2015 09:10 PM, Kees Cook wrote:

> Ah, are you looking at this as an anti-ROP idea? What's the bug class
> or exploitation method you're looking at addressing?

The idea, as it has been presented to me, is to remove the ability to
invoke execve (and a few other system calls) completely, to push
attackers *towards* ROP as the only means for injecting code into a
process (not all processes, obviously, but a large class of processes as

As far as I know, this is intended as a post-exploitation mitigation
(before policy-based mechanisms or containers kick in).  I don't know
enough about real-world attack scenarios to tell if these changes would
make a difference.

>> This would have to be an opt-in feature, obviously, and applications
>> would have to opt in explicitly via some ELF flag (similar to what we
>> did for non-executable stacks).
> There have been a growing number of things that seem like they'd be
> nice to control with ELF flags. Andy Lutomirski recently wanted to
> make the x86-64 vsyscall presence be selectable on a per-process
> basis. (I think it's easier to just turn it off entirely.)

Yes, we have a backlog in this area.  For usability reasons, we also
need ways to mark separated debuginfo files, and PIE binaries (which
currently look like DSOs).

> I always come back to "how can we measure this?" If you've got an
> exploit method you're trying to kill, etc, then it should be easy to
> evaluate its utility.

The final paragraph in


has some more context.  I think you are definitely asking the right
questions, and I desire a more empirical approach to security
improvements.  But this is the position I'm in.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.