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 …
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.
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
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.
> 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.
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
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?
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.
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.
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.
"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.
"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
"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. ;)
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).
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.....
"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.
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'.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
