Java or C: Is One More Secure? 85
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?"
C stack protection might help (Score:2, Informative)
valgrind rocks (Score:4, Informative)
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.
Re:valgrind rocks (Score:1, Interesting)
The fact that you were using C to solve a problem that apparently could have been solved in Perl suggests a problem right there.
C has its uses when you have particular requirements.
Hunh? Does Java even have gets()? (Score:2)
AFAIK, Java is considered a "strongly typed" language, so even if there is a gets(), it has an implied length.
Re:Hunh? Does Java even have gets()? (Score:2)
Not applicable (Score:2, Interesting)
Re:Not applicable (Score:3, Funny)
Sounds like it's not so much a matter of how *long* it's been since you had the one course in Java you were required to take to graduate, but rather how much attention you paid while you were there.
Re:Not applicable (Score:2)
Re:Not applicable (Score:5, Informative)
Re:Not applicable (Score:2)
Thanks
Re:Not applicable (Score:2)
Java prog
Re:Not applicable (Score:2)
Compression code is also simpler with pointer math, since you can incriment through an array by incrementing it (int_array++); this oddly steps though by whatever the size of the base type is, instead of 1 byte. Various things are simpler with pointer math, oddly.
Of course, you always have the option of writing something in C that lets you call functions that set up your objects (structures, linked lists, etc) in memory and decide if it's time to free them. The argument here seems to typically be, "O
Re:Not applicable (Score:3, Funny)
Then maybe you should consider posting only about things you actually do remeber. The set of languages that can be used for malicious resaons includes English.
Re:Not applicable (Score:2)
-Ric
Re:Not applicable (Score:3, Funny)
In point of fact Java architecture contributes significantly to making it easier to write secure applications (as it also improves reliability); hand-waving that "bad stuff can happen in either language" is semantically null.
You *can* crash *any* car, but, by design, some are clearly safer than others.
Re:Not applicable (Score:2)
I agree completely. I'm a
A Java app will come with all of the inherant securi
Re:Not applicable (Score:2)
"A C++ app can be just as secure if coded correctly" says nothing; all cars are safe "if you drive correctly". What's "more secure" is probably more secure because it was *easier
Re:Not applicable (Score:2)
Very true. No matter which language you write in, you will likely be at the trust of some other code provider.
"Calling a virtual machine an "emulator-like environment" is kind of silly; modern JVMs perform dynamic optimizations that bear little resemblence to what an emulator typically does."
The JVM and
Re:Not applicable (Score:2)
That definition even includes compilers. "Emulation" specifically means to program one system to *imitate* the behavior of another, with the strong implication of a loss of efficiency. Not all interpretive execution environments are emulators, or even "emulator-like". And large chunks of modern JVMs
Re:Not applicable (Score:2)
My Tons of crap list wasn't to impress, it was to show that I am not a 'Microsoft fanboi.' In that I will use which ever tool best fits the need of the situation in context. Whether its Java,
"Today, assuming that because something wasn't coded in Java means it
Re:Not applicable (Score:2)
Re:Not applicable (Score:2)
Re:Not applicable (Score:2)
There are several OSS Java VMs. (Kaffe, IKVM, Jikes RVM, etc.)
Python is one of my favorite languages, but from a security standpoint, dynamic typing introduces a whole class of errors and makes code audits more difficult. Sure, one could introduce manual type checks at the beginnings of methods and raise TypeErrors, as well as checking returned types. However, the more correctness (security is a subset of corr
Poor article (Score:5, Insightful)
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.
Apples and ! Apples (Score:2)
Lots of FUD and hand-waving here as the author compares the JVM to a C application, and implies that (1) the C runtime is bug-free and/or any C application can avoid C runtime bugs; and (2) all programmers can make their C programs more bug-free than a JVM.
A better comparison would be the C compiler, runtime and autom
Re:Apples and ! Apples (Score:2)
Lots of FUD and hand-waving here as the author compares the JVM to a C application, and implies that (1) the C runtime is bug-free and/or any C application can avoid C runtime bugs; and (2) all programmers can make their C programs more bug-free than a JVM.
As opposed to Java fud and hand-waving, or .NET fud-- . . . ok so .NET doesn't really have an army of stormtroopers saying it's the next generation solution to everything, aside from microsoft mumbling something along those lines to itself once in a
Re:Apples and ! Apples (Score:2)
I think you misunderstand the grandparent. The grandparent's point is that the C "Error kernel" includes the compiler, while for the most part the Java class loader will catch Java compiler bugs.
The array bounds checking in mos
Re:Apples and ! Apples (Score:2)
On the topic of smashing the stack in C, it is implemented in exactly one place that a stack smash in any C function results in the program outputting the name of the function whose stack frame holds the physical array, then terminating. This is close but not exactly bounds checking. It is also a specific compiler extension that's finally being merged with gcc.
The article was about C programs in such an environment, which also supplied a secure heap manager; data/code separation; and address space ra
Re:Poor article (Score:2)
Sounds like he would be better off trying to compare C vs Perl or the infamous flamebait article of Java vs Perl.
Perl, when used without the Taint option has the potential be be insecure. However, you can readily so secure programs without using Taint. Perhaps the best I can really state is Secure Enough
Perl, when used with the Tain option, is a complete pain in the butt to work with an very secure. It's very difficult to do anything particularly stupid unless you work at it. But properly treated, it
Re:Poor article (Score:1)
False. Java can protect you from a large class of possible exploit vectors (buffer overflow, off-by-one, etc), but programs written in Java are still vulnerable to other classes of exploits. SQL injection, cross-site scripting, information leakage, and certain types of privilege escalation are all still possible in Java programs. Despite some of the common refrains here, Java can not make a bad programmer into a good one, and a bad progra
He is insane. (Score:2, Interesting)
On the other hand, if you convert all these s
No, I think he's right (Score:2)
fixed is because in the hardened environment, these bugs
result in crashes rather than transient misbehavior. These
types of bugs will be much easier to detect and fix since
they will no longer be hard to reproduce.
Sounds reasonable to me. In my experience, no bug is hard
to find and fix if it is easy to reproduce.
Seems reasonable (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:1)
because technology itself is useless. it requires a user to get any use out of technology.
whether that user is another programmer (in the case where a programming language is the product), or if it is a normal joe-blow dude who doesn't really know what he's doing: until someone does something with a computer, its useless. the only significance feasible is that attributed to it through actual use
Re:Seems reasonable (Score:2)
I really don't mind people using code that has built-in error-trapping. If you're using OO code anyway, then by all means use CString and don't worry about how much array is needed underneath the OO abstraction - after all, that's why you use OO. But you're trading that off against the performance hit. And at some point you'r
Re:Seems reasonable (Score:1)
What you are saying is the same thing that happened to the web. IE "fixes" a lot of errors in HTML and the programmers thought that because the renedered page was "correct" their code was good. Like it or not Netscape 4.x did one thing well, it told you if your table structures were correct because it didn't try to work around the bad code.
You suggestion of having the compiler fix the problem instead of the programmer becomming better is going down the same road. If I'm writing ANSI C code and want
Re:Seems reasonable (Score:2)
You suggestion of having the compiler fix the problem instead of the programmer becomming better is going down the same road.
The article points out changes to the compiler and operating system that cause bugs in programs to force a crash, which is like Netscape refusing to render a page at all rather than rendering it incorrectly. Of course, Firefox behaves this way with XML; it gives you a line number and a statement and says, "I don't get this. You broke something. Fix it now." Then you go, "OH!
Re:Seems reasonable (Score:2)
I've met a lot less lazy programmers than I have time-strapped programmers. Every hour not spent managing mallocs and making sure you're not returning stack variables, or verifying that string tests are bounded or x y z you have to do to make sure you C program is safe, that's time you could spend being productive.
Making code safe is not "being productive". You are not meeting customer requirements by making your software secure--security is assumed. If you ca
Re:Seems reasonable (Score:2)
More than once I've seen someone take a gun, unload it, turn the safety on, then pull the trigger - the gun fired! In the first case the idiot didn't know how to use that gun, so he unloaded the chamber then loaded it from the magazine when he closed the chamber, then he misunderstood the safety and turned if off instead of on. The second case the guy was pretty sure something was wrong before he did this test. In both cases the safety mechanism was worthless, but fortunately both people were using goo
Re:Seems reasonable (Score:2)
Re:Seems reasonable (Score:2, Informative)
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 th
Re:Seems reasonable (Score:2)
So if printf truncating could lead to an error, I check it.
Our "bug-of-the-day" intranet page contains a permanent link to "the bug from hell", where one of our most senior engineers ignored a return value (and the coding standard which mandated the check), and left himself open to a very nasty intermittent and hardware-specific bug, which took something like 4 man-weeks to find. As an object lesson in *why* you want coding standards, it serves its purpose...
Grab.
Re:Seems reasonable (Score:2)
Given the state of development processes and what customers are willing to pay for software I'd say the more likely source is programmer burnout adn crappy design practices.
Re:Seems reasonable (Score:5, Insightful)
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:Seems reasonable (Score:2)
Re:Seems reasonable (Score:1)
Re:Seems reasonable (Score:2)
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.
Using the built-in security API in Java is probably a lot easier than writing an SELinux policy; although potentially a distribution maintainer or software maintainer coul
Re:Seems reasonable (Score:2)
Presumably this is less of an issue for C++ since you have exception handling. But if you were writing a web server in C or C++ how could you garuntee that the entire web server wouldn't crash when a developer imported code which caused a CORE dump.
Re:Seems reasonable (Score:2)
The worst thing, I think, is that C doesn't provide a good place to implement "clean up" code, like C++ does (in de
Re:Seems reasonable (Score:2)
On Linux, checking whether malloc() returned NULL is a waste of time. Because Linux overcommits memory and tries to allocate the backing pages lazily, malloc() might return a pointer to memory that is not backed by real pages. When your code eventually uses that memory, Linux now can't find enough pages, so your app crashes. malloc() returned a non-NULL pointer, but you were OOM anyways.
Re:Seems reasonable (Score:2)
No? You're fired.
Yes? You're a freak.
Good day.
Re:Seems reasonable (Score:2)
Stupid troll. (Score:1)
I'm no fan of Java, but at least it gives your program a chance to recover (exceptions and stuff).
Re:Stupid troll. (Score:2)
I'm no fan of Java, but at least it gives your program a chance to recover (exceptions and stuff).
And C++ doesn't have exceptions and stuff? Java is just as insecure as C/C++. It's just insecure in different ways.
As others have said, most bugs and security flaws come from lazy programmers not doing the right thing.
I'd also like to see you run Java in a lightweight embedded DSP situation!
Re:Stupid troll. (Score:3, Informative)
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. Sinc
Re:Stupid troll. (Score:2)
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.
Segmentation fault isn't an exception. But to the heart of the issue, you wouldn't be able to recover. Your stack or heap would contain corrupted memory. In other words, it's like you have a map, and I set fire to it, burn up half of it and you put it out. Now at this point you either try to follow the half-burned map; or go home, get another one, start over. If
Re:Stupid troll. (Score:2)
Knowledge (Score:4, Insightful)
Here's a hint.. (Score:5, Informative)
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.
Re:Here's a hint.. (Score:2)
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.
The source code to the Sun VM is closed source, isn't it? That right there tends
Re:Here's a hint.. (Score:2)
Re:Here's a hint.. (Score:1)
Well, that answers that. I guess the two are fairly close to identical in terms of security.
Re:Here's a hint.. (Score:1)
Well, this is true of any language. Just think of Perl: buffer overflows are impossible, since strings and arrays grow when needed. People still manage to write swaths of code with shell or SQL injection vulnerabilities, despite taint checking. Piling language features onto each other to make a factory for secure programs will always be an uphill battle. What is really needed are competent programmers (which are in pitifully short supply).
Re:Here's a hint.. (Score:2)
Although it's an uphill battle to make the language help programmers avoid insecure code, it's an uphill battle worth facing. Progress in doing so is important progress to make, even if it is very hard. Even very competent programmers sometimes make mistakes, and I'd wager they happen more often in languages that don't help them. Having good tools is always a good thing -- I, for example, find programming without vim and all my customizations to it to be extremely irritating.
As for
Re:Here's a hint.. (Score:1)
To make code secure, a language that makes Doing The Right Thing easy is needed, not a language that makes doing some specific wrong things hard or impossible. And that is wrong with Java, it doesn't make anything easy, it only eliminates wild poi
Re:Here's a hint.. (Score:2)
Further, I would say that Java indeed makes a lot of things easy that are harder in C. It provides much more capable classes with a number of very useful operations on them. Also, strings don't suck, and collections are safer than arrays. Java makes memory management much simpler. If you look at Java and don't see any of these things, I think you've somehow
Garbage Collection Misunderstood (Score:3, Interesting)
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.
Re:Garbage Collection Misunderstood (Score:2)
I see this error a lot, and it's slightly annoying. You're treating pointers as if they all behave like C-style pointers, which isn't correct.
Ja
yes (Score:2)
Infrastructure is a different matter. That too will become the domain of java like languages in the future but for the moment we will need to
Here's the problem (Score:2)
C++ CAN be made more secure of course but it's the programmer's job not the compiler's job to keep it secure. You want to compare security? You need to start with the core C++ stuff and the core java stuff, the stuff that is in every version of it. This of course gives Java the advantage beca
Reply from a language-based security zealot... (Score:2)
Re:Reply from a language-based security zealot... (Score:2)
For one thing, unless I am mistaken, C running with these protections does not provide array bounds checking, unless the out-of-bounds writes happen to hit certain places identified as dangerous.
ProPolice rearranges local arrays to float character arrays to the top, other arrays below those, then structures, basic types, and pointers. An overflow in an array can screw with another array; it can't screw with the return pointer or stack frame pointer. That is the exact extent of the protection, no more
Vast majority of Java does not rely on native code (Score:2)
I'd have to agree that the notion that doing "useful" things in Java requires that "a vast amount of a complex java application's base code is glue to external C and C++ libraries" is ridiculous. Eclipse is the
Re:Vast majority of Java does not rely on native c (Score:1)
It's all about ease of auditing (Score:2)
With Java, some of the most complicated and historically bug-ridden code is encapsulated in the JVM and re-used by every single program, rather than spread throughout the code, doomed to be reimpleme