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

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.