
An In-Depth Study of More Than Ten Years of Java Exploitation - mpweiher
https://testlab.sit.fraunhofer.de/downloads/publications/holzinger2016java.pdf?platform=hootsuite
======
merb
well I've read the paper a multiple times, most of these "exploits" need
"malicious code", how is that even possible? If somebody can inject malicious
code I would say that the game is already over. Of course Applets are
different, but I always hoped that they will be removed soon and that will be
the case (soon).

~~~
WatchDog
Yeah I feel like the tone of the paper is a bit unfair, all of these exploits
are the result of a feature that very few other languages/runtimes even
attempt to implement(safely running untrusted code).

------
misterbowfinger
I'm probably inviting downvotes, but this paper's conclusion reads to me as
"Object-Oriented Programming caused these exploits"

~~~
nl
I don't see anything that is really object-oriented specific here.

Yes, the terminology is all OO-based, but it is really about unauthorized
access to code. There's nothing OO specific about it.

For example:

 _Twelve vulnerabilities abuse a confused deputy to call MethodHandles.lookup
to get a lookup object on behalf of a system class. Such a lookup object can
be used by malicious code to access members that are accessible to the system
class, but that should be inaccessible to untrusted code_

This vulnerability would be exactly the same in principle if it was a
functional or imperative programming. Loosely bound code is loaded into the
incorrect security context and exploited. In a very loose sense, it is similar
to
[https://www.cvedetails.com/cve/CVE-2012-3479/](https://www.cvedetails.com/cve/CVE-2012-3479/),
which is an EMACS Lisp bug cause by incorrect checks[1]. OO or Functional -
bugs like this are the same thing.

[1] [http://www.openwall.com/lists/oss-
security/2012/08/13/1](http://www.openwall.com/lists/oss-
security/2012/08/13/1)

