3 ms·
Please note that the only way to exploit these vulnerabilities is you've already got your code executing on the machine you intend to break. The only thing this
by waps 13y ago
Please note that the only way to exploit these vulnerabilities is you've already got your code executing on the machine you intend to break. The only thing this allows you to do is to break out of the java sandbox, and keep in mind that most languages don't even pretend that sandbox isolates code (e.g. python/perl/go/... all openly say you can easily break out of the sandbox). So they're trying to solve a really hard problem.
- taspeotis 13y agoPlease note that the only way to exploit these vulnerabilities is you've already got your code executing on the machine you intend to break I can't reconcile this with the article. ...34 that are bugs that can be exploited remotely by an attacker without requiring authentication By "your code" do you mean "Java-based application"? Honest question.
- waps 13y agoI mean that these bugs only solve the "break out of the sandbox" issue. They do not get your code on to the machine to exploit. In other words these flaws are the equivalent of "I can upload code, how do I get to shell access to the java account".
- toyg 13y agoConsidering the crappy quality of most java-powered "enterprise" software, I'd say this scenario is extremely likely.
- cma 13y agoSo basically, if someone browses to a site with an applet and doesn't block Java.
- taspeotis 13y agoI wouldn't call that a remote exploit.
- tptacek 13y agoUnlike the whole software security industry, which does.
- taspeotis 13y agoI don't work in the software security industry like you but I don't see how it's a remote exploit. Wikipedia gives a way of discerning the two [1] that makes sense to me, as a software security industry layperson: > Whether they need to be run on the same machine as the program that has the vulnerability (local) or can be run on one machine to attack a program running on another machine (remote). So if a user starts running the code for you on their machine, it's local. If I send a malformed JPG to a Java webservice that process images, and it doesn't process the JPG correctly leading to code execution or a DoS then that's remote. [1] http://en.wikipedia.org/wiki/Exploit_(computer_security) http://en.wikipedia.org/wiki/Exploit_(computer_security)
- tptacek 13y agoThat's a 1990s definition of the term "remote", but 51% of Wikipedians now disagree with the whole software security industry, which uniformly considers browser drive-by vulnerabilities to be "remote".
- meowface 13y agoI agree, it's a local exploit, not a remote exploit (I've debated this with people as well), but in the end Java sandbox bypass exploits are (or were) the most effective local exploit possible. And they're arguably far more valuable than the vast majority of remote exploits out there. Silent, cross-browser, cross-platform; browser plugin installed by default with anyone who has Java. And that's a huge number of people, since a ton of corporate and residential users have Java installed on all sorts of devices. Java is responsible for a massive ramp up in infections of computer literate and illiterate users alike between 2010 and now.
- girvo 13y agoJava Applets.
- tptacek 13y agoThey are indeed trying to solve a hard problem, and they're shackled to a 1990s design. But I'm not sure I understand the rest of your comment. The threat model for a Java plugin vulnerability is, if your target has the Java plugin enabled, they can't safely browse the web; any page they visit could end up redirecting them to a page with a malicious applet. That's pretty bad.
- InclinedPlane 13y agoThis is a very disingenuous way of describing the risk of drive by exploits in the browser.