back to article You work so hard on coding improvements... and it's all undone by a buggy component

Nearly all (97 per cent) of Java applications contain at least one component with a known vulnerability, according to a new study by app security firm Veracode. Veracode reports year-over-year improvements in the code organisations write, a positive finding somewhat undone by the increasing proliferation of risk from open …

  1. Gio Ciampa

    Levels of blame...

    1. The developer who wrote the buggy component...

    2. The developer who used a buggy component without checking it...

    3. GOTO 2...

    1. TeeCee Gold badge
      Facepalm

      Re: Levels of blame...

      Actually there's a third one, as illustrated in the timezone / Astrolabe business not too long ago:

      3) The developer reckoning that an amateur run, free service with no guarantees of availibility is entirely adequate to provide the online service his mission-critical shit depends on.

    2. Lee D Silver badge

      Re: Levels of blame...

      What about:

      The system that was designed so that updating one module of a piece of software, reliably, on multiple versions of - say, picking an OS entirely at random, Windows - is non-existent or almost impossible.

      If people could just say "Is this module, a Java module called X, installed, or could you install that for me, please OS, along with its dependencies?" programmatically and have it reliably work cross-platform, that would be some way to a solution.

      Then you can end the static binaries, hard-coding and compiled-in-libraries and literally just say "This software needs OpenSSL, please install it" and then updates to OpenSSL take place for EVERY piece of software that needs to use it.

      But we don't have anything like that, from a programmatic point of view. Even Linux distros, that's an action outside the scope of programming and into the scope of package creation and OS integration. There is no programming language that I'm aware of that automatically sorts out such things for you so that when you #include popular_library it makes sure that popular_library exists, or asks the user if they want to install it, and keeps it up to date. The onus is all on the packager, not the developer (and they are rarely the same person), and on the individual package management for that particular OS (there's no cross-platform way to do this).

      Perl CPAN.

      PHP libraries.

      Java dependencies.

      DLL's.

      You name it, the problem rears its head in every language in common use, and the languages always consider it "outside the scope" of their remit to provide for it.

      If you want to stop building statically building in old versions, and thus propagating vulnerabilities in un-updateable code, you have to design an OS and a language that takes account of things like this. There's no way we should be manually creating dependency files, packing up RPMs with funny little tags, or running setup programs that have to be told to run off and download MSVCRT from the MS website and then installing it and then switching back to the "setup" program if it worked.

      Java is no different here. But Java was always a highly-specced langauge with the capability for this kind of thing. Aren't java packages almost exclusively referred to by a corruption of their origin domain name? (com.java.sun, etc.). There was scope there to make it automatic, tie it in with DNS, XML requests, etc. and it wasn't done.

      The closest we get is things like Javascript libraries and XML DOM's where you can instruct a browser to run off and download the latest JQuery or use a particular version of the Google web fonts or whatever, and it tries its best to do so. And that works quite well, to be honest. Millions of website rely on it.

      But still you see websites that copy/paste their code to local URLs and things like that. And yet no "offline" programming language or mainstream operating system has facilities for this kind of thing.

      Nobody who wrote a piece of code 10 years ago is going to bother to keep the libraries up to date. They probably no longer work on it, no longer have the power to do anything about it, no longer paid to do that, no longer remember or care. But we still just assume that software will live forever in the same state once its written.

      Imagine if, when OpenSSL was flawed, or MD5 was cracked, we could just mark it as obsolete, mark an upgrade path, and EVERY piece of software that dealt with them worlwide was updated to use a replacement library or object class as soon as it was next executed?

      1. Anonymous Coward
        Anonymous Coward

        Re: Levels of blame...

        But what happens when an updated version deprecates something on which you rely, yet is so subtle there's no semantics for saying the library you need can't update beyond a certain point or your program breaks?

        Frankly, the main reason something like updating is not in the language is simply, because...well...it's complicated. And what if you get caught between Scylla and Charybdis, where the best version you need has more holes than a wheel of Emmentaller yet the lowest "secure" version doesn't work with your program?

      2. richardcox13

        Re: Levels of blame...

        > Imagine if, when OpenSSL was flawed, or MD5 was cracked, we could

        > just mark it as obsolete, mark an upgrade path, and EVERY piece of software

        > that dealt with them worlwide was updated to use a replacement library or

        > object class as soon as it was next executed?

        And watch as some minor behavioural "fix" in the new version (on some other part of its functionality) causes many of those applications to break.

        Behavioural dependencies can be very subtle, no amount of unit/integration testing will cover them all (100% is not enough, people will depend on officially "undefined" results).

        Real world backwards compatibility can include leaving in some bugs…

        1. Doctor Syntax Silver badge

          Re: Levels of blame...

          'Behavioural dependencies can be very subtle, no amount of unit/integration testing will cover them all (100% is not enough, people will depend on officially "undefined" results).'

          Such people deserve a good smack on the head from each of the users on which they've inflicted their code.

          One of the many good points discussed in TMMM was whether a written spec or a working example should be taken as the working standard. The example given was the 360 H/W where programmers came to rely on the data left in some registers after an operation where the contents of those particular registers was undefined in the written spec. It then tied the designers to maintain that particular behaviour in future generations of the H/W whether they wanted to or not.

          Unit tests give a third alternative. Publish the unit tests of a library. If the functionality of the library is added to or bugs fixed more unit tests can be added but no test should be changed or removed*. That guarantees backwards compatibility, it gives users a set of examples to use. And, importantly, any behaviour which isn't covered by the tests cannot be relied upon. Any developer who assumes some behaviour not covered in the tests does so at their own risk.

          *If the need to change or remove some functionality arises it's time to start out under a new name or at the very least, a new major version number so that the old version can still be made available for applications needing the old functionality.

      3. Phil O'Sophical Silver badge

        Re: Levels of blame...

        Imagine if, when OpenSSL was flawed, or MD5 was cracked, we could just mark it as obsolete, mark an upgrade path, and EVERY piece of software that dealt with them worlwide was updated to use a replacement library or object class as soon as it was next executed?

        But that flaw in OpenSSL wasn't put there intentionally, it was inadvertent, and those new versions could have other as-yet-unknown problems. If I've spent months validating my system, checking that all the bits work together, securely, the very last thing I'd want is some smart-alec loader deciding "hey, there's a new improved version, I'll install it and its 27 gazillion dependencies". My security and reliability would go out the window. Does automatic Windows Update sound familiar?

        Sure, dependency hell is no fun, but doing that packaging and testing is part of the job of building a system, you can't delegate it to an untrusted source.

      4. Roo
        Windows

        Re: Levels of blame...

        "Nobody who wrote a piece of code 10 years ago is going to bother to keep the libraries up to date."

        I guess shared objects ld.so and the weird symbolic linking thing in /usr/lib passed you by then. Also APIs change over time - consequently the application also needs to change. Also, realistically, once you've changed the run-time configuration you should do some regression testing.

        1. Doctor Syntax Silver badge

          Re: Levels of blame...

          "Also APIs change over time - consequently the application also needs to change."

          Wrong way round.

          APIs might grow but should not change or remove existing functionality therefore the application should not need to change except to take advantage of such extended functionality

          Why offer and API if you don't intend it to be used?

          Why use it if isn't stable?

          By offering an API a responsible developer is making an implicit offer that it will not change. Unfortunately there are irresponsible developers and/or maintainers out there but an API which fails to maintain backwards compatibility deserves to get a bad reputation. Developers, and their users, have better things to do than keep chasing changes made by other developers with twitchy fingers.

          1. Roo
            Windows

            Re: Levels of blame...

            "Also APIs change over time - consequently the application also needs to change."

            Wrong way round.

            APIs might grow but should not change or remove existing functionality therefore the application should not need to change except to take advantage of such extended functionality"

            You say "should", in practice that just can't be relied upon. There are APIs out there that are insecure by design - what do you do with those ? If apps are tied to those APIs they need to be killed or changed - in my experience the latter works better over the long run (YMMV).

      5. Doctor Syntax Silver badge

        Re: Levels of blame...

        "The closest we get is things like Javascript libraries and XML DOM's where you can instruct a browser to run off and download the latest JQuery or use a particular version of the Google web fonts or whatever, and it tries its best to do so. And that works quite well, to be honest. Millions of website rely on it."

        You think that's a good idea? The application now depends on a component downloaded on the fly form a source where neither the website developer nor user has any control unless, as a use, you run NoScript. The newly downloaded component could have been updated so that it no longer supports the required functionality, has become buggy or has been out-and-out converted into malware. Or, as in an earlier comment, suddenly been made unavailable because of a spat between the developer, the site hosting it for download and, in that particular case, action over a trademarked name. And the situation cascades. NoScript users are familiar with the situation that allowing one address suddenly brings in requests to allow a whole lot more.

        What you describe as working quite well is actually far less regulated than a distro's curated repository.

      6. david 12 Silver badge

        Re: Levels of blame...

        The update model you are describing is Windows 98. Where all libararies were installed in a shared "system" folder, and where installers only and always installed their own libary version if it was more recent than the existing version.

        Not saying that is bad, but the update models we use everywhere now were implemented in /reaction/ to the Win98 model

    3. Andus McCoatover

      Re: Levels of blame...

      GOTO 1.

      There, fixed it for you.

  2. Will Godfrey Silver badge
    Unhappy

    Biased?

    In the article I see the negative reference to open source software, but no mention of the many years-old known bugs that are only fixed by the 'professionals' when forced to.

    1. beerfuelled

      Re: Biased?

      And at least with open source you have a chance of analysing the dependencies (and dependencies of the dependencies) yourself. With closed source you just have to take the vendor's word for it!

      1. Trixr

        Re: Biased?

        *cough* Heartbleed?

        Two years to fix that little number. If you're not *paid* to go searching for problems, assuming you actually have the skill and know-how, how often do you do so?

        1. Doctor Syntax Silver badge

          Re: Biased?

          "Two years to fix that little number."

          Let's look at that a little more closely.

          As far as I can make out from wonkypedia the code with the bug was released in March 2012. It was discovered independantly by at least two lots of researchers in mid-March and the beginning of April 2014. It was disclosed to the developers in early April. How did they discover it? By examining the open source code. Had it been closed source it wouldn't have been discovered let alone disclosed. It was announced to the public and a fix released on the 7th of April.

          In other words, from disclosure to fix took about a week. By my calculation that's about 1% of the time you allege. The two years was the time it took to discover. Had it been closed source that time would have been somewhere between longer and never.

          "If you're not *paid* to go searching for problems, assuming you actually have the skill and know-how, how often do you do so?"

          And even if you're paid, as the discoverers were, how do you do so when you can't review the closed source?

          But, hey, don't let facts and details get in the way of a good rant.

    2. Mark 85

      Re: Biased?

      In the article I see the negative reference to open source software,

      Very understandable as the company's business is for PAID development. Open source people don't hire them and thus are outside of their business model or rather... profit line.

  3. Adrian Midgley 1

    Another closed source shill?

    Open Source: it is impossible to be prevented from checking it or having it checked;

    Closed source: it is impossible to check it unless you closed it, and impossible to know it has been checked or corrected.

    1. Phil O'Sophical Silver badge

      Re: Another closed source shill?

      This isn't an open/closed issue, it's one of sensible validation versus laziness.

      Open Source software can be checked, if the developer takes the time (and has the ability) to do so, or it can be stuffed in without validation because it's easy. Closed source software can be bought from a trustworthy source, with independent certification and penalties in a contract, or it can be bought from a startup with no visibility.

      The problem is that too many people take the easy option.

      1. PNGuinn
        Facepalm

        Re: Another closed source shill?

        "Closed source software can be bought from a trustworthy source"

        If it's closed source, How the hell do you KNOW that??

        Trust the vendor? Yeah, right.

        I smell a dose of FUD. Of course, you'll have to trust me as to the size of the dose ...

        "The problem is that too many people take the easy option."

        I wasn't aware that there was one. Easier, maybe.

        1. Phil O'Sophical Silver badge

          Re: Another closed source shill?

          If it's closed source, How the hell do you KNOW that??

          Trust the vendor? Yeah, right.

          Vendors who need their software to be trustworthy will have it tested and certified (at the source code level) by compliance labs. At considerable expense

          Of course, you can ask "can you trust those labs" but you have to accept trust somewhere. Even open source code is only as trustworthy as the compiler you use. You can analyze the source, but can you trust the compiler you build it with? OK, so 'gcc' is open source, but are you then going to analyze it, and build it from source to be sure? What do you build it with?

          If you're sceptical, you may want to look up Ken Thompson's 1984 Turing award paper "Reflections on Trusting Trust" in which he describes how to modify a compiler so that it intentionally miscompiles certain code, including itself.

          "The problem is that too many people take the easy option."

          I wasn't aware that there was one. Easier, maybe.

          The easy option is not to check at all. It's almost as foolish as assuming that closed source code from a vendor whose business relies on its reputation is automatically worse than open source code written by a self-taught hacker with a sunny disposition.

          1. Charles 9

            Re: Another closed source shill?

            Wasn't Thompson's 1984 paper retorted by David Wheeler in 2005 ("Countering Trusting Trust through Diverse Double-Compiling"), demonstrating a cross-compiling method by which you can detect a bad compiler?

            1. Phil O'Sophical Silver badge

              Re: Another closed source shill?

              I hadn't seen that one, thanks for the heads-up.

  4. Pascal Monett Silver badge

    DevSecOps ? We're really going there ?

    If you have to create a special lingo for including security into your development process, I think you're just highlighting the problem right there.

    There should be no DevSecOps. It should be just plain old DevOps, because security shouldn't be anything special to the process - it should be right in the middle of the process. At all times.

    1. tojarrett

      Re: DevSecOps ? We're really going there ?

      Totally agree. There's no good naming for the concept of "securing DevOps" and no one agrees on the naming. I've seen "rugged DevOps", "SecDevOps," and "DevSecOps." I think we should probably actually just talk about it as "DevOps."

      1. Doctor Syntax Silver badge

        Re: DevSecOps ? We're really going there ?

        'I think we should probably actually just talk about it as "DevOps."'

        I think we should just talk about the good old-fashioned maintenance phase. The long-lasting part of software's life into which it's launched by the development phase.

    2. yoganmahew

      Re: DevSecOps ? We're really going there ?

      Who knew that false positives didn't slow the development cycle.

      DevOps: This QA test has failed.

      Me: My code doesn't go near that.

      DevOps: Prove it.

      Me: Er... oh, never mind, I'll go next release, at this stage I can't be arsed.

  5. Stephen Booth

    Over egging the pudding maybe

    Just because an application CONTAINS a component with a vulnerability does NOT mean that the bug is exploitable in the application. It is very very frequent that applications will include a jar-file for a very specific purpose, pass a very restrictive set of inputs to the code in question and exercise a very small fraction of the included code. If the application never calls the part of the component with the bug and can't be persuaded to do so then the application is still secure.

    I'm not saying that this is never a problem but just looking at component dependencies is making some serious worst case assumptions.

    1. Anonymous Coward
      Anonymous Coward

      Re: Over egging the pudding maybe

      But another situation arises. As long as the module is loaded, whether the original program is coded to call the buggy section or not, can not another program access, or perhaps the original program pwned and redirected to the buggy section?

      IOW, just because no one regularly approaches an ammunition dump doesn't mean it's not a dangerous place.

      1. Stephen Booth

        Re: Over egging the pudding maybe

        If your main application allows arbitrary redirection to code it would not normally call then I would assert that you have already lost the security war. The bad guys WILL find a way to break you no matter what your dependencies are.

        If you can arbitrarily call code in an included class library you can also call the core java libraries to do pretty much what you want.

        Now the Java language does have a second line of defense in it has a sandbox and some support for running "untrusted" code. You are entirely right that if you are relying on the sandbox for your security then having code that contains vulnerabilities that can escape the sandbox linked in to the application would be a big problem. However the fraction of modern Java code that actually downloads remote code and relies on (or even use) the sandbox should be tiny. and the fraction of known vulnerabilities that allow the sandbox to be escaped is also tiny.

    2. Doctor Syntax Silver badge

      Re: Over egging the pudding maybe

      "Just because an application CONTAINS a component with a vulnerability does NOT mean that the bug is exploitable in the application. It is very very frequent that applications will include a jar-file for a very specific purpose, pass a very restrictive set of inputs to the code in question and exercise a very small fraction of the included code."

      If you don't know the bug's there and what it is you've no way of knowing that your very restrictive set of inputs passed for your very specific purpose won't exercise the small fraction of code that includes the bug.

  6. wikkity

    Best practices like remediation coaching and eLearning

    Hmm, do veracode provide such offerings by any chance?

    1. zebthecat

      Re: Best practices like remediation coaching and eLearning

      Indeed they do

      They are also running a devops security roadshow tour at this very moment

      1. Doctor Syntax Silver badge

        Re: Best practices like remediation coaching and eLearning

        "They are also running a devops security roadshow tour at this very moment"

        What a remarkable coincidence. My flabber is utterly ghasted.

  7. Kolchack
    Trollface

    vulnarable component...

    You are speaking of the JRE itself, right?

  8. Anonymous Coward
    Trollface

    Nearly all ... of Java applications contain at least one component with a known vulnerability

    Yes, that would be Java.

    1. Anonymous Coward
      Anonymous Coward

      Re: Nearly all ... of Java applications contain at least one component with a known vulnerability

      What about the other 3%?

      Oh right, Java translated to some other language... like GWT apps.

  9. Erik4872

    Tower of Abstraction Syndrome

    What I see a lot, coming at this from the systems integration side, is developers relying so heavily on these towers of dependent libraries that it's very difficult to tell what the actual code they write is doing under the hood. Or, they take on a huge dependency for one tiny library function to avoid writing anything new.

    No one should unnecessarily rewrite known-good code, but taking a dependency means taking the responsibility of ensuring that it is secure, and continues to do what you want it to do over time.

    1. Doctor Syntax Silver badge

      Re: Tower of Abstraction Syndrome

      "taking a dependency means taking the responsibility of ensuring that it is secure, and continues to do what you want it to do over time."

      Sadly true but the responsibility really ought to lie with the provider of the code.

  10. Andus McCoatover
    Windows

    Simples.

    Try using an Atmel XMEGA series A/D converter to produce meaningful results.

    If anyone can get that working, I'll buy 'em a pint! Even Atmel can't....

  11. Anonymous Coward
    Anonymous Coward

    Real programmers use COBOL

    Years of updating the underlying z/os and CICS regions to maintain support and never once having to rewrite the code.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like