12 ms·

Is Java more secure than C?

74 points by rwbhn 11y ago

vezzy-fnord 11y ago
If you are writing Java code to manage unprivileged Java code (such as an applet container), you are subject to about as many severe rules as if you are writing C code. If your Java code is itself unprivileged, however, or if you are ignoring Java's privilege model, you are subject to far fewer high-severity rules than if you program in C. Is the main thrust of this article.
- SFjulie1 11y ago
  Accessing resources on a system requires privileges. So java is inherently more insecure than C, because java developers are not aware that every time they access a socket, authentication, a file, ram they need privileges. And they tweak whatever policies and rules of the OS to do so. Yes : the problem is not the java dev but the sysadmins... Sysadmins says no it is unsecure, so companies say let's hire clueless devs call them devops and handle the delicate problem of secured access to resources by telling them: make it possible. It is not by hiding dust under the carpet, moving the problem to another place (from code to containers) and creating new "paradigms" to hide the inherent complexity of coding that situation will improve. in 2015 we are still lacking of able developers and every technic to work around the scarcity of really able developers are a failure and adding noise. Software is as good as the lowest "software" IQ of the member of the crowd building it -managers included-. Our managers are clueless, most our devs/devops/sysadmins are frauds.
  - cows_i_have 11y ago
    Though I understand your reasoning as to why you call devops etc fraud, these developers are under a huge amount of pressure from the business side of things to "just make it work TM".
    - SFjulie1 11y ago
      The chain is as strong as every links in it. Professionals knowing their jobs have a responsability. Manager sux bigger because they have bigger authority, devs sux because they are supposed to have the knowledge.
    - crpatino 11y ago
      But you are conceding the point, aren't you? It does not matter if you do the wrong thing because you are an incompetent hack or because you are a low status pawn that got cornered by management into choosing the least worse of a bunch of bad options. The fact remains that a weak solution was implemented, by you, and that it is a matter of time before your employer and their customers suffer the consequences. I'd like to believe that if we were like doctors and our managers came up with some incredibly stupid idea like "let's save cost by reusing hypodermic needles", we could simply refuse to work and force the penny pinchers to back off. But the cynic in me tells me that doctors have to fight every single day to fend off a parade of equally misguided (though not recognizable as such by the public) ideas, and that more often than not, they end up choosing to keep their own families fed and clothed over the theoretical Hippocratic Oath.
tptacek 11y ago
This is a pretty silly analysis. C is categorically less secure than Java. Almost every "rule" SEI CERT has for Java either applies directly to C, or is mooted by C's fundamental insecurity. For an instance of the former case, take SQL Injection: SEI CERT dings Java because it provides libraries that enable SQL injection. C doesn't provide any such libraries --- because it doesn't provide SQL libraries at all! But rest assured that if you bring SQL into your C application through, for instance, the SQLite library, you're inheriting the same set of concerns. For an example of the latter case, take the Java "privilege" system. SEI CERT dings Java because operating the Java privilege system is fiddly, and if you do it wrong you're exposed to privilege escalation. You're not exposed to privilege escalation in C --- because all C code is privileged! This is about the level of pointy-haired boss analysis that I've come to expect from CERT.
- wsxcde 11y ago
  > Almost every "rule" SEI CERT has for Java either applies directly to C, or is mooted by C's fundamental insecurity. Did you read the article? That is precisely what it says: > The preceding analysis demonstrates that all of the high-severity Java rules also apply to C code, except for those in Java's biggest category, which is internal privilege escalation (IPE). C has no possibility of IPE because C lacks an internal privilege model. We also note that C's biggest security category is memory corruption, which does not affect Java code. The article ends with: > If you are writing unprivileged code, therefore, you have many fewer rules to worry about in Java than you do in C. Consequently, this table strongly hints that Java is more secure than C. In fact, as we showed earlier, all nine of the remaining high-severity Java rules also apply to C, which provides more rigorous support for our hypothesis.
  - tptacek 11y ago
    I did read the article, carefully. Notice the "if you are writing unprivileged code" predicate on that paragraph. First, what do they mean, "if"? It's not 1998 anymore, and nobody is writing Java applets. But more importantly, the question doesn't even make sense in context, because you can't ask it if you're comparing C and Java. IF you are considering C for your project, THEN you are writing unprivileged code one way or the other. Java is categorically more secure than C. Notice how the article doesn't open with that statement? I did too, and so now I'm going to rant about how bad the article is.
snarfy 11y ago
Security is a systems property, not a property of a language.
- eranation 11y ago
  Well not exactly See the modula 3 based research operating systems that solve some of the modularity / performance / security trade off triangle issues of a micro kernel
- kabdib 11y ago
  It's incredibly easy to write buffer overruns in C that open up security holes. Not that JVMs are immune, it's just harder. That said, I far prefer writing in C/C++ to doing anything in Java.
  - throwaway13337 11y ago
    >That said, I far prefer writing in C/C++ to doing anything in Java. Why's that? Enjoy pointer arithmetic that much?
    - kabdib 11y ago
      Never found pointer arithmetic hard. I honestly don't know what the big deal is. Template metaprogramming can go straight to hell, though . . . :0
- nickpsecurity 11y ago
  A system's security comes from the security of its components and their interactions. The functionality of each will be expressed in a language. That language will have features that affect the security of that component. Therefore, security is a component of languages and systems. I'll go further to say language security is a subset or component of securing a system wherever it could be applied. This has been known since at least MULTIC's where the choice of PL/0 dodged some security vulnerabilities due to language's attributes. It's been known for reliability at least since Burroughs used ALGOL variant for their OS.
carsongross 11y ago
A bit OT, and perhaps I've been lulled into complacency, but beyond basic bounds-checking I don't think an ideal VM should do much security management at all: I would do away with the java security manager and push all higher level security considerations to the compiler. Sometimes when I'm larping with the gosu team we talk about an ideal VM with: > A minimum of primitive data types (int64, fp64, etc.) > A minimum of security management (bounds checks, etc.) > No method overloading (making bytecode much simpler: no bridge methods, etc.) > Stack based like the JVM This would be a dream to target as a language developer.
- redahs 11y ago
  How would your ideal VM handle input-output? Sending data to GPU, network card, sound chip, etc.
  - carsongross 11y ago
    I don't know if that's something I would handle at the VM level, probably rather an API on top of a native call mechanism in the core library. I suppose if there is enough similarity across I/O then perhaps something could be added. I'm not familiar enough with the state of low level programming to know, and I'd lean towards minimalism unless there was a compelling reason not to. What do you think?
    - redahs 11y ago
      One option would be to provide all IO operations as high level plugins or 'virtual drivers' provided by the platform runtime, similar to how one might install and configure plugins for all of the input and output plugins for video game system emulators. What the VM would provide in a centralized manner would be a repository mapping API names to public header files. This way, if a developer distributed a program over the internet imported a reference to 'simple-video.01' API, the end user and VM could lookup the name and pull a copy of the header API defining the calling convention directly from the VM website. In order to run the program, they could then either find or write a 'native plugin' for their platform which implemented 'simple-video.01' API using machine code similar to a C shared object. Or, they could find or write a 'soft plugin' which translates the calls in the 'simple-video.01' API into calls to another API which their was machine code for (say, 'direct-video.51') using VM bytecode. This way the VM could automatically infer the native code necessary to generate effects, even if it was less efficient or qualitatively different depending on the needs of the end user. For output, the headers would basically need to specify a list of tuples of primitive data types for effects. For input, the headers could perhaps specify a set of named primitive tuples, arrays, and tables which vary over time and can be directly accessed, similar to how one might access pipelined input variables in an OpenGL or Direct3D GPU shader.
neoCrimeLabs 11y ago
Java, just the language,is absolutely more secure. Just be careful what you're using in the JRE else you might negate that gained security[1]. Of course so many C libraries have vulns too, just not included in one commonly used package that runs on every operating system it supports. [1] - https://www.cvedetails.com/vulnerability-list.php?vendor_id=93&product_id=19117&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=7&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=208&sha=dc2bd354d0ef968392f7bac5811742745c04e811 https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
- pjmlp 11y ago
  All languages allow to write code with vulnerabilities. Memory safe ones have logical programming errors and possible runtime issues, which is Java's case. C just adds memory corruption to the set of issues one has to worry about.
  - nickpsecurity 11y ago
    "C just adds memory corruption to the set of issues one has to worry about." That's a very casual way to say that C adds an entire class of errors that lets attackers own your machine with the slightest mistake in the most common coding situations. Memory safety is such a huge increase in security over C that it isn't even funny that people use C where not necessary. Type-safety plus good type system gets a start on knocking out data and interface errors. Type systems with context, or just Design-by-Contract, can knock out more interface errors. So, a good type system, type safety, and memory safety should be the baseline for reliable or secure systems. C tosses out the whole baseline in exchange for... running a bit faster or lazy programmers? Note: I'm talking in general rather than building on existing C projects, where using C makes some sense.
    - pjmlp 11y ago
      Yeah, I should have let the "just" out. There are a whole class of errors caused by C's memory corruption "feature" that I can happily live without. C tosses safety away, because its designers were lazy to implement a proper compiler given what the computing world was doing outside AT&T. Bjarne wasn't also quite found of it, but he had to compromise to get adoption, given his employer. https://www.youtube.com/watch?v=ZO0PXYMVGSU https://www.youtube.com/watch?v=ZO0PXYMVGSU
ColinWright 11y ago
Lovely ... Secure Connection Failed The connection to the server was reset while the page was loading. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the web site owners to inform them of this problem.
- nickpsecurity 11y ago
  I wonder if there was a CERT rule for that.
edko 11y ago
The question seems a bit trivial to me. With Java, you can create a binary file with any content and then execute it. So, in theory, you could replicate the executable code of any C program.
rhabarba 11y ago
Leaving the horrible security of the Java Runtime aside, I highly doubt that there is such a thing like "insecure programming languages". There is "insecure programming" though.
nickpsecurity 11y ago
This article is coming at it from entirely the wrong way. Counting rules is not how you assess language security. We already had language security assessments back in the 80's-90's with proper methodology that taught us more useful stuff. They had basically two approaches: systematic analysis of language attributes on specific types of defects or vulnerabilies; empirical analysis of defect or vulnerability rates on real-world projects with comparisons on languages. The author or another party should apply one or both of those to modern versions of the language to assess real risk. Then, apply analysis of any coding guidelines to see what they counter and what effort is required as productivity is important criteria. On the other hand, this analysis tells us about nothing useful except that there's rules, the rules have claimed benefits, rules here vs there, and a recommendation based on that. Ignores too many real-world concerns. Waste of time.
faragon 11y ago
In many cases, yes. In some cases, not.

74 points by rwbhn 11y ago

If you are writing Java code to manage unprivileged Java code (such as an applet container), you are subject to about as many severe rules as if you are writing C code. If your Java code is itself unprivileged, however, or if you are ignoring Java's privilege model, you are subject to far fewer high-severity rules than if you program in C. Is the main thrust of this article.

SFjulie1 11y ago
Accessing resources on a system requires privileges. So java is inherently more insecure than C, because java developers are not aware that every time they access a socket, authentication, a file, ram they need privileges. And they tweak whatever policies and rules of the OS to do so. Yes : the problem is not the java dev but the sysadmins... Sysadmins says no it is unsecure, so companies say let's hire clueless devs call them devops and handle the delicate problem of secured access to resources by telling them: make it possible. It is not by hiding dust under the carpet, moving the problem to another place (from code to containers) and creating new "paradigms" to hide the inherent complexity of coding that situation will improve. in 2015 we are still lacking of able developers and every technic to work around the scarcity of really able developers are a failure and adding noise. Software is as good as the lowest "software" IQ of the member of the crowd building it -managers included-. Our managers are clueless, most our devs/devops/sysadmins are frauds.
- cows_i_have 11y ago
  Though I understand your reasoning as to why you call devops etc fraud, these developers are under a huge amount of pressure from the business side of things to "just make it work TM".
  - SFjulie1 11y ago
    The chain is as strong as every links in it. Professionals knowing their jobs have a responsability. Manager sux bigger because they have bigger authority, devs sux because they are supposed to have the knowledge.
  - crpatino 11y ago
    But you are conceding the point, aren't you? It does not matter if you do the wrong thing because you are an incompetent hack or because you are a low status pawn that got cornered by management into choosing the least worse of a bunch of bad options. The fact remains that a weak solution was implemented, by you, and that it is a matter of time before your employer and their customers suffer the consequences. I'd like to believe that if we were like doctors and our managers came up with some incredibly stupid idea like "let's save cost by reusing hypodermic needles", we could simply refuse to work and force the penny pinchers to back off. But the cynic in me tells me that doctors have to fight every single day to fend off a parade of equally misguided (though not recognizable as such by the public) ideas, and that more often than not, they end up choosing to keep their own families fed and clothed over the theoretical Hippocratic Oath.

tptacek 11y ago

This is a pretty silly analysis. C is categorically less secure than Java. Almost every "rule" SEI CERT has for Java either applies directly to C, or is mooted by C's fundamental insecurity. For an instance of the former case, take SQL Injection: SEI CERT dings Java because it provides libraries that enable SQL injection. C doesn't provide any such libraries --- because it doesn't provide SQL libraries at all! But rest assured that if you bring SQL into your C application through, for instance, the SQLite library, you're inheriting the same set of concerns. For an example of the latter case, take the Java "privilege" system. SEI CERT dings Java because operating the Java privilege system is fiddly, and if you do it wrong you're exposed to privilege escalation. You're not exposed to privilege escalation in C --- because all C code is privileged! This is about the level of pointy-haired boss analysis that I've come to expect from CERT.

wsxcde 11y ago
> Almost every "rule" SEI CERT has for Java either applies directly to C, or is mooted by C's fundamental insecurity. Did you read the article? That is precisely what it says: > The preceding analysis demonstrates that all of the high-severity Java rules also apply to C code, except for those in Java's biggest category, which is internal privilege escalation (IPE). C has no possibility of IPE because C lacks an internal privilege model. We also note that C's biggest security category is memory corruption, which does not affect Java code. The article ends with: > If you are writing unprivileged code, therefore, you have many fewer rules to worry about in Java than you do in C. Consequently, this table strongly hints that Java is more secure than C. In fact, as we showed earlier, all nine of the remaining high-severity Java rules also apply to C, which provides more rigorous support for our hypothesis.
- tptacek 11y ago
  I did read the article, carefully. Notice the "if you are writing unprivileged code" predicate on that paragraph. First, what do they mean, "if"? It's not 1998 anymore, and nobody is writing Java applets. But more importantly, the question doesn't even make sense in context, because you can't ask it if you're comparing C and Java. IF you are considering C for your project, THEN you are writing unprivileged code one way or the other. Java is categorically more secure than C. Notice how the article doesn't open with that statement? I did too, and so now I'm going to rant about how bad the article is.

snarfy 11y ago

Security is a systems property, not a property of a language.

eranation 11y ago
Well not exactly See the modula 3 based research operating systems that solve some of the modularity / performance / security trade off triangle issues of a micro kernel
kabdib 11y ago
It's incredibly easy to write buffer overruns in C that open up security holes. Not that JVMs are immune, it's just harder. That said, I far prefer writing in C/C++ to doing anything in Java.
- throwaway13337 11y ago
  >That said, I far prefer writing in C/C++ to doing anything in Java. Why's that? Enjoy pointer arithmetic that much?
  - kabdib 11y ago
    Never found pointer arithmetic hard. I honestly don't know what the big deal is. Template metaprogramming can go straight to hell, though . . . :0
nickpsecurity 11y ago
A system's security comes from the security of its components and their interactions. The functionality of each will be expressed in a language. That language will have features that affect the security of that component. Therefore, security is a component of languages and systems. I'll go further to say language security is a subset or component of securing a system wherever it could be applied. This has been known since at least MULTIC's where the choice of PL/0 dodged some security vulnerabilities due to language's attributes. It's been known for reliability at least since Burroughs used ALGOL variant for their OS.

carsongross 11y ago

A bit OT, and perhaps I've been lulled into complacency, but beyond basic bounds-checking I don't think an ideal VM should do much security management at all: I would do away with the java security manager and push all higher level security considerations to the compiler. Sometimes when I'm larping with the gosu team we talk about an ideal VM with: > A minimum of primitive data types (int64, fp64, etc.) > A minimum of security management (bounds checks, etc.) > No method overloading (making bytecode much simpler: no bridge methods, etc.) > Stack based like the JVM This would be a dream to target as a language developer.

redahs 11y ago
How would your ideal VM handle input-output? Sending data to GPU, network card, sound chip, etc.
- carsongross 11y ago
  I don't know if that's something I would handle at the VM level, probably rather an API on top of a native call mechanism in the core library. I suppose if there is enough similarity across I/O then perhaps something could be added. I'm not familiar enough with the state of low level programming to know, and I'd lean towards minimalism unless there was a compelling reason not to. What do you think?
  - redahs 11y ago
    One option would be to provide all IO operations as high level plugins or 'virtual drivers' provided by the platform runtime, similar to how one might install and configure plugins for all of the input and output plugins for video game system emulators. What the VM would provide in a centralized manner would be a repository mapping API names to public header files. This way, if a developer distributed a program over the internet imported a reference to 'simple-video.01' API, the end user and VM could lookup the name and pull a copy of the header API defining the calling convention directly from the VM website. In order to run the program, they could then either find or write a 'native plugin' for their platform which implemented 'simple-video.01' API using machine code similar to a C shared object. Or, they could find or write a 'soft plugin' which translates the calls in the 'simple-video.01' API into calls to another API which their was machine code for (say, 'direct-video.51') using VM bytecode. This way the VM could automatically infer the native code necessary to generate effects, even if it was less efficient or qualitatively different depending on the needs of the end user. For output, the headers would basically need to specify a list of tuples of primitive data types for effects. For input, the headers could perhaps specify a set of named primitive tuples, arrays, and tables which vary over time and can be directly accessed, similar to how one might access pipelined input variables in an OpenGL or Direct3D GPU shader.

neoCrimeLabs 11y ago

Java, just the language,is absolutely more secure. Just be careful what you're using in the JRE else you might negate that gained security[1]. Of course so many C libraries have vulns too, just not included in one commonly used package that runs on every operating system it supports. [1] - https://www.cvedetails.com/vulnerability-list.php?vendor_id=93&product_id=19117&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=7&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=208&sha=dc2bd354d0ef968392f7bac5811742745c04e811 https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

pjmlp 11y ago
All languages allow to write code with vulnerabilities. Memory safe ones have logical programming errors and possible runtime issues, which is Java's case. C just adds memory corruption to the set of issues one has to worry about.
- nickpsecurity 11y ago
  "C just adds memory corruption to the set of issues one has to worry about." That's a very casual way to say that C adds an entire class of errors that lets attackers own your machine with the slightest mistake in the most common coding situations. Memory safety is such a huge increase in security over C that it isn't even funny that people use C where not necessary. Type-safety plus good type system gets a start on knocking out data and interface errors. Type systems with context, or just Design-by-Contract, can knock out more interface errors. So, a good type system, type safety, and memory safety should be the baseline for reliable or secure systems. C tosses out the whole baseline in exchange for... running a bit faster or lazy programmers? Note: I'm talking in general rather than building on existing C projects, where using C makes some sense.
  - pjmlp 11y ago
    Yeah, I should have let the "just" out. There are a whole class of errors caused by C's memory corruption "feature" that I can happily live without. C tosses safety away, because its designers were lazy to implement a proper compiler given what the computing world was doing outside AT&T. Bjarne wasn't also quite found of it, but he had to compromise to get adoption, given his employer. https://www.youtube.com/watch?v=ZO0PXYMVGSU https://www.youtube.com/watch?v=ZO0PXYMVGSU

ColinWright 11y ago

Lovely ... Secure Connection Failed The connection to the server was reset while the page was loading. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the web site owners to inform them of this problem.

nickpsecurity 11y ago
I wonder if there was a CERT rule for that.

edko 11y ago

The question seems a bit trivial to me. With Java, you can create a binary file with any content and then execute it. So, in theory, you could replicate the executable code of any C program.

rhabarba 11y ago

Leaving the horrible security of the Java Runtime aside, I highly doubt that there is such a thing like "insecure programming languages". There is "insecure programming" though.

nickpsecurity 11y ago

This article is coming at it from entirely the wrong way. Counting rules is not how you assess language security. We already had language security assessments back in the 80's-90's with proper methodology that taught us more useful stuff. They had basically two approaches: systematic analysis of language attributes on specific types of defects or vulnerabilies; empirical analysis of defect or vulnerability rates on real-world projects with comparisons on languages. The author or another party should apply one or both of those to modern versions of the language to assess real risk. Then, apply analysis of any coding guidelines to see what they counter and what effort is required as productivity is important criteria. On the other hand, this analysis tells us about nothing useful except that there's rules, the rules have claimed benefits, rules here vs there, and a recommendation based on that. Ignores too many real-world concerns. Waste of time.

faragon 11y ago

In many cases, yes. In some cases, not.