31–40 of 86 posts
pfsense on a thin client = 40$ OpenWRT on a home router as AP = 30$ Not getting pwned = priceless
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.
Interesting. The D-Link security advisory ( http://securityadvisories.dlink.com/security/publication.asp... ) states that the issue was only partially resolved. What was changed (aside from adding an additional buffer overflow) in the patch that attempted to alleviate these issues?
I'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 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?
Compiling C as C++ with a C++ compiler is not a bad idea though... many compilers which will deal with both and tend not to care about pure C very much at all. Modern, extremely popular compilers may not even support C89 features yet... not to mention that lots will allow dangerous things like returning nothing from a function with a non void return type without even a compile error.
Many tools can catch the bugs mentioned here though - things like PVS studio, cppcheck, or the built in visual studio or xcode analysers (I would never recommend pc-lint, sorry), and some of these things mentioned are compiler warnings in some cases (sprintf will trigger the endlessly annoying CRT_NO_SECURE_WARNINGS message from the ms compiler for instance).
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…
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".
Earlier quoted context omitted.
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 would trust Apple's even more if the firmware releases were as regular as iOS updates. And the same goes for AirPort Utility releases, especially on Windows.
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 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 ade…
For the record, when writing new code, I'd strongly recommend that people consider using asprintf instead of either function.
I'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)
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.
The only reason I don't have a firewall box behind my residential router is because I don't have money to buy extra hardware.
Things 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?
As to inspecting the SoC itself, that would be certainly interesting. Most of them are just ARM SoCs; this might make for an interesting blog post looking at the silicon.