6 ms·

Gotta love those reflection api attacks and other remote procedure injections. Also, don't forget that everything is an object.

uaygsfdbzf 12y ago
could you expand on that?
mavroprovato 12y ago
Could you provide an example of those attacks/injections?
- Fasebook 12y ago
  Read this backwards: http://en.wikipedia.org/wiki/Java_EE_version_history http://en.wikipedia.org/wiki/Java_EE_version_history of course, Jvm is insecure by design, that's the whole point of a VM, really, to run anything no matter the context, so they're always be the same ways to escape the sandbox: http://seclists.org/fulldisclosure/2013/Jul/172 http://seclists.org/fulldisclosure/2013/Jul/172 The only thing keeping it secure is legions of devs and an "application server" propagating trust.
  - berdario 12y ago
    How can a JRuby (or Clojure, or Jython...) REST api trigger a vulnerability in the Java reflection? I was always under the impression that such kind of vulnerabilities were only a problem for Java applets (where the sandbox is actually important) Has any exploit ever been built for such circumstances? (I admit that I'm ignorant of their existance)
  - mavroprovato 12y ago
    I really do not understand what the Jave EE version history page has to do with the security of the Java runtime. As for the other link, I think you have mixed things up a little. Those vulnerabilities are ways to bypass the Java sandbox, when Java is running in the browser as an applet. This is really not comparable to Ruby, as it cannot run in the browser and does not even have a sandbox functionality as far as I know. Show me a way to remotely execute code on a machine just because it is running Java, and you will have my fullest attention :-)
  - jerven 12y ago
    The JVM has at least a security model/system. Something the Ruby MRI VM lacks. i.e. a ruby program is never in a sandbox. Using the JVM with JRuby or Ruby MRI as webserver are reasonably equivalent in security footprint. And in recent history MRI has had really worrying security issues too e.g. https://www.ruby-lang.org/en/news/2013/11/22/heap-overflow-in-floating-point-parsing-cve-2013-4164/ https://www.ruby-lang.org/en/news/2013/11/22/heap-overflow-i... I mean security can always be improved but you are comparing apples to apples and declaring one of the two to be an orange without decent evidence or support.
petersellers 12y ago
>Also, don't forget that everything is an object. This is false. What point are you trying to make here?

uaygsfdbzf 12y ago

could you expand on that?

mavroprovato 12y ago

Could you provide an example of those attacks/injections?

Fasebook 12y ago
Read this backwards: http://en.wikipedia.org/wiki/Java_EE_version_history http://en.wikipedia.org/wiki/Java_EE_version_history of course, Jvm is insecure by design, that's the whole point of a VM, really, to run anything no matter the context, so they're always be the same ways to escape the sandbox: http://seclists.org/fulldisclosure/2013/Jul/172 http://seclists.org/fulldisclosure/2013/Jul/172 The only thing keeping it secure is legions of devs and an "application server" propagating trust.
- berdario 12y ago
  How can a JRuby (or Clojure, or Jython...) REST api trigger a vulnerability in the Java reflection? I was always under the impression that such kind of vulnerabilities were only a problem for Java applets (where the sandbox is actually important) Has any exploit ever been built for such circumstances? (I admit that I'm ignorant of their existance)
- mavroprovato 12y ago
  I really do not understand what the Jave EE version history page has to do with the security of the Java runtime. As for the other link, I think you have mixed things up a little. Those vulnerabilities are ways to bypass the Java sandbox, when Java is running in the browser as an applet. This is really not comparable to Ruby, as it cannot run in the browser and does not even have a sandbox functionality as far as I know. Show me a way to remotely execute code on a machine just because it is running Java, and you will have my fullest attention :-)
- jerven 12y ago
  The JVM has at least a security model/system. Something the Ruby MRI VM lacks. i.e. a ruby program is never in a sandbox. Using the JVM with JRuby or Ruby MRI as webserver are reasonably equivalent in security footprint. And in recent history MRI has had really worrying security issues too e.g. https://www.ruby-lang.org/en/news/2013/11/22/heap-overflow-in-floating-point-parsing-cve-2013-4164/ https://www.ruby-lang.org/en/news/2013/11/22/heap-overflow-i... I mean security can always be improved but you are comparing apples to apples and declaring one of the two to be an orange without decent evidence or support.

petersellers 12y ago

>Also, don't forget that everything is an object. This is false. What point are you trying to make here?