Slashdot Mirror


Malformed Packet Causes Cisco Router DoS

MoreBeer writes "Patch 'em if you've got 'em... Cisco Security Advisory: Cisco IOS Malformed OSPF Packet Causes Reload states that a malformed OSPF packet can cause a router 'reload' (reboot). Vulnerable IOS versions include 12.0S, 12.2, and 12.3 ... If you're not screening OSPF at your perimeter and using OSPF Authentication, now would be a GREAT time to start."

19 of 124 comments (clear)

  1. Setup OSPF by BoldAC · · Score: 4, Informative

    I notice that Cisco isn't displaying this on their front page. It seems like they should be screaming for everybody to fix the problem.

    Quick walkthrough that I usually reference:
    Easy example how to setup OSPF Authentication

    AC

    1. Re:Setup OSPF by w1r3sp33d · · Score: 4, Informative

      That would be the same front page that they didn't address the IOS source theft on for several days???

    2. Re:Setup OSPF by Cramer · · Score: 3, Informative

      The home page (www.cisco.com) is not where it belongs. Security notices are available at http://www.cisco.com/go/psirt That's where security people will be looking. (and they'll be subscribed to any number of Cisco emailed alerts.)

  2. Yeah, I better get things patched by Anonymous Coward · · Score: 5, Funny

    Before someone has a chance to reset my r

    1. Re:Yeah, I better get things patched by rwiedower · · Score: 5, Funny

      ...outer. Whew. It's a good thing that man-in-the-middle-attack is working like a charm now.

  3. It's simple really... by hot_Karls_bad_cavern · · Score: 4, Insightful

    at the risk of stating the obvious: if you were a new customer and went to a company's site and it was splattered with all manner of warnings, update calls, and exploit workarounds....would you buy that product?

    If you have a cisco, you should already know where the errata, update, exploit-watch pages are and read them everyday. You should already know this. Why would cisco put that shit on the front page?

    1. Re:It's simple really... by Davak · · Score: 3, Insightful

      If you have a glaring security hole, you better tell everybody to patch it because you risk losing your rep.

      Reference:
      Microsoft's previous security plan.


      I love it when I got a company's webpage and they say... "We found out about the error yesterday and we are posting the fix today. Thanks for your support."

      AC

    2. Re:It's simple really... by hot_Karls_bad_cavern · · Score: 4, Interesting

      "... If you have a glaring security hole, you better tell everybody to patch it because you risk losing your rep..."

      If you spent that much on the product, you should be the emails lists about that product. If you really spent a lot, there are plenty of companies that have closed lists for dissemenating exploit info extremely quickly...to the people that should know about it (ie, the people that HAVE the product. If you love reading that companies have fixed things so much, dig about on the site and find the pages with that info...not the front page. i understand what you are saying, but i'm trying to explain to the OP why this might not be on the front page of the site.

  4. Bleh by Rosco+P.+Coltrane · · Score: 5, Funny

    Patch 'em if you've got 'em...

    What a crock of shit. Everybody knows Cisco boxes are no route to host

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
  5. OpenBSD by Understudy · · Score: 3, Informative

    May I recommend OpenBSD with carp as a alternative.

    1. Re:OpenBSD by xrayspx · · Score: 4, Insightful

      No, in this case, I don't believe you may :-)

      I can't get 1 hour support for an Intel/OBSD server from a service provider with a worldwide reputation. If I do get such support, it would have to be guaranteed that they would have every combination of T1 and FastEther card in stock, power supply, etc that would possibly break.

      Sometimes standardization on one vendor worldwide is a GOOD thing. It's no problem to find Cisco support in Europe, South America, North America, Asia, etc. If a company has a router in Singapore and that router fails, would they rather try to find support for an OpenBSD whitebox, or call 1800-Go-Cisco and have someone go replace it immediately? Many international offices don't have full-time IT staffing, so there may not be anyone within an 8 hour plane flight capable of fixing the issue within the company.

      Cisco and the other infrastructure providers make a lot of money for a very good reason, people trust them and can get support anywhere they happen to be.

      Certainly, for a home user or single office with 20 people, one of whom is a BSD junkie, a Unix based router might be a fine idea. However for global organizations with multiple high-bandwidth links between branches, for example, for whom downtime costs many thousands of dollars per hour, there aren't very many options. It's a good thing that what options there are are very solid.

    2. Re:OpenBSD by Understudy · · Score: 4, Informative

      T1 cards are readily avaliable in PCI form

      OpenBSD at work

      Here is one example That uses 802.1Q VLANS.

      # Empire Net (now known as My180.net)
      An ISP in Bend, Oregon, uses OpenBSD on AMD, Intel, and Sun based hardware, for routing, firewalling, IPsec (VPN), bandwidth limiting, web hosting, database servers, network monitoring, intrusion detection, mail servers, backup servers, cache servers, and workstations. One of their OpenBSD routers handles traffic on between a T3 and eight fast ethernet ports, also with several 802.1Q VLANs to separate networks for co-location customers and business park tenants. An OpenBSD mail server handles e-mail storage/retrieval and RADIUS authentication for over 5,000 users. Several OpenBSD web servers each handle over 300 web sites.

      The Frame Relay over ATM (FROATM) is supported and this card works with OpenBSD. From the website:
      Sangoma's T1/E1 WAN cards have PCI bus interfaces and incorporate an integrated combination T1 and E1 DSU/CSU for a direct connection between the client's server and the demarc. The cards support major protocols including ATM, Frame Relay, PPP, HDLC and X.25 under all popular operating systems including Linux, Windows, FreeBSD, OpenBSD, Unix and Sun Solaris.

      You can look at the OpenBSD hardware list for more information.

      Currently Asterik (a VOIP system)is being ported to FreeBSD and OpenBSD. I am not sure if those are complete yet or not but, that can work in coordination with your Voice over ATM (VOATM) and Voice over Frame Relay (VOFR). I realize that VOFR/VOATM is not VOIP but the system is being designed with that support in mind.

      I realize this may not answer all your points but it will help.

  6. I admit by tomee · · Score: 5, Informative

    I had to look it up. OSPF

  7. Only IOS devices RUNNING OSPF are vulnerable by w1r3sp33d · · Score: 5, Informative
    That rules out most routers, and most switches. If you have followed best practices in your deployment, no internet edge device should be running OSPF so that shouldn't be a consideration, basically it should boil down to who within the company is trying to crash your routers?

    What a great time to post a link to www.routergod.com! Here are the two parts of Seven of Nine's lecture on OSPF:

    http://www.routergod.com/sevenofnine/

    http://www.routergod.com/sevenofnine/ospf_part_2.h tml

  8. This will work just as easily... by ewtrowbr · · Score: 3, Informative

    conf t

    access-list 150 deny ip 10.0.0.0 0.255.255.255 any
    access-list 150 deny ip 127.0.0.0 0.255.255.255 any
    access-list 150 deny ip 169.254.0.0 0.0.255.255 any
    access-list 150 deny ip 172.16.0.0 0.15.255.255 any
    access-list 150 deny ip 192.168.0.0 0.0.255.255 any
    access-list 150 deny ip 224.0.0.0 15.255.255.255 any
    access-list 150 deny ip 240.0.0.0 7.255.255.255 any
    access-list 150 deny ip 248.0.0.0 7.255.255.255 any
    access-list 150 deny ip host 255.255.255.255 any
    access-list 150 deny 89 any any
    access-list 150 permit ip any any

    interface
    ip access-group 150 in

    exit
    exit
    wr mem

  9. It's your own damn fault by JakiChan · · Score: 4, Informative

    To be honest, if this causes trouble for you then it's your own damn fault. If you accept OSPF packets from the Internet and/or you're not doing OSPF authentication then you deserve to be pwned.

    1. Don't use an IGP on an exterior interface.
    2. Don't send out routing updates on subnets/interfaces that don't need it. (For those of you with L3 switches that means using the passive-interface command on your vlans.)
    3. If your routing protocol offers an authentication option then use it.

    I used to think these things were obvious. Then I started interviewing other "senior" network engineers and realized they may not be...

    (BTW, kiddies, if you say you're a "senior network engineer" and you say that you know OSPF and I ask you if OSPF uses multicast or unicast and when does it use it/them then you had better be able to answer the question...)

    --
    "Where quality is like a dead stinking rat - you just can't miss it."
    1. Re:It's your own damn fault by Zarhan · · Score: 3, Insightful

      (BTW, kiddies, if you say you're a "senior network engineer" and you say that you know OSPF and I ask you if OSPF uses multicast or unicast and when does it use it/them then you had better be able to answer the question...)

      I know most of these things, altough I'm not sure right now (2 am, and I've been on vacation for the last three weeks) what (if any) are the considerations on point-to-point or p-mp (Non-broadcast) links or other more special cases. However, I wouldn't in my right mind call myself a "senior network engineer".

      Oh well, I guess it comes with the fact that the more educated you are, the more modest you get.

      However, I don't really thing that the details are too important. I know OSPF is a link-state protocol where every node in a network knows states of all the other links in an area and calculates Shortest Path using Dijkstra's algorith. IS-IS is similar. RIP is not. If I need to suddenly remember what exact numbering scheme was there for the link-types 1-7 I can always look up a reference (L5 are external routes, L7 are NSSA routes, cannot really remember the rest nor do I care? Show ip route ospf tells me all I need to know on whether it is intra-area or inter-area).

      Just pointing out that you really cannot evaluate someone's knowledge by posing questions about minor details unless you are perhaps hiring somebody with a CCIE (and then you can probably start with more obscure ones about DECNet).

      (Anecdotal note: I was hired as a trainee by my current employer probably because I confessed in the interview setting up LANs with IPX/SPX back in -94 so that all us kids could play Doom. I guess they went for the enthusiasm and my genuine interest. Granted, later I was able to shine when the boss was around and I was just discovering an obscure bug in two different vendors' BGP stacks timer synchronization - Don't know if that had any effect by I got hired permanently).

  10. In other news, by mobby_6kl · · Score: 3, Funny

    Malformed color scheme Causes Eyes to Bleed

    "Slashdot Security Advisory: Slashdot Color Scheme states that a malformed IT Color Scheme can cause a eyes to 'bleed' (fall out). Vulnerable /. sections include IT and Games. If you're not already using a /. deuglifyer, you should use the fix provided here."

  11. amusing failover problem with Cisco gear by SuperBanana · · Score: 4, Interesting

    A few years ago I worked at a place where we had two Cisco PIX (the 1U widgets, dunno what model, sorry) in a failover configuration. For those that don't know, you can run two kinds- stateful and non-stateful failover.

    In stateful failover mode, the two units share their connection state info over a dedicated ethernet crossover cable- in theory, if one unit's hardware shits the bed, the other one immediately notices and takes over, and all users will notice is maybe a few seconds pause in everything, if that. It's all very clean and good, the slave even takes over the MAC address of the failed unit (something they've patented, and hence isn't useable in Linux HA; Linux has to force an ARP announcement, which is messier. Goooooo Cisco!)

    Anyway, that's great, except when you have a software defect. Oh, say...where the PIX OS (PIXes didn't run IOS or whatever, they ran a separate OS unique to the PIX family) gets into a certain situation based on state and locks up hard.

    Well, guess what happens to its twin, running the same PIX OS version, and sharing the same data? Yup, it crashes too.

    The pair actually did it once right in front of us- one stopped blinking its lights...the master/slave light blipped on the backup unit, and then a few seconds later, it too crashed- and everything ground to a halt.

    It was terribly amusing that Cisco was incompetent enough to not include a hardware watchdog in the PIX box so that if it hung it would reboot itself; my Sonicwall SOHO has this, why can't a PIX for chrissakes? The problem only happened every few days, and would have been manageable(ie ignorable ;-) if they had both simply rebooted themselves. Instead, someone had to trundle in and power cycle both of them, until we figured out that it was state-based, and disabled stateful failover. Then someone just had to check every day to make sure one of them hadn't kicked the bucket.