[cust-security-announce people: The quoted paragraph is from a posting on "bugtraqat_private"] Yet again, I have to remind y'all that sending these to BUGTRAQ will not get you as fast a response as sending them in directly. At least not from Cisco; can't speak for 3Com or anybody else. This is very preliminary information for Cisco routers; I just saw the message I'm responding to about an hour ago. There may be more going on than this. We'll continue to test and characterize this, and will send out updates as appropriate. > The tcp access / configuration ports on most routers can be disabled > remotely. These sit on port numbers like 23,2001,4001,6001, and 9001. > The attack simply consists of shoving a few thousand bytes of any > character down the connection, a couple times may be needed for some > routers, with the length of time of the DoS related to the amount of > bytes you send down the initial connection. Some Cisco's would have to > be reset manually to fix this, others will recover by themselves given a > few minutes, hours, or days. ComOS seems to be in the manual-reset > category, as I haven't found one yet that recovers from a 1 minute > attack onto thier access ports. Normal operation continues, only in a > few freak cases did the router drop the entire network / reset > connections as a result. I was able to reproduce something like this. At least in my tests, it appears that the router isn't noticing that the TCP connection is being shut down by the initiating end. I don't yet know why; it could be a bug on either end. I'll assume it's a Cisco bug, and report it as such, but it would be interesting to know what sort of machine you were using for your testing. I'm using Linux 2.0.x with netcat as the traffic-sending program. Since the TCP connection isn't deleted, the virtual TTY (VTY) is not being released. If you run a bunch of attacks, you eventually end up with all your VTYs hung up on nonexistent connections. If you can reach the router at all, you can reclaim them with the "clear line" command, but if they're all hung up, you may not have a way to get in and do that. Although the router's getting into this state under these circumstances is very probably caused by a bug, and we will address that bug, it's very important that everybody understand that it would be possible to create the same condition *without* any bug. The easiest way would be to keep opening (and not closing) TELNET sessions to the router, until it refused to accept any more, then simply turn off the power on the initiating system, so that the sessions were never closed properly. That's just the way TCP works. It affects any system that accepts TELNET connections and doesn't use TCP keepalives. It may be aggravated by a bug in this case, but you can definitely make it happen without having a bug. There are several ways to mitigate this vulnerability in your Cisco configuration: 1. Don't accept TELNET connections from just any old host on the network. Do something like this: access-list 1 permit host <trusted-host-1> access-list 1 permit host <trusted-host-2> ... access-list 1 deny any line vty 0 4 ! Select all 5 VTYs transport input telnet ! Don't accept non-TELNET connections access-class 1 in ! ... and only from listed machines We very strongly recommend this configuration for *all* Cisco devices, regardless of this particular issue. It's just plain bad practice to let everybody on the Internet make interactive connections to your router. This is known to work, and should be the primary defense. 2. Configure "service tcp-keepalives-in". This will make the router detect dropped TCP connections. By default, it won't detect a dropped session unless it has output to send to that session... which it usually won't have for a long time, if ever. I have not fully verified that this one works against the "shoving bytes into the connection" attack; I can't reproduce the failure reliably enough to be sure that I've eliminated it. I would expect this to work. Even if it doesn't end up being a solution for this situation, it's a good idea in general. 3. Configure timeouts on the VTY lines, so that an idle session can't permanently occupy a line. You might do: line vty 0 4 exec-timeout 10 ! Disconnect if no commands for 10 minutes session-timeout 10 ! Disconnect if outgoing session and no input I don't think that this one will work with this particular problem, because the failure is at the login prompt. It's a good idea, though, if you want to keep your VTYs from being eaten up over time by dead sessions. It may be a few days before we have more information than this. -- J. Bashinski Cisco Systems Product Security IRT
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:32:52 PDT