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.
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.
So you check the return value from printf?
From the man page:
These functions return the number of characters printed (not including the trailing `\0' used to end output to strings). snprintf and vsnprintf do not write more than size bytes (including the trailing '\0'), and return -1 if the output was truncated due to this limit. (Thus until glibc 2.0.6. Since glibc 2.1 these functions follow the C99 standard and return the number of characters (excluding the trailing '\0') which would have been written to the final string if enough space had been available.)
/* FUCK - The F-word is here so that you can grep for it */
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.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.