Other people have taken notice of the recent “auto-run” attack research against Linux. I was extremely excited to see Jon Larimer publishing this stuff, since it ultimately did not start with the words, “first we disabled NX, ASLR, and (SELinux|AppArmor) …”
I was pretty disappointed with last year’s Blackhat conference because so many of the presentations just rehashed ancient exploitation techniques, and very few actually showed new ideas. I got tired of seeing mitigation technologies disabled to accomplish an attack. That’s kind of not the point.
Anyway, Jon’s research is a step in the right direction. He defeats ASLR via brute-force, side-steps NX with ret-to-libc, and finds policy holes in AppArmor to accomplish the goal. I was pleased to see “protected by PIE and AppArmor” in his slides — Ubuntu’s hardening of evince was very intentional. It has proven to be a dangerous piece of software, which Jon’s research just further reinforces. He chose to attack the difficult target instead of going after what might have been the easier thumbnailers.
So, because of this research, we can take a step back and think about what could be done to improve the situation from a proactive security perspective. A few things stand out:
- GNOME really shouldn’t be auto-mounting anything while the screen is locked (LP: #714958).
- AppArmor profiles for the other thumbnailers should be written (LP: #715874).
- The predictable ASLR found in the NX-emulation patch is long over-due to be fixed. This has been observed repeatedly before, but I hadn’t actually opened a bug for it yet. Now I have. (LP: #717412)
- Media players should be built PIE. This has been on the Roadmap for a while now, but is not as easy as it sounds because several of them use inline assembly for speed, and that can be incompatible with PIE.
- Consider something like grsecurity’s GRKERNSEC_BRUTE to slow down execution of potentially vulnerable processes. It’s like the 3 second delay between bad password attempts.
Trying to brute-force operational ASLR on a 64bit system, though, would probably not have worked. So, again, I stand by my main recommendation for security: use 64bit. :)
Good stuff; thanks Jon!
© 2011, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
I’m sorry if this might be a stupid question — but what does the abbreviation PIE stand for here? I think I could find the meaning of most other abbreviations you used and I didn’t understand via Google, but well, ‘pie’ is just too general. :-D
Comment by Rico — February 12, 2011 @ 5:16 am
Sorry about that; I’ve updated the post to include some reference links back to Wikipedia.
While ASLR is available for every area of a process (stack, libs, mmap, brk, text), it can only be forced on for stack, mmap, and brk, (mostly data regions) since those are almost always programmatically allocated and applications already could not have depended on their being in a fixed position. ASLR is also usable for libraries because of the long-standing requirement that shared libraries already be compiled as “PIC”. Being able to use it for the “text” area (the main executable region of a process — not its libraries) depends on the program being compiled as “PIE” to account for its unknown position in memory.
Comment by kees — February 12, 2011 @ 8:52 am
Thank you, kees, that clears up a lot. ;-)
Comment by Rico — February 13, 2011 @ 4:18 am