[Donncha O’Cearbhaill] has successfully exploited two flaws in Apport, the crash report mechanism in Ubuntu. Apport is installed by default in all Ubuntu Desktop installations >= 12.10 (Quantal). Inspired by [Chris Evan] work on exploiting 6502 processor opcodes on the NES, [Donncha] describes the whole process of finding and exploiting a 0-day on a modern linux system.
One of the flaws, tracked as CVE-2016-9949, relies on a python code injection in the crash file. Apport blindly uses the python eval() function on an unsanitized field (CrashDB) inside the .crash file. This leads directly to arbitrary python code execution. The other flaw, tracked as CVE-2016-9950, takes advantage of a path traversal attack and the execution of arbitrary Python scripts outside the system hook_dirs. The problem arises when another field (Package) from the crash report file is used without sanitizing when building a path to the package hook files.
CVE-2016-9949 is easily exploitable, if an attacker can trick a user into opening a specially crafted file (apport .crash file), the attacker can execute the python code of his/her choice. Two details make it a very interesting exploit.
The first thing to note is the exploit’s reliability. Given that it is pure python code execution, an attacker doesn’t have to worry about ASLR, Non-Exec Memory, Stack Canaries and other security features that Ubuntu ships by default. As the author notes:
“There are lots of bugs out there which don’t need hardcore memory corruption exploitation skills. Logic bugs can be much more reliable than any ROP chain.”
Another interesting detail is that the exploit file doesn’t need to have the .crash extension, as long as its content starts with the string “ProblemType: ” and the file extension is not associated already with other software, Ubuntu considers it being of mime-type type=”text/x-apport” (for example, .ZlP or .0DF). This significantly improves the chances of an unsuspecting user being fooled into open the file.
[via HackerNews]
eval() != evil, but I avoid it. True, it’s one of those Lisp heirlooms that make Python awesome, but if it’s wrong, it will probably be wrong silently…
Pythons eval is really hard to secure.
http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html
Always check you inputs!
Hear, Hear!
someone should be smacked with a fish for coding these bugs!
Why, coders are not taught any security practices. Coders (and anyone else) can’t be expected to test their code reliably. Human nature means we are bad at checking what we do.
The systems and processes are at fault for not finding this.
Between this and shellshock and good old-fashioned SQL injection I’ve been noticing a general pattern that any tool that can process it’s own commands at runtime is a whole trojan horse of additional unnecessary capability. There should be standard accepted ways to send these things data that’s considered forever only data rather than use text manipulation to build scripts on the fly. JDBC does this for SQL via PreparedStatements everything else should do something similar as a best practice.
With bugs like these floating around perhaps the good old unix security is more through obscurity than inherent these days.
Yup. And anyone who ‘knows’ linux will agree.
Way to also leave out that this has already been patch and there was a bounty awarded. Awful reporting.
why are there no permissions set on the crash file that allow only a read only attempt oh nvm
EWBUN2 as those who like it call it.
Little Bobby Tables, we call him.
“if an attacker can trick a user into opening a specially crafted file” is not an exploit. It is user stupidity. If I send you a bash script, and you run it, there is nothing wrong with bash.
The exploit is not getting them to open it….the exploit doesn’t execute until the file has been opened/loaded.
An exploit is taking advantage of a flaw in the system to accomplish some goal.
Granted the user should check the contents of the file (in this case….verify that it is a zip file) before loading it.
Example:
$ file something.zip
something.zip: Zip archive data, at least v1.0 to extract
It also might be useful to secure the system by not allowing the system to open files based on their content or mime-type.
In fact it would probably be better to force users to manually open the files directly with the application (in the case of a zip file: open them directly through the archive program)
A hack on hackaday! What a glorious day this is!
But no Arduino? Or Raspberry Pi? Bah!