Yes, that's kind of what I meant by sneaking in through the backdoor. An article supposedly about Java development focuses on all the non-JVM dependencies. You don't need to build things in this way. Is this how everyone works these days? It surprised me that nobody else was commenting on this...
I think it's worth noting that what you're referring to - the JVM escapes - are exploited under a completely different threat model where the attacker already has remote code execution.
In this model the attacker already can execute code on the victim's host, but the VM attempts to limit what the attacker can do via restricted APIs. It's just a completely different threat.
If you take Java bytecode to be the attack surface, it is probably less likely than that a complex, microcode-based CPU instruction set contains a back door because it is hard to smuggle a multi-instruction side effect into an open source bytecode interpreter. Other attacks like an undocumented jni call are also difficult to conceal. That leaves things like network libraries, and most of those are an interface to protocols, leaving not much room for shenanigans, IF the source is available and build-able.
Though the obvious explanation for that is that it was an intentional backdoor, that honestly looks more to me like a legitimate oversight than a backdoor. I think an actual backdoor would be a lot more subtle and clever than that. Especially since this way, absolutely anyone could exploit it (it's just Java Debug Wire Protocol).
Also, you have to explicitly run it in debug mode for this to happen, which probably only a small percentage of end users will do. Kind of seems like the equivalent of running Flask apps in debug mode, which by default will handle exceptions by showing a traceback with an interactive debugger that can be used to execute arbitrary code.
There could be some backdoors in it, but I'm leaning towards that not being an intentional one. (But I definitely could be totally wrong; you never know when it comes to intelligence agencies.)
That doesn't address what I said in the sentence you quoted at all. We were discussing Java and vulnerabilities that arise given flaws in the JVM. You are talking about something else that is completely different.
This whole story has been stupid. These ideas have been around for ages and are not novel to the security community. Yet we've seen headlines like "all programs ever are vulnerable to this new hack." The root cause is not unicode characters but instead untrusted text. It isn't like a malicious library would be unable to sneak backdoors in through ascii source anyway. Heck, we just had a big kerfuffle over this happening in the linux kernel this year.
Or worse! Go look at the dependencies for some large enterprise system built in java. How many raw jars do you think are being included in there? Has anybody looked at the bytecode of these jars?
Guys, the cause of security is not helped by speculating wildly.
First of all, the Sun JVM is written in C++, not C. Second of all, the recent security problems are not the result of buffer overflows or other C++ coding problems, but design choices in the Java security model coupled with poor library coding. These vulnerabilities existed for a long time. The fact that they're only coming to light now is just a historical accident more than anything else. Oracle's response has been slow, but they did not create the problem. Sun did. (And I say that as a big fan of the old Sun Microsystems.)
The Java security model is supposed to allow you to keep both trusted and untrusted code in the same process space. Unfortunately, if any trusted library is poorly coded, you can use it to escalate your privileges. You can basically get something a lot like "eval" using the classloader and reflection.
This was a tradeoff that the Java language designers made. They chose to implement a powerful, but complex, sandboxing scheme. It would have been a lot simpler just to run the untrusted code in a separate process, like Chrome does. But that would have required interprocess communication. A lot of these 0-days have used this mechanism, or something like it, to exploit their privileges.
Another decision the Java web plugin designers made was to give plugins the ability to do almost everything native applications could do-- manipulate the filesystem, send network traffic, etc. This was another design choice that could have been made differently-- for example, Javascript historically never offered these kinds of abilities.
There have been a ton of Java 0-days and I don't have time to explain or research them all. But most of them flow directly out of the underinvestment in Java plugins over the last decade (a policy Sun started, and Oracle continued), and the fundamental design decisions made in the early days. I haven't seen any of them that were related to C or C++ (although I haven't examined all of them in detail so maybe there was one somewhere.)
I think he's implying something that would be remotely exploitable on a server running the JVM for a service with an open socket. Which is very common. Also the the File API could potentially be exploitable (if a vulnerability exist) remotely also if for example it was used for file uploads or something. Seems non-trivial but I can see how it could happen.
It's been a while since I worked in this area but my recollection was that most JVM security issues in this areas were bypasses of the Java Security Manager often by confusing it about code origin. That's all Java code, not C++.
For instance, Java application servers often have the capability to implement policies per application - so you can run the app server as a privileged user but do things like restrict access to parts of the file system, opening network sockets, using JNI, etc. Essentially this is the same mechanism that applets use to sandbox code. So any exploit that could circumvent this could have an effect outside of the browser, in theory.
I'm sorry if I misrepresented your post, but I feel you do the same to mine. I didn't say the JVM is insecure - I said the sandboxing part of the JVM is insecure and C++ doesn't have anything comparable.
Reading about CVE-2017-9805 it was really interesting to learn that the company that discovered it was using a Datalog-like language in order to query Java code for vulnerability patterns.
But the point still stands that this specific exploit is NOT a JVM exploit? Is it an actual exploit of the JVM implementation, or just the libraries?
The problem has always been that Sun shipped way too big a runtime for Java applets - the entire Java SE - when they should have made a third class ("edition") for browsers. That's a huge attack surface, and that's were most of the exploits have been, including this one, unless someone knows otherwise.
A large number of the Java CVEs you're thinking of are bugs in the Oracle JVM, meaning they are bugs in C++ code, which is not in a memory-safe language.
reply