Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
The Internet Bug Programming IT Technology

Netgear Routers DoS UWisc Time Server 447

numatrix writes "For the last few months, hundreds of thousands of netgear routers being sold had hardcoded values in their firmware for ntp synchronization, causing a major denial of service to the University of Wisconsin's network before it was filtered and eventually tracked down. Highlights how not to code embedded devices." A really excellent write-up of the incident.
This discussion has been archived. No new comments can be posted.

Netgear Routers DoS UWisc Time Server

Comments Filter:
  • So who got fired? (Score:4, Interesting)

    by eln ( 21727 ) on Friday August 22, 2003 @01:25PM (#6766622)
    Simple mistake that should have easily been found and fixed during the testing phase. I hope whoever let this thing be released without following proper testing procedures got canned.

    Yah right. Some hapless low level programmer probably got all the blame for putting test data in there in the first place.
  • by Jammer@CMH ( 117977 ) on Friday August 22, 2003 @01:27PM (#6766666)
    Were this a Haxor attack, there would be criminal liability. I'm willing to believe that it was a simple mistake, with no criminal intent, but would NetGear be liable civilly?
  • by eaddict ( 148006 ) on Friday August 22, 2003 @01:28PM (#6766669)
    to hardcode an address into thier systems? Do you need permission? There was a law a few years ago about 'deep-linking' and even linking... isn't getting the time somewhat the same thing?
  • by joeldg ( 518249 ) on Friday August 22, 2003 @01:28PM (#6766673) Homepage
    Wow, that list of Analysis Tools used for tracking this down had a bunch that I was not familiar with.

    RRGrapher, FlowScan and Cflow being ones I have never messed with..

    Cool.. new tools to play with!

  • Re:Err why ? (Score:5, Interesting)

    by rusty0101 ( 565565 ) on Friday August 22, 2003 @01:42PM (#6766821) Homepage Journal
    Routers tend to log activities such as access, configuration changes, firewall violation detection, etc. and it is often handy to know when that event occured.

    Home centric routers do not tend to have their clocks set before shipping as there is no assurance that a battery keeping that clock powered will be doing so ver the entire span of time from manufacture to customer plugging it in. Even if it did the drift involved would give some inaccuracy as well.

    There are two correct solutions. One is that Netgear should operate their own time server and hard code that server as a secondary or fallback time server. The primary time server should be aquired from the internet service provider when they get their network ip address via dhcp.

    -Rusty
  • Re:So who got fired? (Score:3, Interesting)

    by (54)T-Dub ( 642521 ) * <[tpaine] [at] [gmail.com]> on Friday August 22, 2003 @01:46PM (#6766868) Journal
    100 MBits/second !?!?!?!?! Do you have any idea how much bandwidth that is?

    About once a month a link to my company goes up on the MSN home page (about 3 links down in the top news section). It's like a firehouse and that peaks at an insane 14MBits/second.

    Expecting a public service to handle 100 MBits is ridiculous. It was an erroneous mistake by netgear and there should be severe reprecusions.
  • by ShortSpecialBus ( 236232 ) on Friday August 22, 2003 @01:50PM (#6766906) Homepage
    want to see what the usage graph for a slashdotting looks like?

    http://www.cs.wisc.edu/cgi-bin/cricket/grapher.cgi ?target=%2Fweb-servers%2Fwww;ranges=d%3Aw;view=Acc ess [wisc.edu]

    Yeah, I work at the CSL at UW Computer Sciences, and the tracking of this netgear issue was quite an interesting tale. Had us stumped for quite some time.
  • by Anonymous Coward on Friday August 22, 2003 @01:51PM (#6766911)
    This didn't only generate trouble for U of Wisconsin, it also generated a lot of cost for some people using the router. Since the server was down, the Firmware has been trying to connect to the time server constantly, thereby keeping the connection from timing out. (Who wrote that algorithm?) For people whos connections are on metered internet access, this ment the connnection was never closed and they are stuck with the bill.

    Aparently there are a lot of Netgear users in Germany who are stuck with horrendous bills now. I wonder if Netgear is going to pick those bills up?
  • by seanadams.com ( 463190 ) * on Friday August 22, 2003 @01:53PM (#6766924) Homepage
    They probably would be liable. What surprised me was that the article made no mention of the financial impact of the flood... are the guys who run the network so far removed from the guys who pay the bills that they have no idea, or do the universities get such sweet deals on bandwidth that it doesn't matter?

    I mean, we're talking 150+ Mbps here, for months on end. That's $15K/mo in bandwidth, assuming they have a really good deal and pay only $100/Mbps/mo.
  • Re:Think Strata (Score:3, Interesting)

    by eaddict ( 148006 ) on Friday August 22, 2003 @02:19PM (#6767171)
    Which is exactly what we did. We have a smallish IS shop: 200+ MS/Novell server, 100+ HP midrange servers, and bazillions of PCs. We put our own time server up which ALL of our corporate systems hit. That server then hits a service available via satellite. It is a lot cleaner and 'nicer' to do things in house than rely on some not-for-profit organizations generosity. I even have my PC at home hit my work time server (when I use the VLAN to connect).

    Just my $0.02
  • Re:Who pays? (Score:3, Interesting)

    by confused one ( 671304 ) on Friday August 22, 2003 @02:30PM (#6767262)
    It seems UofW is putting a "redundant fault tolerant server" at the border of their network to handle the traffic. Perhaps, Netgear should compensate them for the cost of the machine and the bandwidth...

    Just a suggestion.

  • Re:So who got fired? (Score:2, Interesting)

    by krist0 ( 313699 ) on Friday August 22, 2003 @02:37PM (#6767335) Homepage Journal
    bah, weaklings,

    when i worked for a ISP over here in .nl, we hosted the live streaming of big brother...

    300mbit/s out, on old cisco 7500s....had to get new gig cards for it...the original GEIPs started borking....

    heh, everyone needed their vouyerism fix.
  • by altek ( 119814 ) on Friday August 22, 2003 @02:38PM (#6767353) Homepage
    This is funny - one of the head sysadmins for UW's network ops gave a firewall talk in one of my grad classes last semester. I remember him saying that they recently put a packet filter on their FW to block NTP requests because they started getting high numbers of them..

    They thought that maybe somewhere someone had published a net time server in a document or whatever and that an IT department was deploying it on workstations or there was a document floating around telling people to set it up as their time server...

    Looks like they finally got to the bottom of it!
  • Comment removed (Score:3, Interesting)

    by account_deleted ( 4530225 ) on Friday August 22, 2003 @02:39PM (#6767359)
    Comment removed based on user account deletion
  • by whterbt ( 211035 ) <m6d07iv02@sneakemail.com> on Friday August 22, 2003 @03:52PM (#6768067)

    I took a Unix course at the University of Colorado in Fall 2001, I think. We had a guest lecture from Evi Nemeth [amazon.com], who is a professor emeritus at CU.

    She had done some work on a couple of the DNS root servers, G and H if memory serves. She showed a rate of query graphs for those servers. There was a huge jump in the middle of the graphs that corresponded neatly with the release of Windows 2000.

    Turns out Win2000 had it hard-coded to consult the DNS root servers every time it wanted to run a nslookup!

  • by MojoRilla ( 591502 ) on Friday August 22, 2003 @03:53PM (#6768076)
    We had customers complain that they couldn't connect to our streaming application. After much head scratching and wasted time, we discovered that the customers MR814 wireless router wasn't working properly.

    After a lot of research on the internet, I discovered that this was a well known problem with the MR814, fixed with an update to its firmware. It was strange because I asked the user if he had updated his firmware, which he said he did.

    It turns out that the firmware was only released on the Austrilian version of the NetGear website. Downloading and installing that version fixed the users problem.

    I sent a polite note to NetGear technical support informing them of this on April 7th. I got back a note on 4/8 saying that it would be forwarded to the appropriate people. On April 17th I sent a more harshly worded note. On April 20th I got back a note saying again that my request would be forwarded to engineering.

    I gave up. It wasn't worth it.
    Just for fun on May 13th I checked their site again. They had finally updated the software.

    This runaround was all to just make a solution to a problem that they had already fixed available. Imagine the hassle trying to get them to actually fix a problem?
  • Windows Time Service (Score:4, Interesting)

    by Webmoth ( 75878 ) on Friday August 22, 2003 @04:55PM (#6768681) Homepage
    Both Windows 2000 and XP have the "Windows Time Service" which once per day query an NTP server to set the system clock. By default, Windows 2000 does not have an NTP server set, and XP looks to time.windows.com -- every blasted installation of Windows XP phones home every day to set its clock and who-knows-what-else.

    One would expect millions of XP boxes phoning home daily would overload a time server. For myself, I've changed the NTP server to a different server (which I will not name) and had somewhat more reliable time syncing.

    The commands are net time /setsntp:some.ntp.server and net time /querysntp, or in the Time and Date properties in XP there's the Internet Time tab.
  • by Jayfar ( 630313 ) on Friday August 22, 2003 @06:40PM (#6769494)
    I didn't notice it when I first installed my Netgear RP614 last fall, but several months ago I noticed that my dsl modem and RP614 activity lights were blinking once per second round the clock. Just in recent days it occurred to me that this activity had stopped. Having read the article (sorry I do that once in awhile, /. tradition notwithstanding) I see that UWisc's stopgap solution a was to begin servicing the sntp requests again and as such my Netgear device no longer feels compelled to query them every second

    As a side note, one thing that frustrates me about the RP614, although I'm otherwise happy with it, is that even though I can choose an option to allow ping to function, it still wont allow other types icmp traffic through and renders traceroutes out from my workstation useless.
  • by grozzie2 ( 698656 ) on Friday August 22, 2003 @06:47PM (#6769541)
    I'm chuckling, cuz this has got to be the most informative /. thread in a while, but the useage graph kinda made me laff a bit. I work with code in tiny embedded devices all day long, so, I read the article with GREAT interest, and particularily the paths taken to resolution (which appears to be an ongoing thing).

    My hat is certainly off to you folks, it's so refreshing to see somebody facing a serious problem, and actually go about the course of identify and deal with it, with no mention of 'sue them' etc etc. Instead, the problem was identifed, tracked, and eventually the root cause discovered. At that point, they stayed on the high road, and went thru the company to address it, even though initial contacts were 'problematic'. My expectation from most americans after that root cause was discovered, would be for them to get a bidding war going between various law firms as to who could garner the largest settlement, and only then make contact with Netgear, via whichever law firm was bidding highest.

    I sympathise with the problem, and I can sure see how something like that slipped thru various pre-release testing cycles (or possibly the lack thereof). The article has definitely made me step back and think about how 'accidental' things like this can slip thru, and possibly consider a new set of release testing parameters to catch such accidents. The /. boys (and girl) are having fun screaming for the head of the folks that caused the problem, but I think there's a valuable lesson in this, made much more valuable by the paths taken towards resolution. It's so refreshing to see non confrontational co-operation in a case like this. That's the kind of spirit that makes the open source world thrive, and it can apply to more than just 'lines of code'.

"Gravitation cannot be held responsible for people falling in love." -- Albert Einstein

Working...