User: Password:
|
|
Subscribe / Log in / New account

Java and Memory Protections

Java and Memory Protections

Posted Nov 22, 2006 8:49 UTC (Wed) by tzafrir (subscriber, #11501)
In reply to: Virtual Machines and Memory Protections by jwb
Parent article: Virtual Machines and Memory Protections

Java has basically the same problem, right?

I'm surprised that the article has not mentioned it.


(Log in to post comments)

Java and Memory Protections

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

I'm not sure Java enables to dynamically create code. At least I haven't generated byte code dynamically, but I might have read something about this. Actually I've written self-modifying code in LISP, so I guess there is a problem with that language as well.

Bye,NAR

Java and Memory Protections

Posted Nov 22, 2006 14:16 UTC (Wed) by smitty_one_each (subscriber, #28989) [Link]

Isn't dynamic code generation a natural consequence of a virtual machine coupled with reflection?
If my understanding of what the Apache Tomcat code was correct back in '03, at boot-time, the XML configuration files got parsed and instantiated all of the security classes for the app server via reflection: the XML was a de facto scripting language for the JVM.

Java and Memory Protections

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

Isn't dynamic code generation a natural consequence of a virtual machine coupled with reflection?

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.

Bye,NAR

Java and Memory Protections

Posted Nov 22, 2006 15:40 UTC (Wed) by gouyou (guest, #30290) [Link]

From the article the problematic code generated is the native code executed by the processor. So in fact I believe the problem exist for all language using a VM using a Just-in-Time compiler: C#, Java, but also future version of Python, Perl running on a VM doing JiT compilation.

The security problem won't anyway be fixed by PaX or SELinux. Any language providing an eval function will have this type of problem, just at a higher level.

Java and Memory Protections

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

The security problem won't anyway be fixed by PaX or SELinux. Any language providing an eval function will have this type of problem, just at a higher level.

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.

Bye,NAR

Java and Memory Protections

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

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

Java and Memory Protections

Posted Nov 22, 2006 18:11 UTC (Wed) by Per_Bothner (subscriber, #7375) [Link]

Java does support dynamically generated classes. This is used by Kawa for its evaluator: Kawa reads a high-level program (Scheme, XQuery, Emacs Lisp), translates it to Java bytecodes, dynamically creates a class, and then calls a method in the class. It is quite fast, allowing for a very responsive read-eval-print-loop combined with fast execution.

Java and Memory Protections

Posted Nov 22, 2006 18:19 UTC (Wed) by iabervon (subscriber, #722) [Link]

Dynamic generation of Java bytecode is actually quite common; that's how applets actually work. The plugin, running in a JVM, downloads code from the internet as a sequence of bytes, and calls the library method to read the memory as classes. Sure, it's not generation of bytecode from scratch, but it is pulled out of nowhere with respect to memory protection and certainly ahead-of-time compilation.

Java and Memory Protections

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

This is incorrect. This is not how applets work. Applets use classloaders (network classloaders in this case) exactly like any standalone Java application might.

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.

Java and Memory Protections

Posted Dec 3, 2006 12:54 UTC (Sun) by fjalvingh (guest, #4803) [Link]

You are both right. A ClassLoader is used to create the class. But the classloader used for Applets (which is a a standard one) indeed merely loads a stream of bytes and instantiates these as a Class using a ClassLoader base method [ Class defineClass(String name, byte[] b, int off, int len)].

In Java it is trivial to write and execute your own byte code from within a program; whole libraries exist to help you doing it (BCEL, ASM). I used this extensively in many programs to speed up scripting stuff or parameterized logic by compiling it into a class (which will then be JITted by the Java runtime).

Anyway, the fact that Java code can do that has nothing to do with the article's subject which has to do with actual executable content for a system processor...

Java and Memory Protections

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

To me, the meat of the problem is that "safe" code (C#, Java) is allowed to call native libraries. It then becomes possible for the "safe" code to exploit flaws in those native libraries, which is obviously unsafe.

The nice thing about Java is you can easily forbid calling native code.

Java and Memory Protections

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

> The nice thing about Java is you can easily forbid calling native code.

C# can do this as well. The thing is, sometimes you actually need the functionality present in the native libraries. F-Spot uses libpng to show PNG images, and libjpeg to show JPEGs. As well, Mono uses Gecko and .NET uses IE to supply the Internet Explorer Web control from .NET, which has obvious implications; if you want to write a Web browser, are you going to be forced to write it all in C#, including render engine?

Java and Memory Protections

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

I don't see why not. Java provides pure Java (not native) PNG and JPEG routines, as well as pure Java cryptography, pure Java compression, and the rest. Oh, and there are also pure Java web browsers.

Java and Memory Protections

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

Sun Java does. What about GNU Classpath? Kaffe? Project Harmony? IKVM?

Java and Memory Protections

Posted Dec 3, 2006 12:57 UTC (Sun) by fjalvingh (guest, #4803) [Link]

One good reason to go native is performance.. Although Java performance is usually great you can get huge performance gains using assembly for specialized problems (like image encoding/decoding/filtering for instance)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds