That NetBIOS bug in full: readers have their say
You're safe. Just turn off your networking.
The debate over a flaw that Network Associates' PGP labs found last week in Windows networking continues to rage, judging by our mailbag.
PGP's COVERT lab reported that a single packet sent to a particular common networked Windows client configuration can divert users to a rogue IP destination. The advisory cited a case where a machine inside a corporate LAN (or an unprotected home network) could be used to capture names and passwords.
Several readers wrote in to point out that the editor of the NTBugTraq security mailing list Russ Cooper, contestedPGP labs' view of the issue as "high risk."
Cooper writes that blocking the vulnerable ports used by Windows networking protocols is standard best-practice among diligent BOFHs.
"I'm not admonishing the very detailed and well-written technical portions of the advisory," he wrote, "but IMO the designation of "HIGH RISK" does NAI, COVERT Labs, and the readers of NTBugtraq a disservice," he writes. He points out, as several readers do, that security was never a part of the NetBIOS spec. As a consequence, he says, it's "more hype than not".
But is it?
He's quite right - competent LAN administrators should be aware of the vulnerabilities on these well known ports. But this might be a case of preaching to the converted.
It's not just corporate LAN users who'll be at risk. Because of the potentially explosive mix of Windows networking - which is ubiquitous, easy to set up for novices (and even more so with Microsoft Internet Connection Sharing facilities built into Windows 98, Me, and 2000) many home users will be potentially at risk too.
As Cooper points out: "I have no doubt there are many non-home networks that may not have these ports blocked, I don't believe they're amongst the readership of NTBugtraq."
No doubt they should be - it's mandatory reading for anyone concerned with Windows security. But where does that leave the great unwashed?
Imagine (and for British readers, this will alas require more imagination than for our American readers, who can sign on to a fixed-IP DSL or cable broadband right now) a home network in which several PCs are linked via a single dial-up or broadband connection.
Since the US has a higher penetration of PCs in households, and a far larger number of multi-PC households, this puts many people into the potential risk zone. Naturally, these folk should all be running softwalls, but if they're not, are they sitting ducks?
Robert Woodcock, maintainer of the Debian GNU/Linux bug reports mailing list, tells us that he tends to agree with Cooper. But he suggests several scenarios where a cable user or corporate user could find themselves potentially compromised. He points out that only the PC connected to the Internet is vulnerable, and that the target in the Network Neighborhood would have to be on the same workgroup.
Mind you, that's just the scenario you get where Dad's PC in the den is connected to the modem, and that's linked up to Junior's PC upstairs via ICS.
Robert writes that LANs are more vulnerable: "This would be much more interesting from inside a company network. Just do some passive sniffing for ARP traffic to see who's initiating connections to who, make a list of the busy servers and their names, get the IPs of the desktops from the ARP traffic, and throw these packets out at random desktop computers. If they're all Win95 machines, your hacked-up Samba server running at a debug level of 99 is bound to get a few dozen passwords." He points out that more recent Windows versions don't actually send out passwords as cleartext over the LAN: more recent versions have fixed this.
Reader Bernd Backhaus suggests the sledgehammer approach, pointing out that "binding NetBIOS to the IP-Stack is generally a bad idea (and most people should know by now)" .
So the answer seems to be, get thee behind a firewall, and if you want to make really sure, turn off Windows networking.
When Microsoft's own security gets back from the Labor Day break, we hope they'll have an advisory of their own. ®
Sponsored: Protecting mobile certificates