Java or C: Is One More Secure?

bluefoxlucid writes "Security has been a hot topic lately, and we've seen everything from changes to how memory is managed to compiler hardening to "secure" programming languages. Java is considered more secure than C in general; but this guy seems to disagree, and thinks hardening the system itself is the way to go. Are we really approaching the problem the wrong way, or is he just insane?"

Comments

Poor article

[ChrisRijk]

The author points out there's some tools and run-time environment features you could use to help secure C/C++ binaries. Nothing new there. Then based on some FUD and hand-waving arguments he predicts that with all these extra bits that C can be made more secure than standard Java.

The thing is though, C is still insecure as standard, while Java is still secure by design (and has shown to be in practice). Not that there's an idiot proof general purpose programing language/environment out there - being "secure by design" doesn't make something 100% secure.

Seems reasonable

[Grab]

The major source of security bugs in C and C++ is lazy programmers.

Our company has an in-house rule - "if it returns an error status, you check it". Why? Because most really nasty bugs arise from failure to check this. If you're lucky, this will just result in unexpected crashes. If you're unlucky, you get buffer overruns and remote code execution.

Why do programmers not check this? I'm convinced it comes down to how you're taught. I went through a good dozen C and C++ tutorials when I was learning them. I've been through a few more since, teaching other people. And I've *never* seen a textbook that includes a check on the results of a malloc() call being NULL. Yes I know the argument is "it'll make the examples harder to read". That's a fair point, in a hello-world program. But by the time you get to using malloc(), you should know enough to handle a little complexity. The books just don't cover it though. Not only do they simplify the examples, but they don't mention that they're simplifying. As a result, it's an issue that too many coders don't realise exists.

If coders get some good mentors at work, to show them how this *should* be done, then fine. But I don't think that happens either - code review is not a way of life for most companies. So they just go their merry way until their code falls over in a heap, and then wonder what to do about it.

Python is generally quicker to write than Java, and Java is generally quicker to write than C++, and C++ is generally quicker to write than C, simply because each step along the line does most of that work for you. But that generally comes at the cost of increased overhead (code size, execution time or both). And even then it's worth knowing what's happening underneath, because if you don't then it *will* bite you sometime. Neither of these is more secure than the other though, assuming the coder knows what they're doing.

Grab.

Re:Seems reasonable

[node 3]

The major source of security bugs in C and C++ is lazy programmers.

Why is that whenever a technology is flawed or otherwise lacking, the blame is put on the end user?

It makes me think that in a debate over the merits of putting a safety on a gun, these same people would say it makes the gun unnecessarily complex, expensive, prone to failure and just plain gets in the way when you really, really need that extra bit of performance, and besides, anyone who accidentally shoots themselves (or someone else) with a gun is an idiot in the first place.

The fact is that there is a security issue which *can* be fixed by each individual programmer, which both reality and the normal distribution curve demonstrate won't be universal, or can be fixed by the compiler, which will work 100% of the time that option is used (assuming the compiler implements the feature properly).

So, given the security issue exists, which solution is more likely to take hold: better (and more time consuming) programming practices will spread 'cross the land, or a compiler feature will fix the problem across the board?

Sure, it would be nice if programmers (and everyone, really) did their jobs "better", but it's foolish to expect it. It's better to fix the system itself because not only will it eliminate the problem, it will save the programmer from an unnecessary tedium, giving them more time to devote to actual features and other improvements.

Re:Seems reasonable

[moro_666]

i agree, each language is as secure as the developer coding style is. java is forcing on the check of error conditions with exceptions, you need the try{}catch(){} blocks, so does python. but C doesnt really care if you even check the return value of your malloc (this probably the most common bug around :D). C leaves a lot up to the programmer (Java arrays always know their length by themselves for example).

For an average young programmer, making mistakes in C is alot easier than to do mistakes in Java. But this still doesnt make java/python/ really secure, the virtual machine executing the code can still make mistakes.

If you want to have a secore application use common sense and good planning with enough foresight. I guess that more than 50% of all the bugs come from dirty add-ons and quick-hacks to make smth work. Stuff that is written in a rush and without long planning, often backfires, and sometimes in places where none notices it until it's too late.

The author of TFA howeves is totally incompetent on the security manager theme as it seems. Java can have very very very many restrictive security measures applied that makes it basically unable to do much from the byte code (deny filesystem access, network access, classloader access etc.), whereas unless you override the standard C calls with a preload, the C application is prone to all kinds of mistakes all over the place. If in doubt, check the java security api before "bashing" back on this one.

Btw. has slashdot really nothing better to do that to publish these bashing articles like this ? Java and C aren't really comparable in very very many ways. It's a lot better than comparing php and java ofcourse, but still, it's an unfair comparisment. C can do stuff that java can't do (interrupts to devices, all kind of low-level stuff), java can do stuff that C can't do (execute the same bytecode on different architectures and machines and operating systems). Nobody really wants to implement a big banking website in C and nobody wants to write a kernel in Java. The fact that poker and solitaire are both cardgames really gives us no opportunity to compare them just because they both use the same set of cards.

Re:Not applicable

[lexarius]

Except that you can't do pointer math in Java. Java references are opaque and cannot be manipulated.

Here's a hint..

[Improv]

People who can't spell words in the English language like "aggravate" might not be the best people to look for deep and insightful attacks on what everybody else agrees on. I'm not saying that having good spelling would make his point any more valid, but it should at least be a rule of thumb for those who can't bother to think about his point on their own (as the poster of this article can't).

To get more into it, yes, the C runtime is smaller than the Java runtime, and there is a certain trustworthiness in having your code small. However, languages like C where the basic type system requires a lot of care to avoid bugs starts you off considerably behind just having a large runtime. In C, it requires almost no thought at all to write insecure code, and to do some things securely requires chunks of wrapper code around most things involving IO layers, wrapper code that is not program logic and can have bugs. In higher-level languages, the user won't be writing that code -- the engineers at Sun will, and because that code gets exercised by the entire world, its bugs will be found and removed very quickly.

Of course, in both cases, we're not really talking about the language being secure, we're talking about how likely it is that, given equivalent tasks, people using the different languages will end up writing secure code. To weigh that, we all use rules of thumb based on what we know causes errors -- he invokes bulk of code, but doesn't think about how the used code in that bulk will need to be written anyway and will be reused by every Java programmer. As I said before, I think a caveat-emptor type system is another major factor to be considered. Other (generally obvious) rules of thumb that go against this guy are left as an exercise for the reader.