Hacker News Reader

Comment by JustSomeNobody | Hacker News Reader

So, this is the Java plugin for browsers, right?

Why is there never a clear distinction?

What would a security exploit in Java outside the browser look like?

Buffer overflow to a network socket opened by the JVM? Or a similar attack executed against the standard library's file IO?

To achieve what? If you are executing Java locally it already has full disk and network access?

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.

True, if there was a vulnerability where reading a byte stream could trigger a JVM exploit, that is exploitable. But that would be a really weird bug, since the JVM isn't going to be the one parsing a byte stream.

There is also the standard library, it does a lot of stuff that could hide a vulnerability.

To go from "We can send your web server an HTTP request" to "We own your datacenter."

Most JVM methods can require permissions because it provides built-in POLA ACLs (security policies). The default would likely be to deny network access and file io. It's more likely that an app itself contains vulnerabilities &| unnecessary weaknesses due to ease of misconfiguration because of the pervasive lack of full-stack implications, grokable and auditable security policies.

http://download.oracle.com/sunalerts/1020226.1.html

> A buffer overflow vulnerability in the Java Runtime Environment with processing PNG images may allow an untrusted Java Web Start application to escalate privileges.

Java Web Start: In computing, Java Web Start (also known as JavaWS, javaws or JAWS) is a framework developed by Sun Microsystems (now Oracle) that allows users to start application software for the Java Platform directly from the Internet using a web browser.

That was the biggest attack vector but not the only one. Many of these image exploits also applied to e.g. pure server-side software that happened to use the java standard library to process user-submitted images.

Buffer overflow in the jpg, png or bmp decoder libraries?

There is a lot of enterprise, server side Java running around. It wouldn't surprise me if there were a vulnerability that could be used to attack it.

Likely something in I/O. Obviously this would probably be much more difficult to exploit, but the potential is there.

Just one example...

Any Java application can run a SecurityManager:

http://docs.oracle.com/javase/7/docs/api/java/lang/SecurityM...

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 can think of a few:

* Bug in the default XML parsing library that exposes local files, existence of local files, or even allows a user-supplied XML to open a socket to a remote server? * Vulnerability in SecurityManager that allows a sandboxed jar more privileges than it is supposed to have? * Allowing a default RMI-JMX configuration to provide an attack vector to authenticated clients whereby they can upload arbitrary code that executes outside of a SecurityManager?

Reply on news.ycombinator.com