Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security IT

Java or C: Is One More Secure? 85

Posted by Hemos from the nothing-is-ever-truly-secure dept.
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?"
This discussion has been archived. No new comments can be posted.

Java or C: Is One More Secure? More

Java or C: Is One More Secure?

Comments Filter:
  • Apparently there will be a port of IBMs stack protector in GCC 4.1. Might be interesting to see how that changes matters.

    • valgrind rocks (Score:4, Informative)

      by oo_waratah ( 699830 ) on Monday October 10, 2005 @10:30AM (#13756383)
      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.

      • Re:valgrind rocks (Score:1, Interesting)

        by Anonymous Coward
        I switched to Perl because there were no memory allocation problems like this.

        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.
  • Almost all the exploits in `c` center around the implicit assumption that misbehaviour is tolerated when unexpected input is received. Yes, the stack can be somewhat protected against overflows, but this is a bolt-on.

    AFAIK, Java is considered a "strongly typed" language, so even if there is a gets(), it has an implied length.

  • Not applicable (Score:2, Interesting)

    by RingDev ( 879105 )
    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
    • By design C allows you to access memory at your own descretion. I beleive Java does also (It's been a while)

      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.
      • It's been years, and I can't remember what specific limitations there are. Yes there is the sand box, which would apply at least a basic level of security. But so long as there has been a sand box there have been ways out of it. So even if you can do pointer math in Java you are theoretically limited to the sand box. But realisticly, either language can be used for malicious reasons. -Rick

        • Re:Not applicable (Score:5, Informative)

          by lexarius ( 560925 ) on Monday October 10, 2005 @08:28AM (#13755701)
          Except that you can't do pointer math in Java. Java references are opaque and cannot be manipulated.
          • Please give an example of how this is relevant to the typical programming task that a programmer would see...

            Thanks
            • C programs need pointer math. Among other things, it is how you access dynamically allocated memory chunks, which is done in most programs. It is also used heavily in operating system code. Pointer math is highly useful, but it can lead to all sorts of bad things if pointers point to the wrong places. You certainly don't want some Malicious Person to figure out how to reassign one of your pointers so that it points at some arbitrary place in memory, such as inside of the currently executing code.

              Java prog

              • 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

        • It's been years, and I can't remember what specific limitations there are.

          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.
          • Which is why I specificly noted that I could not garuntee the accuracy of that statement. The issue is that the problem was being approached from a black or white stance. Much like the retarded Linux vs Windows arguements that are had here. What is likely to follow is a bunch of java fanatics and C old schoolers tossing insults back and forth over who's language is better. The point is that either can be better, and either can be worse, it entirely depends on context, design, and the skill of the coder.

            -Ric
            • Ignorance-based relativism doesn't really further the discussion. It's really hard for you to say anything of merit about something you don't understand.

              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.
              • "In point of fact Java architecture contributes significantly to making it easier to write secure applications (as it also improves reliability);"

                I agree completely. I'm a .Net developer, I much prefer using precompiled libraries and an emulator like environment to run my applications. My point being that C/C++ can be just as secure as a Java app if it is coded correctly. The question should not be which is MORE secure, but which is EASIER to secure.

                A Java app will come with all of the inherant securi
                • Erm...the C++ programmer is only "free to fix it" if it's in his code, or code he controls. "Home-built" apps actually do call libraries and the OS too. 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.

                  "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
                  • "the C++ programmer is only "free to fix it" if it's in his code, or code he controls. "Home-built" apps actually do call libraries and the OS too."

                    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 .Net Framework acheive the same thing, the convert
                    • The JVM and .Net Framework acheive the same thing, the convert a common language to native language and run it in a (somewhat) enclosed environment. Call it an emulator, a virtual machine, a sandbox, what ever.

                      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
                    • Ehh, we're arguing symantics over the definition of the JVM/.Net framework.

                      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, .Net, C++, PHP, or what ever. This was intended to rebut your implication that I am some how inferior because at the moment the tool I am using is designed by Microsoft.

                      "Today, assuming that because something wasn't coded in Java means it
                • Or you can use an open source VM (such as in python) and still be able to fix it yourself.
                  • Now that would be a much more interesting debate! Which is better, an open source VM(python/Mono) or closed source VM(Java/.Net) for security? -Rick

                    • Which is better, an open source VM(python/Mono) or closed source VM(Java/.Net) for security?

                      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)

    by ChrisRijk ( 1818 ) on Monday October 10, 2005 @08:16AM (#13755631)
    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.

    • So now, which language is more secure? I still say C, for no other reason than because it's easier to make the system protect itself from broken C programs than broken JVMs or Java applets.

      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

      • 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

        • Wouldn't a buggy JVM that messes up on bounds checking still be able to generate buggy code? Or one that decrements a reference count in the garbage collectory too much, so it hits -1 and gets freed; then later bumps over that again and frees again. Double frees, buffer overflows.

          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

          • 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

    • 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

    • Java is still secure by design (and has shown to be in practice).

      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)

    by dascandy ( 869781 )
    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 s
    • The reason he claims that the bugs are more likely to get
      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)

    by Grab ( 126025 ) on Monday October 10, 2005 @08:21AM (#13755656) Homepage
    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 (Score:5, Insightful)

      by node 3 ( 115640 ) on Monday October 10, 2005 @08:45AM (#13755796)
      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.
      • Why is that whenever a technology is flawed or otherwise lacking, the blame is put on the end user?

        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 ..
      • I suggest you bring that analogy up with US gun owners who are currently being asked to fit handprint recognition to guns. Ask them how practical that is, for how much extra safety.

        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
      • Bull.

        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

        • 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!

      • 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

      • The problem that remains is that the bugs go up the stack. Now instead of a buffer overflow,your application is vulnerable to SQL injection, and XSS and your data is toast anyway.

    • Re:Seems reasonable (Score:2, Informative)

      by laptop006 ( 37721 )
      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 th
      • if it returns an error status, you check it

        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.
    • The major source of security bugs in C and C++ is lazy programmers.

      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)

      by moro_666 ( 414422 ) <kulminaator@gCOB ... m minus language> on Monday October 10, 2005 @09:19AM (#13755984) Homepage
      i agree, each language is as secure as the developer coding style is. java is forcing on the check of error conditions with exceptions, you need the try{}catch(){} blocks, so does python. but C doesnt really care if you even check the return value of your malloc (this probably the most common bug around :D). C leaves a lot up to the programmer (Java arrays always know their length by themselves for example).

      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.

      • 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

    • Difference is in handling 3'rd party libraries.. You have have the most talented C programmers in the world, but if you use a 3'rd party driver that didn't properly check fro null malloc, you're FUBAR.. Especially if you thought you could trust this 3'rd party.

      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.
    • I mostly agree with you, but I also think you're forgetting that a lot of nasty bugs originate from the horrid situation that exists wrt checking for error status in C programs. There's little standardization across libraries as to what constitutes an error indicator. Further, many functions use errno to report errors, and to preserve that mechanism requires throwing re-entrancy out the window.

      The worst thing, I think, is that C doesn't provide a good place to implement "clean up" code, like C++ does (in de

    • 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.
    • Do you check printf calls as well?

      No? You're fired.

      Yes? You're a freak.

      Good day.
  • Yes, fancy tricks as PaX and ProPolice can turn remote root attacks into 'only' a denial of service (your daemon gets killed). That's definitely an improvement.

    I'm no fan of Java, but at least it gives your program a chance to recover (exceptions and stuff).

    • 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)

        by reynaert ( 264437 )

        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

        • 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

        • Agreed, agreed, agreed! Memory management is at the core of every useful program that ever has been or will be written. It absolutely should be automated and invisible to the programmer. Doing your own memory management while writing a program is like buying iron ore and coal and turning it into steel so you can build your own wheels for your car. It's a waste of effort.

  • Knowledge (Score:4, Insightful)

    by GerritHoll ( 70088 ) <gerrit@nl.linux.org> on Monday October 10, 2005 @08:26AM (#13755690) Homepage
    Isn't the best way to go to program in a language one is experienced in?

  • Here's a hint.. (Score:5, Informative)

    by Improv ( 2467 ) <pgunn01@gmail.com> on Monday October 10, 2005 @08:32AM (#13755724) Homepage Journal
    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.

    • 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

      • The source code to Sun's JVM is available - it comes with the JDK as standard in fact. There are some license restrictions that mean it isn't Open Source (tm) compatible though. The main restrictions AFAIK are the compatability requirements - essentially, "thou shalt not embrace and extend" (with products anyway - you can mess around if you want with it internally).
    • In C, it requires almost no thought at all to write insecure code

      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).
      • A few specific comments --

        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
        • You didn't get it, did you? It's not about regexes being *bad*, it's about regexes being *wrong* and by extension insecure, but the *right* solution, context free expressions or something exquivalent, is prohibitively expensive due to the B&D language chosen.

          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
          • Regexes are *wrong*? What does that mean? How are they wrong? I can understand that you might not like them, but can you make the case for anything more?

            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)

    by MobyDisk ( 75490 ) on Monday October 10, 2005 @10:24AM (#13756350) Homepage
    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.

    • 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.

      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)

    by jilles ( 20976 )
    You can't prevent bad/malicious programming of course but you can prevent the vast majority of bugs that are typically exploited by hackers, like buffer overflows or dangling pointers. Java is immune to both these issues. Therefore, Java is a much more secure environment to program in and therefore the use of C/C++ is nearly non existent in the web application domain.

    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
  • This article deals with 3 compilers or systems for C++, NOT C++ in general. sorry, gcc is a C++ compiler, not c++ itself. If I use another compiler those issues will return. And many people do use other systems...

    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
  • First, I am happy to see these stackguard-like systems be integrated into C compilers and runtimes. I think they can go a long way towards solving common security problems, and I am dumbfounded that distributions aren't clamoring to have these installed by default. The only explanation I can think of is this bizarre obsession with performance in the Linux world, as if a few percentage points of performance are worth living in constant fear of being hacked. However, it's not really fair to say that C "has" t

    • 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

  • I can't reply on the blog so I'll reply here:

    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 /exception/ to the rule. Besides Eclipse and Azureus, I don't know of ANY other Java desktop applications that use SWT. Those other 99% are most likely using Swing. That is not to mention the server side, in which it is even more ridiculous to suggest
    • I had a problem with Azureus crashing the OS, it wasn't the Jave it was some brain damaged swt OpenGL JNI code in a plugin, because the idiots insisted on unsafe swt code instead of safe fast well tested Java 3D code, which uses the faster Direct 3D API on windows! So I will never allow that POS swt code and plugin on my PC again!
  • The issue is the number of lines of code (assuming rougly equivalent complexity of lines of code) that must be audited in order to be reasonably sure that your code is free from a certain type of bug. (In some domains, "resonably sure" means "formally proven with full documentation" for certain types of bugs.)

    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

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close