2

I have to evaluate how difficult it would be to extract some object (e.g. java.security.PrivateKey) from memory of a running java program.

I'm not very into this low level memory stuff, so I started out with small C programs and familiarized myself with gdb, /proc/<pid>/maps, /proc/<pid>/mem and a script that dumps all the memory areas.

However, things change when switching to java. Memory is allocated and managed very differently with java thanks to garbage collection. In C programs I'd look at a stack address and know for certain that it contained the variable I wanted to extract.

So my questions are:

  1. Do Java objects have some kind of type ID so I can locate objects of that type in a memory dump?
  2. If so, how do I find out the ID of a type (e.g. what's the ID of a String)?
  3. If there is no such type ID, what other possibilities would attackers have to extract, let's say, a java.security.PrivateKey from a java process?

Suppose that JMX is turned off.

Thanks for your help

Community
  • 1
  • 1
S1lentSt0rm
  • 1,989
  • 2
  • 17
  • 28
  • 1
    See http://stackoverflow.com/a/18880485/1015327. [VisualVM](https://dzone.com/articles/visualvm-see-whats-your-heap) could be helpful. – JimmyB Sep 16 '15 at 10:31
  • VisualVM is a great pointer. Honestly I'm a little bit shocked: How can it be that visualvm is able to give me all this information _without root priviledges_? – S1lentSt0rm Sep 16 '15 at 11:19
  • Ahh I see, that's why: _"Java applications are automatically exposed for monitoring and management by JMX agents"_ [1] Having that as default is really bad for any application that stores sensible data in memory. In my opinion this should be changed... [1] https://visualvm.java.net/jmx_connections.html – S1lentSt0rm Sep 16 '15 at 11:30
  • At a glance, it seems like it's even worse than that: I cannot seem to even find an option to *disable* monitoring in Java 6+... – JimmyB Sep 16 '15 at 12:47
  • @HannoBinder You _can_ disable it with this flag: `-XX:+DisableAttachMechanism` (found [here](http://stackoverflow.com/q/1255049/1922350)) – S1lentSt0rm Sep 16 '15 at 13:04
  • If an attacker can dump the entire memory of a process you already lost the game. Difficulty may vary slightly for them, but in the end that difficulty will all within the same computational complexity class. I think you're basically asking the wrong questions here. You should consider your threat model and how it relates to the kind of attacks you can and want to defend against. – the8472 Sep 17 '15 at 00:06
  • @the8472 I _do_ know that an attacker basically needs root privileges to make a memory dump and that an attacker with that much power would probably have easier ways to get what he wants (key logger, modify program for next run, ...). However, it is exactly what you mentioned that interests me: the computational complexity and the algorithm or "path" one would use. – S1lentSt0rm Sep 17 '15 at 08:19
  • If you just want to know "how difficult" then the answer is "not difficult". The JVM is not some magical obfuscation engine. As for the computational complexity, At worst it's O(n), a few heap scans to extract the necessary information. WIth additional knowledge one could maybe bring it down to O(1). – the8472 Sep 17 '15 at 08:40
  • @the8472 Could you point out (as an answer) _how_ that could be done? Let's say I want to find java.lang.PrivateKey objects. Where are the vtables stored in memory? How do I find the address of a specific class' vtable so I can find the objects associated with this vtable? Or _how_ else would you do it? Thank you! – S1lentSt0rm Sep 17 '15 at 09:36
  • What you are asking in your comment does not tie well to the stated intent of your question. If you want to evaluate the complexity then any answer is going to be some naive approach full of generalizations and simplifications. So its hardly going to provide much tighter bounds than "it's in the heap, therefore we can just brute-force it". Basically, you claim to ask "how difficult would it be for an attacker" and then actually ask "please outline all the necessary details to implement an attack". Assessing complexity is not the same as outlining one conceivable approach among many. – the8472 Sep 17 '15 at 10:28

1 Answers1

2

This is even easier than you might think :)

HotSpot Serviceability Agent does the magic. It can open a core dump or attach to a live Java process using ptrace and then extract the layout of JVM structures and all Java objects. No cooperation from target JVM is needed. This works even when JMX and Attach Mechanism are disabled.

Here is an example how to inspect the instances of a given class in the remote JVM.
sa-jdi.jar must be in the classpath to work with Serviceability Agent.

Finally the easiest solution ever. Run jmap -F -dump:format=b,file=heap.bin PID
Note -F argument - it forces jmap to use Serviceability Agent to make the heap dump.

P.S. Here are the sources of SA if you'd like to know how it works under the hood.

apangin
  • 92,924
  • 10
  • 193
  • 247
  • I tried `jmap -F -dump:format=b,file=heap.bin PID` before, but I was always getting an InvocationTargetException ([stacktrace](http://pastebin.com/4P8znwTv)). However, this is a great pointer! I will try and mark as accepted if I succed. Thank you! – S1lentSt0rm Sep 17 '15 at 23:35
  • @S1lentSt0rm Note that the sa-jdi.jar and jmap must belong to exactly the same version of Java as the target process (because the layout of VM structures may change from version to version). If this is not the case and if you have a reproducible example where `jmap -F` always fails, please show it to us as it could be a JDK bug. – apangin Sep 18 '15 at 07:23
  • Here is a [shell session](http://pastebin.com/MduBNuRZ) that demonstrates the problem. I did some research and found that ptrace_scope has to be set to 0, but that didn't help. – S1lentSt0rm Sep 18 '15 at 08:58
  • It _does_ work on another machine though, so I'm going to accept this answer as it was exactly what I was looking for. I'll try to isolate and resolve the problems I have with my machine and report my findings. Thanks again! – S1lentSt0rm Sep 18 '15 at 10:05