Slashdot Mirror
Cisco IOS Source Code Theft Story Continues
securitas writes "eWEEK's Steven J. Vaughan-Nichols reports that the source code for Cisco's 'main networking device operating system was stolen on Thursday' (May 13) according to the Russian company SecurityLab. SecurityLab says that criminals broke into Cisco's network and stole 800MB of source code for IOS 12.3 and IOS 12.3t, a pre-release variant. The purported culprit(s) then bragged about the feat in an IRC session and offered 2.5 MB of the code as proof. Industry analysts Dell'Oro Group says that 'Cisco owns 62 percent of the core router market.' More at the Sydney Morning Herald and Windows Network magazine." Our original coverage was here of this story.
Having had a look at some of the source code, I'm generally impressed. Cisco's code is solid. It's perhaps a bit more simplified than what you'll see in BSD's ipfw source, but simpler is better when you're talking about mission-critical applications. IOS is responsible for switching packets on a fair amount of heavy links; ipfw is responsible for switching packets at your average LAN.
I don't think the IOS leak is going to lead to any new vulnerabilities. Cisco produces solid code. The only real interesting thing we may see is backdoor-style commands to IOS that the public is not aware of.
--
Free Naked Pics
"A previous major source code theft of parts of Microsoft's NT 4.0 and Windows 2000 has not led to any security violations."
Uhh...wasnt there a serious problem in the code for parsing bitmap files discovered? wasnt there a virus that started spreading whenever a bitmap was viewed based on the exploit found?
I recently finished CCNA training and asked the instructor what OS CiscoIOS was based on and I was told it's based on BSD OS. He didn't tell me which BSD though....
My one thought: it's all bullshit until Cisco comes out and says they were hacked. Anyone can put together a bunch of seemingly well-written code and say that they were l33t and got in to Cisco.
The proof is in the pudding. And all I see so far is some sugar.
Chris Knight is my hero.
Sorry, but if this is true and the full source code has been released to the public, I can pretty much gurantee you there will be vulnerabilities found. The likleyhood that in the entire codebase, there exists not a single flaw is scientifically insignificant. We may not see any vulnerabilities the likes of "print 500 A's on login: " but you can bet there's something that will let someone do something they aren't supposed to. The chances of vulns coming from this are alot greater than the chances more vendor implemented backdoors are found, and that wouldn't suprise me in the least.
Everyone is entitled to their own opinion. It's just that yours is stupid.
Am I the only one who thinks this 'might' be a good thing? Cisco now has incentives to give their code another look and hunt down any serious bugs they might not know about yet, resulting in a more secure OS. I doubt it would happen, but it's what I would do if my source code was stolen.
"Two direct links on the front page of slashdot to (literally) stollen IP?"
Not literaly, but metaphoricaly. It would have been "literaly" stolen only if the source code disappeared from Cisco's servers.
Well ... is it not kinda strange? A few months back when the Windows code was leaked, most of Slashdot was screaming about 65,000(i dint cook that number!) Windows bugs. Well, nothing happened really. Except an IE 5.x bug, which was patched silently before the source code leak.
... Slashdotters, cant it be just possible that this leak might be much more disastrous that the Windows leak.
... its funny reading that Windows article again, and going through posts that talked abt non-existant security in Windows. And how many holes did people find.]
Now lets compare the REAL security issues.
1. The number of people who were dissecting the Windows Source Code are much more than those trying to find a Cisco hole.
2. Even without the Windows Source, we can reverse engineer large parts of the Windows Sources and identify problems. With the leak it just became easier. I dont expect too many crackers trying to find holes in Cisco's IOS.
This simply means that the chances of finding a security hole in Cisco is much higher than in Windows. Because now that the source is out in the open, its easier. Why would they choose to look?
1. Bringing down those routers could virtually bring down most of the internet.
2. The entire financial world uses them! If a hole is discovered it might just be the easiest way to get into those systems.
3. It could be easier than trying to find a Windows hole, since (as from my earlier logic) many many people have already tried without results.
4. The damage that could be done in those 2 cases are so immense, that a comparison would be irrelevant.
[Troll: Btw
Here's my prediction of the effect that this will have on Cisco's sales, and on Cisco's share price. Zilch.
I don't know anyone who's choice of Cisco products was predicated on the closed source nature of IOS. IOS will work the same as always, except that now Cisco might be motivated to go on a massive bug squashing expedition. They might also be compelled to close some back doors. I expect the next version of IOS to be better than ever.
Which leads to the question: Why is IOS closed source in the first place?
I've looked at the sources on display at the russian site [IPv6 sources], that pretend to be from the IOS. Several things took my attention: :) ;)))
1. Since when programmers, working for a serious company, write copyright notices for themselves in the header... Like if you work for, let's say, SCO (ha-ha), you will put in the header copytight by you, and then - who knows - might sue SCO for stealing code from you
2. printf("\nAdding %P to ND cache", &target);
The ND cache is really connected to neighbor solicit messages, but would the Cisco IOS be printing a message, saying that it is adding the address to the ND cache without checking debug flags, etc.? And I am sure it is not a matter of system design in this case. You cannot get the impression just from one tiny piece of code.
3. Some post here were stating... "root" access, which certainly made me smile. The IOS is running cooperative multitasking and the tasks usually run at the same level.
4. Ole Troan really works for Cisco Systems (in UK) and is the proud author of the IPv6 DHCP RFC specification 3633. So this is an argument that supports a little bit of the theory. Just didnt think that Cisco still has developers in UK. I thought they outsourced everything to India long time ago
There are some more, but I'll save you the tiny details, like big endian or other nifty stuff in the code.
SECURITY BY OBSCURITY DOES WORK
*sigh* And, of course there's going to be a troll like this.
No, it doesn't, but thanks for playing. See, someday maybe you'll learn the painful lesson that Cisco is learning now: Security Through Obscurity only works as far as your REAL security measures can protect it. Gee. Looky there. Cisco's cat just left the bag, and why? Becuase the network security wasn't strong enough to protect it. All these years of obscurity are now on the brink of becoming completely worthless because the REAL protection wasn't there just long enough to let it happen. The second that code hits a public FTP server, STO at Cisco became absolutely useless.
But, hey. If you want to rely on STO for anything more than your last line of defense, be my guest. Just promise me you won't be mad when I laugh at you for getting burned by it.
Alito: A vote for Alito is a punch in the eye to put that bitch back in her place!
Yes, provided it's solid code. So the obvious question is: is it solid code? What makes for solid code? I'm of the opinion that it is far from 'solid' code for two main reasons.
The history of the code base.
It's monolithic nature.
IOS started out on the same CPU board as Sun (and SGI) computers: The Stanford 68000 board. Remember what Sun stands for: Stanford University Network. These three companies all started from the same hardware design. Cisco took this design and the original software for running the Stanford networks (some allege they stole it) and kept adding on to it. The 68000 had no MMU, and therefore provided no protection of one process from another- any process could write to any part of memory.
The problem is that the software still has this in its genes. While IOS will make use of modern MMU's to do some level of protection (such as marking read-only the text segment), at its core its still a "every process is fully trusted" design. Now, this does have some advantages- in the old days when the forwarding was all done on the CPU in the interrupt context this was a huge win. Saving all the state and MMU context switches could really lower performance.
The drawbacks, however, are pretty bad IMHO. Since there's no separation of processes, any one process can bring down the system. If BGP was running under Unix, and it ran in to a problem where it would seg fault, under IOS the entire system would panic and reboot. IF it happens to catch the error, which is much less likely to happen because there's no separation of processes and what memory resources belong to that process as opposed to other processes.
The monolithic nature of IOS also tends to breed lax programming practices. Who needs to ensure that everything is tip top when everything is self contained? There's a certain darwinian pressure that gets placed on a system when anyone can write code for it and expects the system to stay up and running like Unix. Under IOS, none of that exists. As a matter of fact, the pressure is in the opposite direction- when you write something that crashes the system- don't do that. Furthermore, the code tends to largely interact with only a few other implementations, and the one it interacts with the most is itself (cisco's talking to cisco's). Not a lot of pressure to find those odd ball corner cases and fix them... Just the kind of corner cases that are the most likely to result in exploitable bugs.
So, are there security problems with IOS? You'd better believe it. All you have to do is peruse the BugTracker database and look for bugs that cause a crash. Things like "malformed SNMP request causes crash" are prime candidates to exploit.