back to article Juniper 'fesses up to TWO attacks from 'unauthorised code'

Juniper Networks has offered a more detailed description of the security issues resulting from its find of “unauthorised code” in ScreenOS, the software that powers its firewalls. The company's knowledge base article on the incident says: “The first issue allows unauthorized remote administrative access to the device over SSH …

  1. ken jay

    i used to upgrade the juniper routers, it consisted of, heres a cd go run it on that box. wasnt rocket science either

  2. Destroy All Monsters Silver badge
    Headmaster

    a criminal gang that on-sells

    What happened to english grammar?

    nothing further to add

    So we are left with an "un-knowledge base article" (or an "un-knowledge un-base article" or even an "un-knowledge un-base un-article")

  3. P. Lee Silver badge

    The source of the code is irrelevant.

    More importantly, was the source code updated or were the binaries changed?

    Where is the QA?

    Was there no code audit followed by md5sum?

    Here in Oz, stuff "made is China" has a pretty bad reputation, whereas European stuff is "premium quality." Which is funny because "European stuff" is usually made in China too, but someone has applied decent QA to it.

    The next time, someone tries to shout down the implementation of security policies and procedures as administrative dead-weight, I think there is now plenty of evidence that you will lose customers if you don't do security effectively.

    1. Anonymous Coward
      Anonymous Coward

      Re: Where is the QA?

      QA is expensive, really good QA is ludicrously expensive*.

      Comprehensive QA extends the production cycle, making it slower to ship 'new, improved' features.

      QA in the short term adds absolutely no value visible to the accountants**

      So, the financial answer is "do as little QA as we can get away with".

      When a company is acquired / taken over by another, one of the obvious back room savings is in the amalgamation of two QA groups into one group with a head count nothing like the sum of the originals.

      That's where the QA is - gone

      * one one safety-critical system I know of that protected very high value assets with lives at stake, the QA staff was almost exactly 50% of the effective head count of the entire development group.

      ** it is impossible for a beanie to value the stuff-ups avoided by having 'enough' QA

      1. tom dial Silver badge

        Re: Where is the QA?

        After quite a few years of involvement variously in system specification, design, development, QA, and management, the only thing that surprised me in this was the implicit proposition that a QA staff only half the size of the development group might be adequate.

      2. Doctor Syntax Silver badge

        Re: Where is the QA?

        "it is impossible for a beanie to value the stuff-ups avoided by having 'enough' QA"

        Just get an insurance quote to cover fines, class actions, loss of income due to loss of reputation, cost of remediation & anything else you can think of. Avoiding that's the value.

      3. Vic

        Re: Where is the QA?

        Comprehensive QA extends the production cycle, making it slower to ship 'new, improved' features.

        Actually - no, that's wrong.

        Decent QA stops the "knock it out the door in Friday afternoon before you go home" shipments, but those are inevitably the ones that bite you. They fail in the field, leading to expensive retro-fitting, embarassment in front of cuistomers, lost sales, etc.

        Doing the job properly gets working product to market more quickly than having to go through a release cycle three times because you haven't bothered to check if the machine even boots...

        Vic.

    2. Anonymous Coward
      Anonymous Coward

      Re: The source of the code is irrelevant.

      > Was there no code audit followed by md5sum?

      Ahem. Anything important which relies on md5 is breakable - it has been publically explotable since 2008 using nothing more than a bunch of Playstations.

      http://www.win.tue.nl/hashclash/rogue-ca/

      > I think there is now plenty of evidence that you will lose customers if you don't do security effectively

      Where is that evidence? Most consumers don't even consider security as part of their purchasing decision, because they have no way to evaluate it. Perhaps when we have security "star ratings", like restaurant hygiene ratings, it will have an impact. How those stars are assigned is a separate discussion.

      However, purchasers of firewalls are probably one of the few groups who do actually care about security, so Juniper may lose some customers over this.

      1. Destroy All Monsters Silver badge
        Headmaster

        Re: The source of the code is irrelevant.

        Ahem. Anything important which relies on md5 is breakable - it has been publically explotable since 2008 using nothing more than a bunch of Playstations.

        Granted that SHA-1 or whatever is "best" now should be used. Still:

        I challenge you to write code that:

        0) Still compiles

        1) Hashes to the same md5sum as the original code

        2) Has the same functionality as the original code

        3) Doesn't immediately raise a red flag by eyeball inspection alone

  4. a_yank_lurker Silver badge

    Questions

    There are numerous questions about were did the code come from. Rummaging around it appears the licensing is a mixture of proprietary and BSD. So the question was which part was corrupted. Also, who did it; fingers seem to point to China. But as stated, one should be wary about this since many spook agencies would love to have this kind of back door.

    The spooks are very good at bending people to do their will. Also, the bit about a skilled attacker would not leave any trace in the log files of their presence tends to point a spookhaus doing this. But which spookhaus?

    1. Vic

      Re: Questions

      the bit about a skilled attacker would not leave any trace in the log files of their presence tends to point a spookhaus doing this

      No, I don't think so. It's merely a recognition that, if you've rooted the box, it's a trivial matter to cover your tracks.

      Vic.

    2. NigelD

      Re: Questions

      It seems there is better evidence to suggest NSA involvement... http://boingboing.net/2015/12/21/juniper-networks-backdoor-conf.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+boingboing%2FiBag+%28Boing+Boing%29

  5. Anonymous Coward
    Anonymous Coward

    Seriously!!!

    It's a toss-up between who is more stupid:

    Juniper for trusting the coding of a security device to commies in China or the US Government for buying a security device from the boobs at Juniper.

    Just glad I don't own Juniper stock.

    1. Anonymous Coward
      Anonymous Coward

      Re: It's a toss-up between who is more stupid:

      Juniper, the US governement, or the regtard ac commenter who thinks jingoisitic name calling make him sound knowledgeable.

    2. Anonymous Coward
      Meh

      Re: Seriously!!!

      As opposed to say Cisco, who have had no bloody great holes in them this year?

      In fact "Commie" Chinese (must be a Fox News lover), seems to have less in, than the big boy "home grown" stuff from the USA.

  6. Big Ed

    I Can Hardly Wait for Self Driving Cars

    Best lesson I learnt from a sage university prof, "it is mathematically impossible to prove a program is correct".

    You can prove test cases. And even if you think your test cases test all conditions, failures, or paths; testing can't account for failure conditions never imagined, or errors in underlying hardware, firmware, Hypervisor, or OS. And then there's the possibility that the test cases themselves may be coded wrong. When I use to write MF security code, I sometimes made design choices and assumptions that were proved wrong in the real world.

    All the QA in the world can't prove correctness.

    Moral of the story, never, ever completely trust software.

    1. Voland's right hand Silver badge

      Re: I Can Hardly Wait for Self Driving Cars

      Indeed.

      QA has little or nothing to do with this - if the software still passes the tests, then there is nothing QA could do.

      What this show is lack of commit and merge review process. It should be impossible to insert code into a system without leaving trace in the SCCM who inserted it, who reviewed the patch, what is the associated issue and what is the associated test-case. While this can also be subverted it takes more than one person to do so and they leave traces all over the place.

    2. Vic

      Re: I Can Hardly Wait for Self Driving Cars

      Best lesson I learnt from a sage university prof, "it is mathematically impossible to prove a program is correct".

      Well, if he actually said that, then he's wrong. It *is* possible to prove code correct.

      What he probably said is that is is infeasible, and that's a more realistic statement. The closer you get to correctness, the harder (and more expensive) it gets.

      Vic.

      1. Anonymous Coward
        Anonymous Coward

        Re: I Can Hardly Wait for Self Driving Cars

        Greatest respect etc: Was it Knuth that said something like "I have proved this program correct but I haven't actually tested it"?

        Proofs of correctness need to be shown to be correct: see e.g. RSRE 'proven correct' Viper microprocessor.

      2. Destroy All Monsters Silver badge
        Headmaster

        Re: I Can Hardly Wait for Self Driving Cars

        "it is mathematically impossible to prove a program is correct"

        For most values of "correctness".

        However, it is possible (in some cases) to mathematically prove that code conforms to a (specially crafted) specification.

        What he WANTED to say is that "it is mathematically impossible to prove the absence of 'errors' (however defined, the definition is left as an exercise to the reader) IN THE GENERAL CASE". The general case is generally not sought. This is why incompleteness theorems are rarely relevant in the real world.

        "The Self Driving Car" does not need code correctness btw - it needs safe failure modes. Safe failure in a complex environment cannot be obtained by code inspection or testing, but needs to be determined by going out, driving around, and doing the statistics.

      3. Roo
        Windows

        Re: I Can Hardly Wait for Self Driving Cars

        Have an upvote for making a better job of it than I did. :)

    3. MacroRodent Silver badge

      Re: I Can Hardly Wait for Self Driving Cars

      Testing shows the presence, not the absence of bugs

      - Edsger W. Dijkstra

      1. Destroy All Monsters Silver badge
        Headmaster

        Re: I Can Hardly Wait for Self Driving Cars

        "Testing shows the presence, not the absence of bugs"

        Obvious to the meanest first-semester intelligence. The more so as bugs may be in the eyes of the beholder. Dijkstra's provable microproblems continue to make one think, but they are still irrelevant to real-world software (plus they were written in imperative style, which is hard to think about and hard to apply first-order logic on, in order words, inappropriate -- I hope Dijkstra-inspired curriculae have been reworked, mine was rather horrid btw. but it was probably also meant to weed out freshmen easily disgusted by mysterious symbology)

        More interesting, in (paywalled):

        Steve Tockey, "Insanity, Hiring, and the Software Industry", Computer, vol.48, no. 11, pp. 96-101, Nov. 2015

        "Software project and product outcomes strongly suggest that the software industry still suffers from dismal performance. A brief survey of job postings reveals a significant gap between what hiring managers of software developer positions are asking for and what they actually need" (i..e NOT people "skilled in C++" but in actual system engineering and economic thinking)

        we read:

        The next question we should ask is, “What drives poor software project and product performance?” I’ve identified four major causes of poor performance, listed here in decreasing order of significance:

        1) Vague, ambiguous and incomplete requirements

        2) Inadequate project management

        3) Overdependence on testing: It’s impossible to comprehensively test nontrivial code. .... Typical software testing teams are between 60 and 70 percent effective at finding defects, meaning users discover 30 to 40 percent of software defects. The cost to repair any defect increases exponentially as the project progresses—that is, fixing a defective requirement after code has been written is many times more expensive than fixing that same requirement defect before design and coding work has begun. Return on investment for software inspections—a form of peer review—has been reported as high as 44:1. Thus, each person-hour spent inspecting requirements and design avoided as many as 44 person-hours of rework later in the project

        4) Uncontrolled code complexity

        .

        But that's just by the by

    4. Roo
      Windows

      Re: I Can Hardly Wait for Self Driving Cars

      "Best lesson I learnt from a sage university prof, "it is mathematically impossible to prove a program is correct"."

      Some programs can't be proven to be correct, but in the general case Sage University Prof is wrong.

      You can prove that *some* programs are "correct" with respect to a "correct" spec. There's been a fair bit of work in that area over the last 30 years, a sage prof with a good solid understanding of the topic and research done in the area, might have phrased their assertion more carefully. ;)

  7. imanidiot Silver badge

    What I find telling

    is that the second flaw didn't make it into just one version but 2 different versions. Possibly with a gap in between (hard to tell, was 6.2.0r18 the last 6.2 and 6.3.0r12 the first 6.3 release?) So how did THAT happen?

    1. Anonymous Coward
      Meh

      Re: What I find telling

      Errr the same way any "bug" can be in software for years, if no one is looking, no one will find it. Just look at Windows and Linux for cases of this happening.

  8. Christian Berger Silver badge

    One should note...

    ...that this bug really smells like it comes from the NSA. After all it's in their random number generator.

    And Juniper (claimed to) fix(ed) it, nobody knows if it's still in other equipment.

  9. DrHow

    It should be noted that the VPN vulnerabilities do not apply to VPNs in general but just to those provided by Juniper.

    1. Anonymous Coward
      Anonymous Coward

      If you've ever tried getting their VPN client to work, it doesn't inspire confidence in their firewalls either. "Slap together some bloatware and ship it" eh?

  10. CAPS LOCK Silver badge

    What, if anything, is the open source equivalent?

    Justaskin'

    1. Roo
      Windows

      Re: What, if anything, is the open source equivalent?

      I used OpenVPN a long time ago, no idea how it stacks up against Juniper's gear though. It worked well enough from the PoV of just using it (I didn't set it up). I try not to make a habit of courting the attentions of plods operating under the "nothing to hide, nothing to fear" principle, so I tend use (ad-hoc) SSH sessions on the rare occasion I feel the need to wrap stuff in a security blanket (pun intended).

  11. Steve Medway

    I think everybody commenting so far has missed an important point regarding QA.

    QA's purpose is to ensure that a product's features works as intended. If some rogue employee puts in a hidden backdoor that allows additional 'functionality' it's not the QA's Dept's job to spot it. FFS They don't even get to see the code usually.

    It was up to his line manager or teammates to ask the question of why something so nefarious (or boneheaded) was inserted into the code. This is a 'Pre-QA' issue and points to dev team not performing 2nd person code validation (or the second person was not as clever as the backdoor writer).

    'Negative Testing' is a valid test methodology but it's virtually impossible to say it has EVER been completed because the reality is that it NEVER will be (there's always someone more cunning than you out there folks)!

    Deep 'Negative Testing' would have caught this kind of stuff-up but how far do you go with it? For someone like Juniper I'd have an army of independent penetration testers + bug / hack bounties. Seems likely that they have neither.....

    1. Roo

      "For someone like Juniper I'd have an army of independent penetration testers + bug / hack bounties. Seems likely that they have neither...."

      I hate to sound flip, but as soon as testers are taking Juniper's money they would cease to be independent. Arthur Andersen failing to properly audit Enron is an example of how that can go wrong in practice.

      The bounty scheme seems like a reasonable option for acquiring your army of independent penetration testers, but you are competing in an open market against other vendors to attract decent talent, you have zero (you said independent, right ?) control over which bits of code these folks work on so the coverage will be patchy for a non-trivial bit of code.

      1. Steve Medway

        I sense a worm hole... Enron is a prime example of collusive fraud, Maybe the Juniper does proper internal code audits.... but who audits the auditors before the brown stuff hits the spinny thing?

        Sarbanes-Oxley didn't really change anything, just create one massive clusterf*uk of paperwork and use it to place blame after the fact. It would be highly amusing if it wasn't such a pain in the ass.

        It's a critical to have a test strategy that has a solid methodology and every potential input into the system is tested.

        However off-piste testing is fun, it really pisses of Dev's off because it can expose laziness or incompetence (e.g. playing the game of doing just enough to pass the Company QA 'suite of tests' despite what the company mantra is on product security).

        Off-piste pen testing is the job of a hacker who wants to do it for fun. The reality is that a company 'friendly' towards these people can save a lot of money. That is where the independence bit of bug bounties pays off. It's also a hell of a lot cheaper than keeping them on the pay roll 'full-time' but there's nothing the matter with a retainer for a good 'bug hunter'.

  12. Anonymous Coward
    FAIL

    Feeble journalism <flame alert>

    This story starts well enough and then descends into the sort of wink-wink that makes El Reg look like a second-rate knock off of eWeek. The problem starts with, "That work's done in China".

    OK, so now you, dear journalist, have a question to ask yourself. Are you going to follow the lead where it goes? Y'know, make calls, hang around outside the dev center in Beijing or Shenzen or whatever, trace old release notes back, call your techie insider Trevor to see what he knows, and buy drinks for ex-employees? Or are you going to wimp out, insert some feeble disclaimer that your editor's lawyer said you should to feebly indicate that you aren't really poking at the honesty of the Chinese, whilst *simultaneously* doing so? El Reg readers are smart and can see a "Brutus is an honourable man" attempt a mile off.

    Net-net: if you've got proof, come out with it. If you don't, STFU. Trawling LinkedIn is not journalism.

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

Biting the hand that feeds IT © 1998–2019