Cisco Confirms Regex Flaw in IOS
gattaca writes "Cisco has announced a confirmation of an unpatched denial of service vulnerability in Cisco IOS. From the NetPro Forum post: 'I have just discovered a regular expression that crashes the router. I suspect the error is because of division by zero. Since I work for the Enterprise, I do not have direct access to TAC. Please somebody report this to Cisco. I have tested it on ranges of routers (2611, 2821, 2851, 7206) and IOSes (12.0-12.4). All routers crashed with some type of BUS ERROR.
Command can be issued in user mode, therefore I think it can be considered as vulnerability to potentially cause DOS.'" Of course, the command has to be entered in user mode, so while potentially a vulnerability, chances are your local IOS-based router won't be DoSed via the bug any time soon.
if your own people have to do it?
Nitpick: if it were a division by zero fault, would it really trigger a bus error, or more likely a ... division by zero error?
There are no karma whores, only moderation johns
BUS ERROR
FTA: "I have just discovered a regular expression that crashes the router. I suspect the error is because of division by zero."
Reminds me of:
Patient: "My arm hurts when I do this." <wiggles arm>
Doctor: "Then don't do that."
The solution is obvious: don't use that regex/divide by zero. Duhhhh. Problem solved. Thank you, come again.
$slashheading =~ s/stuff that matters/bug reports/i;
OH SHI-
Infiltrated dot Net
"Since I work for the Enterprise, I do not have direct access to TAC. "
Yes, Capt. Kirk can be very protective of the TAC.
Alex, I'll take keybindings not used by Emacs for $400....
Writing code that can parse for any given syntax is, well, pretty much as difficult as writing a parsing front-end to a compiler.
I.e. it is not trivial and it is fraught with danger.
Any time you allow the user to submit arbitrary, un-screened, un-filtered data, you're just asking for trouble.
Of course, I guess you could argue that the job of a RegEx parser is precisely to do the screening & the filtering for you, but it is not a trivial business, and anyone who approaches the problem as though it were a mere triviality is a fool.
I.e. from the security point of view, the RegEx parser is a firewall [and, in all likelihood, is the only firewall], hence anyone writing a RegEx parser has to assume that the user submitting the input is a blackhat, not a whitehat.
PS: And the problem undergoes manifold [if not infinite] complexification when you're dealing with languages [or "environments"] like HTML, Javascript, and XML, which can re-write themselves on the fly.
There are many routers out there running IOS that are used for Looking Glass purposes, so, yes, this is a problem I guess..
Dividing by zero screws everything up. Even Windows Calc, one of the most advanced pieces of software on the planet, can't do it.
To be fair, there IS a story here, which is that Cisco only just acknowledged this officially.
Service Provider types (the operators of routers whose successful attack would actually affect anyone in the real world) have been well aware of this. But as others have pointed out, if you don't trust your admins, and you're not running proper logging and a proper audit trail of admin sessions already, you've got bigger problems than this.
Everything I needed to know about life, I learnt from Blake's Seven
Can someone explain to me the difference between a $50 OpenWRT router and a $2k Cisco one? I have both, and the OpenWRT router is by leaps and bounds more featureful than the Cisco one (I guess that doesn't really make sense, because for $20k the Cisco can have the same features). Obviously the difference is reliability/performance, but what are the exact limits? How many people do I have to have in my network before getting a Cisco? How will I know that?
Send email from the afterlife! Write your e-will at Dead Man's Switch.
In case anyone cares, the reboot (or "reload" as cisco likes to call it) is caused by a stack overflow resulting from an uncaught recursive processing of specific combinations of regex options. The overflow must be input from the command line interface, after providing a valid username and password to login to the device. If you are being DOS'd by someone that has a valid login and password on your hardware, you have bigger issues that need dealing with before investigating firmware bugs in your router.
I work for the Department of Redundancy Department.
If a rogue has CLI access to your router, you have bigger issues. Proper filtering, TACACS and Logging, Out of Band Management makes this a non-issue.
The risk is almost the same as "reload" or the even more fun undocumented "test crash" commands.
Granted I do not think this vulnerability requires "enable" access, which does increase the risk. However, nobody should have any CLI to a router that you do not trust.
That said, I'm on AT&T's route server right now and I can clearly see that it's been abused by the regex bug:
Note the uptime and line noting the reason for the last reboot.
So, in short, looking glasses aren't susceptible to this bug, at least none of the dozens LG projects I've seen are susceptible to this). However publicly accessible route servers that are IOS-based and not run on Juniper routers or Quagga may very well be susceptible if the admin hasn't secured the box.
Since I did a "show buffers all" on a 4948 and it reloaded the box. General rule I follow is that if you have to have root access to do something, it's not a vulnerability. This is just a TAC case/bug fix.
www.traceroute.org -> LookingGlass list.. First one (AS137), does offer regexp 'forms'..if the gear behind the scenes is an IOS box... There are others in the list, but, you get the point..yes, a looking glass can be vulnerable
If you can telnet to the router's IP address and it doesn't block you (i.e. if there's any kind of remote administration), you get user exec mode. Good job.
Support my political activism on Patreon.