Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Or, you could just write your software in Java.
Virtual Machines and Memory Protections
Posted Nov 22, 2006 4:18 UTC (Wed) by bluefoxicy (guest, #25366)
What does the Sun JVM use for various parts of Java? How about Kaffe? How about Apache's Project Harmony? GNU Classpath? Do they all use their own complete rewrites of everything in Java?
What is the JVM written in? Does it have bugs? (Sun's has had a few security holes itself, mostly though you would have to pass it broken Java bytecode to trigger these)
Writing something in Java has the same effect as writing it in C#: You don't know about the rest of the program, but the code YOU WROTE is immune to X Y and Z class of bugs. You're not even sure what virtual machine implementation the code is going to run on (Mono/IKVM, Kaffe, Harmony, Sun Java, IBM Java, GNU Classpath, proprietary in-house...).
Java and Memory Protections
Posted Nov 22, 2006 8:49 UTC (Wed) by tzafrir (subscriber, #11501)
I'm surprised that the article has not mentioned it.
Posted Nov 22, 2006 13:23 UTC (Wed) by NAR (subscriber, #1313)
Posted Nov 22, 2006 14:16 UTC (Wed) by smitty_one_each (subscriber, #28989)
Posted Nov 22, 2006 14:49 UTC (Wed) by NAR (subscriber, #1313)
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 15:40 UTC (Wed) by gouyou (subscriber, #30290)
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.
Posted Nov 22, 2006 16:18 UTC (Wed) by NAR (subscriber, #1313)
Yes, consider this bash code:
Y="m -f /"
Y="m -f /"
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)
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===
1. Buffer overflow (stack)
2. Buffer overflow (heap)
1. Attacker redirects instruction pointer
2. Attacker may execute foreign code (i.e. local root exploits)
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).
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)
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).
Create a complex return chain through various bits of code of the
... (code that doesn't mess up our attack)
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 22, 2006 18:11 UTC (Wed) by Per_Bothner (subscriber, #7375)
Posted Nov 22, 2006 18:19 UTC (Wed) by iabervon (subscriber, #722)
Posted Nov 24, 2006 18:45 UTC (Fri) by ttfkam (guest, #29791)
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 Dec 3, 2006 12:54 UTC (Sun) by fjalvingh (guest, #4803)
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...
Posted Nov 22, 2006 18:20 UTC (Wed) by jwb (guest, #15467)
The nice thing about Java is you can easily forbid calling native code.
Posted Nov 22, 2006 19:16 UTC (Wed) by bluefoxicy (guest, #25366)
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?
Posted Nov 22, 2006 19:22 UTC (Wed) by jwb (guest, #15467)
Posted Nov 22, 2006 19:25 UTC (Wed) by bluefoxicy (guest, #25366)
Posted Dec 3, 2006 12:57 UTC (Sun) by fjalvingh (guest, #4803)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds