Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Nov 2015 11:51:23 +0100
From: Florian Weimer <>
To: Solar Designer <>, Jeff Law <>
Cc: Bernd Schmidt <>,
Subject: Re: Fwd: x86 ROP mitigation

On 11/18/2015 03:10 AM, Solar Designer wrote:

> This approach makes sense to me, but I think we should have a better
> idea of whether and how "a point where ROP gadgets are reasonably hard
> to find & exploit" is potentially reachable.  If it is not even
> potentially reachable, then this undermines the effort, unfortunately.

This came up in other discussions as well.  We even got to the point
where someone ran a ROP gadget finding tool on a core library, which did
not find any gadgets at all, and someone else found a useful one in a
few minutes with objdump and no other tool support (and this did not
even include jumping into the middle of instructions).

In the end, this boils down to lack of concrete goals.  “Blinding ROP
gadget finder X“ is easy (just change the ELF format in such a way that
it's no longer recognized by the tool), but probably not very useful if
you want to improve security, for any useful definition of “security”.

We face the problem that I and my immediate colleagues (on the Red Hat
tools team) do not have access to information about successful
compromises, and what attackers actually do today, on GNU/Linux systems,
both to achieve initial access and to maintain a presence afterwards.
Under these conditions, anything we implement is, to some degree,
arbitrary and a shot in the dark.  We can still use our best judgment to
set priorities, but we are very far from being guided by empirical evidence.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

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