Slashdot Mirror
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?"
Apparently there will be a port of IBMs stack protector in GCC 4.1. Might be interesting to see how that changes matters.
By design C allows you to access memory at your own descretion. I beleive Java does also (It's been a while), which means neither is a 'secure' programing language. This would be like asking if Fords or Chevys are safer because one uses tig welding and the other uses mig welding. It completely matters on how the code is used. You can write your own memory editor in C (and I beleive Java). Which would make them fundamentally unsecure. C has the advantage that you have to write your own code, so you can make sure it is bug and security flaw free (cha right, and monkeys might fly from my ass!) where as Java comes with libraries. No need to recreate the string. Which saves you tons of dev time, but now you depend on someone else's code review. With that in mind, I'd say Java has a slight edge, just because more people are testing the Java libraries then your custom made objects.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
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.
TFA talks about C being just as secure with protection bits, claiming that use of stack-protection stuff is going to increase programmer and company awareness and willingness to fix bugs. They can fix the bugs, it's going to make it easier, but the inverse is what will happen. Instead of better software coming out, less time is spent on fixing that kind of bugs "since the protector will catch it anyway". Why bother fixing something that doesn't crash the program?
On the other hand, if you convert all these soft errors to hard errors (instead of a program doing something softly off-balance to a rigorous crash) they'll be fixed faster. Yet still, just teach the programmers to program.
Oh, and please do give all books about programming you have left to EA. They appear to be hiring kids between 12 and 16 since they're cheaper, judging by the quality of their software. I can't even run NFS3 in opengl mode since my video card isn't supported... no, the pre-pre-pre-pre-pre-predecessor was.
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.
Isn't the best way to go to program in a language one is experienced in?
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.
For every problem, there is at least one solution that is simple, neat, and wrong.
And C++ doesn't have exceptions and stuff? Java is just as insecure as C/C++. It's just insecure in different ways.
I'd like to see one of those kernel-based systems make a C++ program throw an exception. Well, I guess signalling SIGSEGV kind of counts.
As others have said, most bugs and security flaws come from lazy programmers not doing the right thing.
You say that as if doing proper manual memory management is easy. It's not: that has been sufficiently demonstrated over the past few decades. Since automatic memory management is possible and cheap, it stupid not to use it.
I'd also like to see you run Java in a lightweight embedded DSP situation!
While current Java environments don't optimise for speed (instead relying on fancy JVM's), there's no reason why you couldn't compile Java to efficient machine code.This more pertains to yesterday's article on performance, but it relates to Java in general.
I see lots of articles saying how garbage collection prevents memory leaks and provides security improvements. That is a slight misunderstanding: The automatic memory management is what makes it secure, not the garbage collection. The garbage collector is merely HOW the memory is freed. If Java eliminated the garbage collector and freed the memory immediately the language would be equally secure. What matters is that you don't have access to pointers.
For example, take Visual Basic 6: This language does not have garbage collection, but it is about as safe as Java. It frees memory/objects that aren't used, uses bounds checking, doesn't allow bad casts, and doesn't use pointers. The only time VB6 is a problem is when you call an outside library (which is the same problem you have in Java). So it isn't the garbage collector that matters.
Inherently, a language with access to pointers is always going to be less secure than a language that does not have them, and uses automatic memory management. None of the security enhancements to the compiler can change code that assigns a pointer to the wrong object and overwrites the memory for it. None of them can prevent a bad cast from screwing things up.
Stack protection really is the next big step and like ports from WIndows typically the difficulties is broken code that is just allowed. Stack protection is going to cost developers dearly and it is likely that it will be disabled if there is an option rather than paying the cost on the very software that needs it the most.
I have used valgrind on production code that has been working 8 years. I found multiple protections, uninitialised variables in this code. Anyone coding C and not using valgrind in the testing cycle is not using their head.
I switched to Perl because there were no memory allocation problems like this.