I guess this is a reminder that writing secure C is actually really, really hard.
I don't write C at all but aren't there code analysis tools that catch things like this? Some kind of standard code linting library, maybe?
D-Link patch doesn’t address all bugs listed in their own security advisory
11–20 of 86 posts
Re: D-Link patch doesn’t address all bugs listed in their own security advisory
#12I guess this is a reminder that writing secure C is actually really, really hard.
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.
Re: D-Link patch doesn’t address all bugs listed in their own security advisory
#13I guess this is a reminder that writing secure C is actually really, really hard.
I don't write C at all but aren't there code analysis tools that catch things like this? Some kind of standard code linting library, maybe?
Yes, the point is that these are obvious flaws, and dlink didn't even fix them. Someone from the dlink team just sucks.
edit: And that someone may not even be the developer, at the end of the day, the company does not have the systems in place for quality control.
Re: D-Link patch doesn’t address all bugs listed in their own security advisory
#14I 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 coarse and ends up locking the thread.
It seems ridiculous that, for a hardware product, a company would decide to remove features in a firmware upgrade. There is a work around, but even if it is a legitimate thing to do, it seems like a terrible product and engineering culture to be this condescending to customers.
Relevant thread: http://forums.dlink.com/index.php?topic=4542.0
End of story: The router ended up going in the trash after other issues, along with two different D-Link models.
It's not the best idea to use consumer grade gear in an office, but then I replaced it (as a temporary fix) with an even older Linksys WRT54GL flashed with DDWRT with no problems.
Re: D-Link patch doesn’t address all bugs listed in their own security advisory
#15I've just accepted that residential routers are full of assorted orifices (security holes, backdoors & holes in functionality). Then again I'm not hiding anything dubious - if I was I'd install a firewall box asap. (And yes I know the "nothing to hide" slippery slope etc argument)
I'm guessing that Apple's are better than average, since they have two versions (the built in HD on a time capsule doesn't make it appreciably different) and maintain them for long periods between upgrades.
Asus/Netgear/D-Link/etc follow the "If we don't release an 802.11ac router every week, we won't get enough press releases out!" model, and their firmware suffers as a result.
I'm not touching those unless I can wipe the stock firmware and replace it with Tomato or DD-WRT.
Re: D-Link patch doesn’t address all bugs listed in their own security advisory
#16Things like this make me so happy to have things like DDWRT, OpenWRT, et al.
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?
Re: D-Link patch doesn’t address all bugs listed in their own security advisory
#17pfsense on a thin client = 40$ OpenWRT on a home router as AP = 30$ Not getting pwned = priceless
The problem is that mom and pop can't possibly be expected to do this. They are trusting that the device they buy or the device their ISP provides, is secure.
Re: D-Link patch doesn’t address all bugs listed in their own security advisory
#18pfsense on a thin client = 40$ OpenWRT on a home router as AP = 30$ Not getting pwned = priceless
What are you running pfSense on for $40?
Re: D-Link patch doesn’t address all bugs listed in their own security advisory
#19I've just accepted that residential routers are full of assorted orifices (security holes, backdoors & holes in functionality). Then again I'm not hiding anything dubious - if I was I'd install a firewall box asap. (And yes I know the "nothing to hide" slippery slope etc argument)
I'm guessing that Apple's are better than average, since they have two versions (the built in HD on a time capsule doesn't make it appreciably different) and maintain them for long periods between upgrades. Asus/Netgear/D-Link/etc follow the "If we don't release an 802.11ac router every week, we won't get enough press releases out!" model, and their firmware suffers as a result. I'm not touching those unless I can wi…
I recently bought an Asus AC-1900 router (the RT-AC68W) after a long search, specifically for its supporting DD-WRT.
Re: D-Link patch doesn’t address all bugs listed in their own security advisory
#20I guess this is a reminder that writing secure C is actually really, really hard.
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 agree, but I don't think mentioning such an exception is a good idea. That's basically the same reason why gets() is part of ISO C90 and C99. Just call snprintf() even in such cases and forget about sprintf().
From http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10..., PDF page 163:
>The Committee decided that gets was useful and convenient in those special circumstances when the programmer does have adequate control over the input, and as longstanding existing practice, it needed a standard specification.