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?"
Except that you can't do pointer math in Java. Java references are opaque and cannot be manipulated.
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.
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.