[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Nov 2015 10:49:58 -0500
From: Steve Grubb <sgrubb@...hat.com>
To: oss-security@...ts.openwall.com
Cc: Florian Weimer <fweimer@...hat.com>, Solar Designer <solar@...nwall.com>,
Jeff Law <law@...hat.com>, Bernd Schmidt <bschmidt@...hat.com>
Subject: Re: Re: Fwd: x86 ROP mitigation
On Wednesday, November 18, 2015 11:51:23 AM Florian Weimer wrote:
> 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).
This was something that I was involved in. What I did was get the latest
source code of ROPgadget. [1] I have no idea how good it is compared to other
tools. But it does have a command line switch that builds a full ROP chain so
that you have a working exploit.
Next, I wrote a small script to iterate over the directories on my Fedora 22
system that should hold programs or libraries the attacker might exploit and
check each and every one of them using ROPgadget. I was curious what the size
of the elephant is that we have.
What I found was that the list of libraries or programs that ROPgadget could
build a chain for is fairly small. I thought about reasons why that might be
the case and then considered that maybe if the gadgets from several libraries
were combined, maybe it would find more. But I think ASLR would make too many
moving parts for that to be practical. If you use a whole library or
application, then everything moves together up or down as a unit to the new
offset.
Another thought in explaining why the list was so small is that the quality of
the chaining that ROPgadget has needs a lot of improvement. Could someone more
clever piece together gadgets that make a chain that ROPgadget didn't see? I
don't have the expertise to do this by hand. So, I'll do what others would do
and look for another tool. There is only one other tools that I could find,
ropper [2]. It dies due to a programming bug. So, I doubt its being used.
The following files are the ones that ROPgadget was able to build a chain for:
/usr/lib64/ld-2.21.so
/usr/lib64/libasound.so.2.0.0
/usr/lib64/libavfilter.so.5.11.102
/usr/lib64/libc-2.21.so
/usr/lib64/libcln.so.6.0.4
/usr/lib64/libdb-5.3.so
/usr/lib64/libfreetype.so.6.11.4
/usr/lib64/libgs.so.9.16
/usr/lib64/libgtk-3.so.0.1600.7
/usr/lib64/libgtk-x11-2.0.so.0.2400.28
/usr/lib64/libliveMedia.so.36.0.6
/usr/lib64/libmozjs-17.0.so
/usr/lib64/libmozjs185.so.1.0.0
/usr/lib64/libmozjs-24.so
/usr/lib64/libpython3.4m.so.1.0
/usr/lib64/libQtWebKit.so.4.10.4
/usr/lib64/libruby.so.2.2.0
/usr/lib64/libsamba-util.so.0.0.1
/usr/lib64/libsmbconf.so.0
/usr/lib64/libsqlite3.so.0.8.6
/usr/lib64/libtcl8.6.so
/usr/lib64/libwebkit2gtk-4.0.so.37.6.8
/usr/lib64/libwebkitgtk-1.0.so.0.22.15
/usr/lib64/libwebkitgtk-3.0.so.0.22.15
/usr/lib64/libxml2.so.2.9.2
/usr/libexec/mysqld
/usr/sbin/ldconfig
/usr/sbin/sln
/usr/bin/clang
/usr/bin/clang-check
/usr/bin/dvipdfmx
/usr/bin/gimp-2.8
/usr/bin/inkscape
/usr/bin/js
/usr/bin/shotwell
/usr/bin/virtuoso-t
This is on a desktop with a lot of server and software development packages
that total up to approx 3800 rpms. If we are going to try to spoil ROP
gadgets, I would suggest that we as a community pick one tool and give it some
love so that it finds all kinds of gadgets. This way we know how effective any
mitigations are.
During this study, Florian had suggested checking -fstack-protector-all. This
defeated ROPgadget. It was not able to find any ROP gadgets in anything
compiled that way. If it were better at finding gadgets I would like to retry
the study to see if that still holds true.
> 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
There is information about this scattered around. It largely depends on what
the role of the system is, what exploit is recently circulating, and external
vs internal threat actors. Fishing around for the top uses of Linux servers
[3] reveals probably what we all knew its used for: virtualization, database
servers, web servers, application servers, etc.
For web servers, there are studies [4] that show what people do. TL;DR: they
find a hole in the web software to issue a wget command to pull down software,
this lands in /tmp, they then execute the software downloaded.
There's 3 different points where this could have been defeated. 1) mod_security
probably would have blocked whatever weird URL or hole they found. 2) /tmp
should be mounted noexec. But noexec is easy to defeat by invoking the
interpreter or ld.so directly. 3) This is the hard one and yet so simple to
fix....make all interpreters check the execute bit before executing. They need
to be a policy enforcement point for the noexec mount option. Otherwise we may
as well ask the kernel guys to remove the noexec mount option because its
useless.
For other servers, its a similar pattern.
> and to maintain a presence afterwards.
This is something I am also interested in. There are groups of people studying
this. One such project is ATT&CK [5] run by MITRE. I have been collecting
information for Linux systems to add to their project. The idea of that
project is to enumerate the various ways that an attacker can perform actions
post exploit. With a catalogue, you can then go build tools that check the
hiding places. If they get a rootkit installed, you might not be able to
detect it on the host, but rather by its actions on the network.
>From this catalogue, you can the create indicators of compromise to look for.
Mandiant has one method [6], but I would rather see something based around
SCAP tooling so that its standardized.
> 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.
I hope I filled in some of the blanks. I am sure that others can point to more
information to help fill in more gaps.
-Steve
1 - http://shell-storm.org/project/ROPgadget/
2 - https://github.com/sashs/Ropper
3 - https://www.daniweb.com/hardware-and-software/linux-and-unix/news/258647/10-ways-that-enterprises-use-linux
4 - https://www.sans.org/reading-room/whitepapers/malicious/introduction-linux-based-malware-36097
5 - https://attack.mitre.org/wiki/Main_Page
6 - http://www.openioc.org/
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.
