
Is Java more secure than C? - rwbhn
https://insights.sei.cmu.edu/sei_blog/2015/10/is-java-more-secure-than-c.html
======
tptacek
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
> _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
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.

~~~
wsxcde
The article acknowledges that the so-called "IPE rules" only apply to small
subset of libraries. (They don't even apply to applets/servlets because the
libraries which run these things are supposed to handle the isolation here.)

IMO the gist of the article is this:

1\. We came in believing that Java is more secure than C.

2\. So we thought that Java would require fewer secure coding rules.

3\. But it turns out Java has more! What does this mean? Was assumption (1)
wrong or is there something else going on?

4\. Analysis follows.

5\. Our assumption was right, it's just that Java has more stuff than C.

IOW, the point of the article was to refute the strawman, "Java has more
secure coding rules than C, hence it's harder to write secure Java code than
secure C code."

I'm not sure what you expected the article to say but just asserting "Java is
more secure than C" is useless because you just end up preaching to the choir.

~~~
tptacek
I didn't read it that way at all, but agree that an article that effectively
refuted that straw man would be a good thing.

------
neoCrimeLabs
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=...](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)

~~~
pjmlp
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
"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
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)

~~~
nickpsecurity
Thanks for the link. It's all good so long as you keep countering the myth of
C having good design like you did here [1] and I backed you up on here [2].
Their house of cards (i.e. ideology) will come down easier as we continue kick
its foundation out from underneath. ;)

Far as resource constraints, there's been interesting work along those lines,
too. I mean, we have obvious Modula-2/Lilith project. However, it was cool
that a recent project used ATS language to program an 8-bit microcontroller.
That's on top of safe ASM, embedded DSL's like Ivory language, and stuff like
Cyclone. C proponents' excuses for its design advantages are getting thin,
thin, thin...

[1]
[https://news.ycombinator.com/item?id=10268614](https://news.ycombinator.com/item?id=10268614)

[2]
[https://news.ycombinator.com/item?id=10273656](https://news.ycombinator.com/item?id=10273656)

~~~
pjmlp
There is some interesting content here regarding how older languages were
ignored in the process.

History and Spirit of C and C++ @ NDC 2015

[https://vimeo.com/132192250](https://vimeo.com/132192250)

~~~
nickpsecurity
Finished. Was a pretty good video. I did a write-up of it below on Schneier's
blog to justify eliminating C because it's provably Bad by Design. All due to
limitations of the PDP's and, new to me, the EDSAC. Also more of a rip-off of
BCPL than I thought before.

[https://www.schneier.com/blog/archives/2015/10/friday_squid_...](https://www.schneier.com/blog/archives/2015/10/friday_squid_bl_497.html#c6708072)

~~~
pjmlp
Very good write-up. Sadly I can only up-vote once.

------
vezzy-fnord

       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
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
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".

~~~
crpatino
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.

------
carsongross
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
How would your ideal VM handle input-output? Sending data to GPU, network
card, sound chip, etc.

~~~
carsongross
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
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.

------
nickpsecurity
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.

------
ColinWright
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
I wonder if there was a CERT rule for that.

------
rhabarba
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.

------
edko
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.

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

~~~
kabdib
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
>That said, I far prefer writing in C/C++ to doing anything in Java.

Why's that? Enjoy pointer arithmetic that much?

~~~
kabdib
Never found pointer arithmetic hard. I honestly don't know what the big deal
is.

Template metaprogramming can go straight to hell, though . . . :0

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

