Java and Memory Protections [LWN.net]

Java and Memory Protections

Posted Nov 22, 2006 19:13 UTC (Wed) by bluefoxicy (guest, #25366)
In reply to: Java and Memory Protections by gouyou
Parent article: Virtual Machines and Memory Protections

> The security problem won't anyway be fixed by PaX or SELinux.

You're right that higher-level languages misfiring "eval" statements can't be addressed; but this is not what I was referring to. What can be "fixed" by PaX or SELinux is the method of attack possible on broken native code. Consider the below.

===Begin Attack Model===

PROBLEM:
1. Buffer overflow (stack)
2. Buffer overflow (heap)
3. double-free

RESULT:
1. Attacker redirects instruction pointer
2. Attacker may execute foreign code (i.e. local root exploits)

SOLUTION 1:
1. No memory may be created WRITE and EXECUTE; and
2. No memory without EXECUTE may be granted EXECUTE

Attacker cannot directly write in code to execute, then carry out attack (memory-level W^X).

WORKAROUND 1:
1. Return to open(); then
2. return to write(); then
3. Return to mmap(), mmap() file executable; then
4. Return to mapped file (rootkit code)

SOLUTION 2:
1. SOLUTION 1; and
2. Employ mandatory access restrictions on what files can be mmap()'d executable. Limit to files in directories not writable by unprivileged users.

Attacker cannot use WORKAROUND 1, because he can't write a file and then mmap() it executable (filesystem-level W^X).

WORKAROUND 2:
Create a complex return chain through various bits of code of the
following structure:

@entry:
interesting_code
... (code that doesn't mess up our attack)
RET

This is highly unlikely to be possible or easy in most cases; often
this will be out of the attacker's scope. Attackers may keep a list
of interesting opcode locations to help speed up the creation of
these types of payloads, however.

See http://uninformed.org/?v=2&a=4&t=sumry for an attack that actually uses this bypass method.

===End Attack Model===

The above will allow most programs to execute properly; but will interfere with most memory-corruption-based security attacks. In the case of JIT, these protections prevent the JIT from ever working.

Usually, JIT is used for languages that you can't experience these kinds of bugs in. The article explains that the underlying C code and the other native code being linked in may still have these bugs, and can't fall under the protection umbrellas normally possible.

"Safe" languages are interesting and hopefully at least a partial solution can be found. A global AOT cache might work exclusively for code that doesn't use reflection...

(Log in to post comments)