Java and Memory Protections

Posted Nov 22, 2006 14:49 UTC (Wed) by NAR (subscriber, #1313) [Link]

I'm not sure - in my mind, reflection is about getting runtime information about the objects, it has nothing to do with creating anything. Anyway, as far as I understand, the problem with memory protection is not simply the dynamic code generation, but the compilation of the generated code to machine-level instructions. So even though one can write self-modifing code in LISP or perl, it's not a problem until the interpreter executes this code, not the CPU directly.

Posted Nov 22, 2006 16:18 UTC (Wed) by NAR (subscriber, #1313) [Link]

Yes, consider this bash code:


X="/bin/r"
Y="m -f /"
Z=$X$Y
eval $Z


If the values of X and Y are not hardcoded, but come from the untrusted input, then it's a problem. That's why things like the -T option of perl got invented - I wonder if other languages/VMs have options like this.

Posted Nov 22, 2006 19:13 UTC (Wed) by bluefoxicy (guest, #25366) [Link]

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...

Posted Nov 24, 2006 18:45 UTC (Fri) by ttfkam (guest, #29791) [Link]

JSPs have sort-of done this for years by compiling whenever the source doc is modified. Another example would be the "translets" created from XSLT stylesheets tranformations by the XSLTC.

A better example of dynamic code generation would be frameworks that implement EJB3 and read information from annotations to generate code that fits those aspect-oriented patterns.

But that's higher level. From the implementation point of view, dynamic code generation is implemented from libraries like ASM, JavaCC, cglib, etc.

Posted Nov 22, 2006 19:22 UTC (Wed) by jwb (guest, #15467) [Link]