5 ms·

This sounds like a witch hunt. Java has horrible security bugs even today. Bugs can be found in code written in all languages.

iso-8859-1 10y ago
Java removed certain classes of errors (memory management). It introduced other (providing an insecure sandbox for applets).
- wolf550e 10y ago
  I think code execution by insecure deserialization is the big Java security problem now, though I'm neither a security guy nor a Java guy.
- lmm 10y ago
  It's not like C applets are safer.
  - PeCaN 10y ago
    If we consider NaCl to be "C applets"... yes, it actually is safer.
swsieber 10y ago
Right. And certain languages remove entire classes of bugs.
Someone1234 10y ago
No disputing that bugs can be written in any language. But by avoiding C/C++ you're excluding a specific class of bugs which have historically proved harmful. You can write exploitable code in Java. But you'd actually have to try if you wanted Java to be able to write arbitrary memory or execute arbitrary code. Essentially any bug that can be written in Java/Go/Rust/etc can be written in C/C++. But some C/C++ bugs are extremely uncommon in other languages, or you have to actually TRY to introduce them.
- ArkyBeagle 10y ago
  Intent doesn't matter; results do. This is a heatmap problem - there's simply more 'C'/C++ code out there.
  - hansjorg 10y ago
    I'm pretty sure there is more (and a greater variety of) net facing Java code than C/C++ code.
    - ArkyBeagle 10y ago
      You may be right. I'm just thinking that everything( has an O/S and it's probably written largely in 'C'. So much will depend on how you measure it. I tend to ignore the web as much as possible.
- shanemhansen 10y ago
  > But you'd actually have to try if you wanted Java to be able to write arbitrary memory or execute arbitrary code. Depends on your definition of arbitrary. Higher level languages have higher level exploits. While injecting x86 shellcode into a java process is probably hard, many java applications have been vulnerable to serialization bugs which result in the execution of arbitrary bytecode. Source: http://www.darkreading.com/informationweek-home/why-the-java-deserialization-bug-is-a-big-deal/d/d-id/1323237 http://www.darkreading.com/informationweek-home/why-the-java...
  - pcwalton 10y ago
    Nobody is saying RCE is impossible in memory safe languages, just much less likely.
    - askyourmother 10y ago
      And this needs to be said more "RCE is possible in Rust", because sometimes it is portrayed in almost unassailable terms.
gr3yh47 10y ago
>Bugs can be found in code written in all languages. But not all languages frequently produce security vulnerabilities as a result of common types of bugs that are due to error-prone humans having to do things that should be done for us automatically in the year of our Lord 2016
Sindisil 10y ago
To be clear, are you referring to security bugs in the Java standard library (written almost completely in Java), or those in the JVM itself or the browser plugins (written almost entirely in C++), or in Java code bases? The vast majority of the high profile Java security bugs have been in the second, which would be more of a ding against C++ than Java the language, wouldn't it?
- geodel 10y ago
  I think it would be against Java in sense Java does not support writing high performance code like Java runtime / security code etc. Now it may not have errors as much as openssl but that argument will be about implementation quality not against C/C++.
tveita 10y ago
Most the horrible security bugs in Java show up in the sandbox, where attackers can supply arbitrary code for you to run. In contrast, Java as a server language has an excellent security record IME. The last public patch panic I can remember was in 2011 with the denial of service bug regarding parsing of floating points. There has been other security bugs regarding cryptography etc, I'm sure, but in general you can feel very secure running Java on your servers. It is a shame that security bugs for both are bundled together, making every sandbox compromise a "Remote exploitable" vulnerability. The "applet" use case should probably just die, there is no indication that Java sandboxing will ever be secure, the design is unsound.
- hansjorg 10y ago
  Oracle is deprecating the Java browser plugin in JDK 9, ie. the applet use case. There will still be support for Java Web Start though.
  - ThisIs_MyName 10y ago
    I've always wondered why nobody sandboxes Java applets in a LXC/Docker container or in a chrome sandbox the same way flash is contained.
- makomk 10y ago
  Java as a server language has a record of nasty serialization-related RCE vulnerabilities. Of course, they're in popular Java libraries used on the server rather than the language itself, just like this bug was in a popular C library rather than the language itself - but Java makes it very easy to accidentally write that kind of vulnerability. In fact, just loading two unrelated libraries that are individually safe sometimes create an exploitable RCE condition in Java. That's worse than even C.
_Codemonkeyism 10y ago
Not sure what 'horrible security bugs' in Java you are referring too. If those you refer too, and there are many, are exploits in browser plugins, sandboxes or the JVM, these are written in C(++).
cstejerean 10y ago
Java applets have security issues today. That's a situation where you are allowing random websites to execute arbitrary code on your computer. Flash has the same issues. So don't do that. Don't confuse Java applets (and the lack of security thereof) with the JVM as a development platform. I'd bet on the security of a Java application over that of a C/C++ application any day.
lmm 10y ago
> Java has horrible security bugs even today. Example? > Bugs can be found in code written in all languages. And there's no difference between a bug every week and a bug every 10 years?
- robert-wallis 10y ago
  Here's a list of Java CVEs: https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html https://www.cvedetails.com/vulnerability-list/vendor_id-93/p... To be clear, I am not a security researcher, and I haven't verified the severity of these issues. But in 2016 alone there are 16 CVEs which is 4 per month.
  - lmm 10y ago
    Those are vulnerabilities in the JVM itself - and I'd bet a fair bit the majority will be in the C/C++ parts, not the Java parts.
pcwalton 10y ago
> Bugs can be found in code written in all languages. This is like saying "there's no point building bridges because sometimes they collapse". Memory safety bugs are found far, far less often in memory-safe languages.

iso-8859-1 10y ago

Java removed certain classes of errors (memory management). It introduced other (providing an insecure sandbox for applets).

wolf550e 10y ago
I think code execution by insecure deserialization is the big Java security problem now, though I'm neither a security guy nor a Java guy.
lmm 10y ago
It's not like C applets are safer.
- PeCaN 10y ago
  If we consider NaCl to be "C applets"... yes, it actually is safer.

swsieber 10y ago

Right. And certain languages remove entire classes of bugs.

Someone1234 10y ago

No disputing that bugs can be written in any language. But by avoiding C/C++ you're excluding a specific class of bugs which have historically proved harmful. You can write exploitable code in Java. But you'd actually have to try if you wanted Java to be able to write arbitrary memory or execute arbitrary code. Essentially any bug that can be written in Java/Go/Rust/etc can be written in C/C++. But some C/C++ bugs are extremely uncommon in other languages, or you have to actually TRY to introduce them.

ArkyBeagle 10y ago
Intent doesn't matter; results do. This is a heatmap problem - there's simply more 'C'/C++ code out there.
- hansjorg 10y ago
  I'm pretty sure there is more (and a greater variety of) net facing Java code than C/C++ code.
  - ArkyBeagle 10y ago
    You may be right. I'm just thinking that everything( has an O/S and it's probably written largely in 'C'. So much will depend on how you measure it. I tend to ignore the web as much as possible.
shanemhansen 10y ago
> But you'd actually have to try if you wanted Java to be able to write arbitrary memory or execute arbitrary code. Depends on your definition of arbitrary. Higher level languages have higher level exploits. While injecting x86 shellcode into a java process is probably hard, many java applications have been vulnerable to serialization bugs which result in the execution of arbitrary bytecode. Source: http://www.darkreading.com/informationweek-home/why-the-java-deserialization-bug-is-a-big-deal/d/d-id/1323237 http://www.darkreading.com/informationweek-home/why-the-java...
- pcwalton 10y ago
  Nobody is saying RCE is impossible in memory safe languages, just much less likely.
  - askyourmother 10y ago
    And this needs to be said more "RCE is possible in Rust", because sometimes it is portrayed in almost unassailable terms.

gr3yh47 10y ago

>Bugs can be found in code written in all languages. But not all languages frequently produce security vulnerabilities as a result of common types of bugs that are due to error-prone humans having to do things that should be done for us automatically in the year of our Lord 2016

Sindisil 10y ago

To be clear, are you referring to security bugs in the Java standard library (written almost completely in Java), or those in the JVM itself or the browser plugins (written almost entirely in C++), or in Java code bases? The vast majority of the high profile Java security bugs have been in the second, which would be more of a ding against C++ than Java the language, wouldn't it?

geodel 10y ago
I think it would be against Java in sense Java does not support writing high performance code like Java runtime / security code etc. Now it may not have errors as much as openssl but that argument will be about implementation quality not against C/C++.

tveita 10y ago

Most the horrible security bugs in Java show up in the sandbox, where attackers can supply arbitrary code for you to run. In contrast, Java as a server language has an excellent security record IME. The last public patch panic I can remember was in 2011 with the denial of service bug regarding parsing of floating points. There has been other security bugs regarding cryptography etc, I'm sure, but in general you can feel very secure running Java on your servers. It is a shame that security bugs for both are bundled together, making every sandbox compromise a "Remote exploitable" vulnerability. The "applet" use case should probably just die, there is no indication that Java sandboxing will ever be secure, the design is unsound.

hansjorg 10y ago
Oracle is deprecating the Java browser plugin in JDK 9, ie. the applet use case. There will still be support for Java Web Start though.
- ThisIs_MyName 10y ago
  I've always wondered why nobody sandboxes Java applets in a LXC/Docker container or in a chrome sandbox the same way flash is contained.
makomk 10y ago
Java as a server language has a record of nasty serialization-related RCE vulnerabilities. Of course, they're in popular Java libraries used on the server rather than the language itself, just like this bug was in a popular C library rather than the language itself - but Java makes it very easy to accidentally write that kind of vulnerability. In fact, just loading two unrelated libraries that are individually safe sometimes create an exploitable RCE condition in Java. That's worse than even C.

_Codemonkeyism 10y ago

Not sure what 'horrible security bugs' in Java you are referring too. If those you refer too, and there are many, are exploits in browser plugins, sandboxes or the JVM, these are written in C(++).

cstejerean 10y ago

Java applets have security issues today. That's a situation where you are allowing random websites to execute arbitrary code on your computer. Flash has the same issues. So don't do that. Don't confuse Java applets (and the lack of security thereof) with the JVM as a development platform. I'd bet on the security of a Java application over that of a C/C++ application any day.

lmm 10y ago

> Java has horrible security bugs even today. Example? > Bugs can be found in code written in all languages. And there's no difference between a bug every week and a bug every 10 years?

robert-wallis 10y ago
Here's a list of Java CVEs: https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html https://www.cvedetails.com/vulnerability-list/vendor_id-93/p... To be clear, I am not a security researcher, and I haven't verified the severity of these issues. But in 2016 alone there are 16 CVEs which is 4 per month.
- lmm 10y ago
  Those are vulnerabilities in the JVM itself - and I'd bet a fair bit the majority will be in the C/C++ parts, not the Java parts.

pcwalton 10y ago

> Bugs can be found in code written in all languages. This is like saying "there's no point building bridges because sometimes they collapse". Memory safety bugs are found far, far less often in memory-safe languages.