oss-sec mailing list archives
Re: Re: Fwd: x86 ROP mitigation
From: Fabio Pagani <pagabuc () gmail com>
Date: Wed, 18 Nov 2015 17:33:37 +0100
Hello everybody, I'm jumping into this discussion since I've worked the last couple of months on this topic. The plan outlined in the previous email seems reasonable but, for a more complete overview, you should definitely check G-Free: https://www.iseclab.org/papers/gfree.pdf
It seems to me that if the stack canary check happened directly before the RET instruction, after restoring the registers, it would make it more difficult to abuse the RET instruction. With the code above, you can just jump to the address 1c6e7 and have access to quite a few useful POP instructions.
You are right. Attackers will have access to POP instruction and potentially to any instruction found in an unaligned fashion. Shifting down the check will work but it's very dangerous, because you are accessing a part of the stack that was deallocated with the add. Actually I've implemented G-Free for X86-64 (except the "symbolic addresses" part) in the LLVM backend. The source will be released max in 2 weeks, but anyway i will be very happy to discuss and help for a GCC implementation. // Fab On Wed, Nov 18, 2015 at 4:49 PM, Steve Grubb <sgrubb () redhat com> wrote:
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 accessThere 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/
Current thread:
- Re: Re: Fwd: x86 ROP mitigation, (continued)
- Re: Re: Fwd: x86 ROP mitigation Daniel Micay (Nov 17)
- Re: Re: Fwd: x86 ROP mitigation Josh Bressers (Nov 17)
- Re: Re: Fwd: x86 ROP mitigation Daniel Micay (Nov 17)
- Re: Re: Fwd: x86 ROP mitigation Rich Felker (Nov 17)
- Re: Re: Fwd: x86 ROP mitigation Daniel Micay (Nov 17)
- Re: Fwd: x86 ROP mitigation Solar Designer (Nov 17)
- Re: Fwd: x86 ROP mitigation Florian Weimer (Nov 18)
- Data on Linux attacks (was Re: [oss-security] Re: Fwd: x86 ROP mitigation) Josh Bressers (Nov 18)
- Re: Data on Linux attacks (was Re: [oss-security] Re: Fwd: x86 ROP mitigation) Kurt Seifried (Nov 18)
- Re: Re: Fwd: x86 ROP mitigation Steve Grubb (Nov 18)
- Re: Re: Fwd: x86 ROP mitigation Fabio Pagani (Nov 18)
- Re: Fwd: x86 ROP mitigation Solar Designer (Nov 19)
- Re: Re: Fwd: x86 ROP mitigation Jonathan Salwan (Nov 19)
- Re: Fwd: x86 ROP mitigation Solar Designer (Nov 17)
- Re: Fwd: x86 ROP mitigation Bernd Schmidt (Nov 18)
- Re: Re: Fwd: x86 ROP mitigation Florian Weimer (Nov 18)
- Re: Fwd: x86 ROP mitigation Jeff Law (Nov 18)