Live data from Hacker News

D-Link patch doesn’t address all bugs listed in their own security advisory

devttys0.com

61–70 of 86 posts

Re: D-Link patch doesn’t address all bugs listed in their own security advisory

#61
post #32

this guy clearly has a passion for security. d-link could do well by firing whatever uncaring 9-to-5 programmers they have and hiring him. part of the problem is that people with this kind of passion and skill are few and far between... is very rare that good people want to work for a company like d-link on something like drivers or router software.

> d-link could do well by firing whatever uncaring 9-to-5 programmers they have and hiring him.

That's a great experiment to discover how long somebody can can stay passionate inside an uncaring corporation.

I give him 2 years to become an uncaring 9-to-5 programmer.

Re: D-Link patch doesn’t address all bugs listed in their own security advisory

#62

Earlier quoted context omitted.

Why would you still be comfortable using an incompetent company's hardware , even if you fixed the software issue? Does anyone do meticulous teardowns of routers, much less documenting what silicon is present?

The OpenWRT wiki pages for the routers usually has some detailed info about the hardware. That won't tell you about hardware problems they might have that they didn't investigate but you can usually find photos of the boards to see what's there. [1][2][3] [1] http://wiki.openwrt.org/toh/tp-link/tl-mr3040#photos_v10 [2] http://wiki.openwrt.org/toh/linksys/wrt610n#opening_the_case [3] http://wiki.openwrt.org/toh/netgea…

https://wikidevi.com/ also has detailed information about what chips are used, often gathered from FCC filings. Atheros, Broadcom, etc. are a lot more trustworthy than D-Link and Netgear. Once you've identified a router as having an Atheros SoC and a firmware update format supported by OpenWRT, you really only need to worry about it having bad power supply and antennas.

Re: D-Link patch doesn’t address all bugs listed in their own security advisory

#63
post #21

It's better to stick with OpenWRT or DD-WRT.

Care to share your opinion of why that is? Have you compared Tomato? What problems or deficiencies did you identify? More detail would be helpful.

OpenWRT tracks upstream software as well as the desktop Linux distros do, and it's what the upstream developers use. DD-WRT and Tomato put their own web interface on things but often leave important parts of the system out of date for very long times, especially when they're being held back by proprietary drivers. If you want to make full use of the features and stability and security of modern Linux networking, OpenWRT is where to start: you know you're getting proper IPv6 support, state of the art QoS stuff many DD-WRT and Tomato devs haven't even heard of let alone understand, and a current kernel.

Re: D-Link patch doesn’t address all bugs listed in their own security advisory

#64

Cheap SOHO routers: Sadly, you get what you pay for.

Paying more gets you better radios and more GigE ports. It doesn't get you less-stupid software. "Friends don't let friends run factory firmware" applies regardless of the price.

Re: D-Link patch doesn’t address all bugs listed in their own security advisory

#65
post #36

I inherited an office with a D-Link router being used that kept misbehaving. I tried upgrading the firmware as a last resort, since DDWRT and the others don't work on it. Digging around I found a thread where customers were wondering what happened to bridge mode and why it had been removed. An obdurate admin informs everyone that D-Link decided it wasn't needed as a feature, so they removed it. The admin is very coar…

> an even older Linksys WRT54GL That thing has been working for almost ten years (granted it is not an office environment), once with openwrt and now with tomato, while rebooting its little and adorable self every night at 3am automatically so that I don't have to. It's an amazing piece of hardware that makes one say "back in the day".

Ah, yes, a router that requires daily reboots. A real gem to reminisce about.

Re: D-Link patch doesn’t address all bugs listed in their own security advisory

#66
post #60

Earlier quoted context omitted.

>"This person does not do online banking, does not have a webcam or mic installed device such as a laptop, and does not have an email account." I don't know a ton about networking (probably not too much in fact) but doesn't HTTPS fix most of this? And if your laptop grants access to its mic/webcam to any packet that manages to make it past your router, I think you have a bigger problem.

Most devices trust their router a lot . HTTPS on its own doesn't protect you from a malicious router. Strict Transport Security and Certificate Pinning are also necessary for HTTPS to protect you against an evil router, and even then it does nothing about all the unsecured and weakly secured traffic and devices on your LAN and all the opportunities that come from being able to lie about DNS records. If you can't trus…

>If you can't trust your router, you really just have to initiate a secure VPN connection to a network that isn't out to get you.

:(. that's really frustrating. So you really need to vpn to a secure network anytime you use free Wi-Fi?

Re: D-Link patch doesn’t address all bugs listed in their own security advisory

#67
post #40

Earlier quoted context omitted.

Why would you still be comfortable using an incompetent company's hardware , even if you fixed the software issue? Does anyone do meticulous teardowns of routers, much less documenting what silicon is present?

Yes, typically home routers tend to use pretty industry standard chips like Broadcom chips (like the BCM5357 in my home router). D-Link, Linksys, and crew don't usually roll their own SoCs, but just seem to throw off the shelf stuff in there. These chips tend to be SoCs, and while I can't be totally sure that there isn't a weirdo NSA backdoor on it (probably just as likely as any other router, residential or commerci…

ARM? I thought most routers used MIPS. At least several of the ones I've used are.

Re: D-Link patch doesn’t address all bugs listed in their own security advisory

#68
post #60

Earlier quoted context omitted.

Most devices trust their router a lot . HTTPS on its own doesn't protect you from a malicious router. Strict Transport Security and Certificate Pinning are also necessary for HTTPS to protect you against an evil router, and even then it does nothing about all the unsecured and weakly secured traffic and devices on your LAN and all the opportunities that come from being able to lie about DNS records. If you can't trus…

>If you can't trust your router, you really just have to initiate a secure VPN connection to a network that isn't out to get you. :(. that's really frustrating. So you really need to vpn to a secure network anytime you use free Wi-Fi?

Yeah. With the right security software on your device and the right options on the server you could theoretically initiate a properly secured connection with some web sites, requiring DNSSEC, STS, etc., but for general purpose use you need the VPN.

Re: D-Link patch doesn’t address all bugs listed in their own security advisory

#69
Factory firmware on SOHO routers is notoriously terrible. You'd think that this would be a good place for a startup to disrupt. The hardware is basically off-the-shelf components. It would be an easy sell to experts, but maybe harder to get traction with most people.

Re: D-Link patch doesn’t address all bugs listed in their own security advisory

#70
post #12

Earlier quoted context omitted.

Writing completely secure C is hard, but this code is littered with extremely basic bugs like unchecked sprintf and not sanitizing arguments to system. Like, it's a basic rule that you should use snprintf instead of sprintf, possibly with exceptions for cases where you're absolutely sure the result fits in the provided buffer, and in this case there is sprintf everywhere and no checks on the input size whatsoever.

I wonder where this "length blindness" comes from, since it certainly leads to a lot of vulnerabilities. Are these programmers who started with a higher-level language than C, one with dynamically sized strings that automatically expand? Do they even know how big the buffer is, or how long the input string could conceivably be? Did they ever consider the case where the input is very, very long? A funny analogy I've h…

Just to hazard a guess, there's probably little organizational incentive to prevent security issues in the first place.
Post reply on HN