I arrived at the point where when I see Cisco in a headline
I expect to read an article about another security failure. Job done Cisco.
A programming slip in Cisco VPN software has introduced a critical vulnerability hitting ten different Adaptive Security Appliance and Firepower Threat Defense Software products. The bug scores a perfect ten CVSS rating, and is present in the products' SSL VPN functionality. That's bad news because if you've deployed the VPN …
A security appliance that experiences memory allocation errors caused by a programming error, isn't really secure now is it. Isn't it patently obvious that there is a crisis in computer security and the current solutions aren't up to the task. What was the name of the CPU and chipset that fails if you try and double free a region of memory?
What was the name of the CPU and chipset that fails if you try and double free a region of memory?
Uh, it is not the CPU or chipset that fails, but the program. A double free is a common blunder in C and C++ programming, which leads to a crash or other undefined behaviour, which may be exploitable as a security vulnerability.
All these security errors. Makes one wonder who they pay to write their code. Same for all the big programming houses. The chip manufacturers are, of course, guilty too. Is it the state of the education system? Wherein Universities need money so pass people who wouldn't have have able to pass the curriculum of 30 years ago? Is it the time line in which they are expected to write the code? It's not like these programmers are inventing new programming methods, in most cases. Are the groups who write this code so segmented the left hand doesn't know what the right hand is doing? Those are all real questions. Am I being to hard on the programmers? Can anyone fill in the blanks?
"... Can anyone fill in the blanks?"
Yeah, sure. It's easy.
Deep down, nobody really cares.
They get the accounts in on time because if they don't they get fined.
When they get fined for bad security, security will improve. Not until.
I imagine that some of what you say is entirely valid, but surely you are missing a couple of points too.
First of all programming 30 years ago may well have been full of exploitable holes that no-one discovered due to the simple fact there weren't as many people looking for them. What we've got now is the infosec equivalent of an infinite number of hackers on an infinite number of laptops, more systems are being prodded by more people and so more problems are being found.
In addition to that is it not the case that the systems that are being released are just that much more complicated? Your programmer 30 years ago might have made tidier, tighter code but chances are it was only doing one small easily tested (relatively speaking) function, compared to a cisco Threat Defense system thats infinitely configurable and can operate in a huge number of ways.
And that isn't to defend the idea that we appear to have a fundamental problem with security in the industry now, but blaming the 'new' programmers is perhaps a little simplistic.
I guess you haven't been paying attention to how many American programers are being fired to make room for H1-B visa holders. Of course they get some sort of severance which they lose if they speak up. Hence very little in the press.
So when you talk about Universities it is probably not the American Universities who are the issue.
"...30 years ago?"
How secure was Windows 2.10 running on MS DOS 4.0? Netware 2.x? OS/2 1.1? Cisco was barely 3 years old 30 years ago, and I bet the contemporary version of IOS is a scary nightmare of security holes that no one knew were there.
Or even know about today, as no one is looking at it any more, so it never got the same level of scrutiny that today's code gets.
So, did the "best and brightest from the best universities" programmer fail to NULL out the pointer after he or she freed it or were there multiple copies of the pointer to the memory region in the code? Both are no-nos that were supposed to be banned in IOS more than a decade ago. Also, looks as if someone removed the "zero out a freed memory buffer" code - probably because it was "slow". Let's not forget the old "freeing freed memory" check that was in IOS.
But I know nothing.
"Our software is our crown jewels." -John Chambers
Check the "Interim Releases" tree. 9.8.2(14) through 9.8.2(17) all fixed should show up there. Likewise, there.
That said, there is not yet an Interim Release for 9.9.1. The original announcement described 126.96.36.199 as being fixed. That must have shown bugs, because now the document shows 188.8.131.52 as the target. Cisco tells me that release will be available today.
"... Can anyone fill in the blanks?"
Yeah. Do you think developers at corporations should work for free, in their own time? If not then they are limited to the time (budget) allocated to the project.
Dev: Boss, do you want this error-free? We'd need code reviews and a comprehensive test frameworks, etc.
Boss: How much more would that cost?
Dev: (cost of crap code) * n
Boss: Well, lets' see if we can minimise n, shall we?
Dev: OK, boss.
Why do you think Linux is stealing the OS market? No bosses. The devs do it right.
I understand that, but this is the software that runs their own devices, security devices. Obviously I'm naive , I'd have honestly thought that the software/firmware for these devices would be developed under better practices with more intense QA/testing regimens. Cisco is a huge Corp. with a massive amount equipment out in the world. I think they can ill afford these issues and still demand premium prices. If a Corp. wants to charge premium prices it had better produce a premium product; otherwise, screw them Chinese white boxes are good enough.
I can't even enumerate all the times a boss have asked me if I could skip some testing after I've delivered a time estimate for implementing a feature. For the first few years of my career in systems development, it happened on every single time estimate I delivered.
I hold no illusions about it being better anywhere in the industry. Verifying correctness is expensive, and thus skipped as soon as the product barely resembles the initial requirements, as if they were any good to begin with.
"Obviously I'm naive , I'd have honestly thought that the software/firmware for these devices would be developed under better practices with more intense QA/testing regimens."
Yes, this is a naive thing to expect. Because in economic terms, Cisco and every other software vendor out there simply does not have any incentive to make correct software (or hardware, for that matter). It is certainly possible to produce bug-free products, and the processes required to at least dramatically reduce the number of serious bugs in products are well-understood by the better engineers in the industry. This isn't a matter of "can't" but of "don't care".
They don't have any incentive because their customers (mostly other corporations) don't have any incentive to secure their customers' data or provide reliable services; therefore, they aren't selective about the IT products they purchase, either. And with no market pressure, the IT vendors will keep producing crap products because other corporations keep buying them because their customers keep buying their products and services too. Meanwhile, the Chinese will continue their mammoth-scale industrial espionage activities, made trivial by the presence of all these bugs. By the time they can take advantage of the take from them to out-compete Cisco's customers (and Cisco), the CEO will have made his megamillions and retired, so what does he care that Cisco's insecure security products leaked his own company's trade secrets?
As was said earlier: deep down, no one really cares. People express care by spending, or not spending, their money. People keep buying leaky, unreliable products and services from Cisco's customers. Cisco's customers keep buying buggy IT products from Cisco. That's what it means not to care. What people say doesn't matter; it's the money that votes.
I have to disagree... people do care but the line between the programmer who missed one colon, sub-routine, class etc and the high flying exec who is pushing for the healthy bottom line is too far apart.
The two ends of the scale can not comprehend each other and the distance between them in the large multi-national businesses ensures a dis attachment that means they care not about each other and the drivers and goals they are each working towards. A programmer is proud of his code and a CFO proud of his balance sheet, until one understands the other fully what we see here will continue... IMHO
This is why those who sell insecure products such as blatantly defective software, O/Ss, security hardware, etc. should be fined tens of millions for their negligence and apathy. If the fines are high enough more care will be exercised or the incompetent and unscrupulous purveyors will go tits up.
Fixes [...] are available – if you have a Cisco service contract [...] If not, you'll have to ask the Cisco Technical Assistance Center really nicely.
Twice I was in the position where I had to seek security fixes for Cisco gear with lapsed SMARTnet agreements. Twice Cisco came up with the goods, though not after a protracted 20-30 minute phone call with the TAC each time.
I really am grateful that Cisco is committed to supporting even lapsed equipment, but I have always wondered why they don't simply dump their security updates on their website. By all means Cisco, place them behind a registration wall so that you can collect whichever metrics are of interest to you, but is dedicating TAC resources to this truly worth the cost?
I mean seriously VPN software is supposed to negotiate a key, then take a packet, encrypt it, send it, take the next packet. It shouldn't be hard. Everything that is hard can easily be abstracted away into support systems which either are known to be moderately reliable (e.g. the operating system's DHCP-client) or run with low priviledges.
"UPDATED 2/5/2018: After further investigation, Cisco has identified additional attack vectors and features that are affected by this vulnerability. In addition, it was also found that the original fix was incomplete so new fixed code versions are now available."
Best get testing and patching again...
Biting the hand that feeds IT © 1998–2019