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 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.
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.
I had that router. To be clear, when they "removed bridging" they "removed, via adding a CSS 'display:none;' block to the radio button", and the workaround was inspecting the HTML and removing the CSS.
NOT that you should have to, by any means whatsoever.
I used to own a D-Link DIR-655. It had a hilariously terrible bug: It had a scheduler built in, so you could set WiFi to turn off overnight, amongst other things.
The scheduler web interface would only accept a range in the same 24 hr day, if you tried to set it to e.g. start (WiFi off) at 11 pm and stop (WiFi on) at 5 am, it refused with an error (paraphrasing) "end time must be after begin time."
It was ONLY a JavaScript issue. You could trivially bypass it using a developer bar, and it worked perfectly. But they never fixed the JavaScript in all the years I owned it (and I doubt it is fixed right now today).
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".
It was good for its time, but has limited onboard RAM, limited storage, and pretty slow WiFi by modern standards (there are even faster G-band, let alone N). Wouldn't recommend it today, and certainly wouldn't recommend touching Linksys with a ten foot pole.
As to stability, I'd describe it has a mixed bag. I owned one for just under five years and had to do fortnightly restarts (which I eventually automated), and we also owned one at work which needed nightly reboots (DD-WRT provided that).
PS - In fairness to the work one, the building was insanely congested. It was one of these buildings which are shared by three dozens small businesses, and each had 1-2 WiFi networks, plus the local homes also. When you spun up a WiFi analyzer it could not find an empty piece of spectrum, and a lot of routes/APs would crash if you left the "find best frequency" option checked (as they would hop continuously and never find anything).
TCP did that with their smart bulbs. They removed the local web interface in a silent update, bricking the bulbs for a lot of users. It's really bad manners, and I wish they would at least have options to re-add the missing features. It ultimately just alienates customers.
I was in a dev team for a network security appliance. It is really sad they way they treat vulnerabilities and security advisories. There were very few people who know what the actual vulnerability was.The vulnerability would be listed as one of the last items in a release checklist. Gets assigned to a guy who has no clue whatsoever. The guy fixing the issue would google a patch. apply it. has no way of testing it comprehensively. He will run a basic test case. He will make up a report with a lot of security jargon for the managers and advisory team. And the next release would list the vulnerability as fixed.
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)
To be fair, I know that firewalls have come to be considered "good security practice" -- but I've always been more comfortable to only expose programs that are supposed to talk to the Internet. Any recent version of Windows (say 8.1) comes with a firewall enabled (and that's needed, as windows still is a bit chatty with various smb protocols etc... just don't enable filesharing on your lan, if it's not protected from the Internet...). Don't know about OS X -- and for a Linux box, one can just make sure that everything is either off, listens to loopback -- or is supposed to be open.
Now, in many settings one do need a "LAN" in the sense of a firewalled playground for hopeless consumer devices, such as printers, ip web cameras etc.
Perhaps the biggest reason to have a firewall, is if you're running windows -- as unpatched windows machines live dangerously on the open Internet. And you'll be unpatched from initial install until you've patched up...
AFAIK there's been a while since any major Linux distro shipped with remote (no-action needed, like browsing) vulnerability out of the box.
As for "does not have an email account" -- I generally assume that anyone with half a brain can patch into the upstream DSLAM of my DSL line, so anything between me, and everywhere else is suspect. Which is of course why I protect my IMAP/SMTP with TLS.
[edit: consider people that use a laptop outside of the home -- they'll probably have to use dubious wireless links. It's more convenient to assume that the trust-boundary between you and the internet is at the local ethernet port/wireless card -- than anywhere else. That way you can have one set of "OpSec" that works (or not) wherever you are -- rather than fighting an uphill battle of situation awareness...]
>"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 trust your router, you really just have to initiate a secure VPN connection to a network that isn't out to get you.
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.
Email and banking has two factor authentication and runs over SSL so it would have to be a very determined hacker to get to my money.
Its not perfect, but as I'm pretty comfortable with the risk balance. Things like all these android apps containing god knows what make me way more jittery (See google's recent cleanup).
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.
Apple's routers are based on VxWorks. So if you trust VxWorks' networking, then you can trust Apples routers.
Personally I trust VxWorks over some patchwork router of the week by the usual vendors. It's used in many safety critical/medical applications, including the mars rovers.
The downside being that VxWorks has very low resource requirements, so some vendors use them to cut resources. Hence, You'd better be happy with the factory provided configuration because you can't flash them.
Some OpenWRT routers like the TL 1043ND I have suffer from VLAN leakage. Basically the router separates WAN from LAN via a VLAN config as the CPU has only one LAN port. At the router's bootup, devices on my lan would randomly get a public IP adress assigned by the DHCP server on the modem. Scared the crap out of me. From now on the thing is an access point, not a router.
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.
I have to run the configuration tool in a windows VM because on 10.10 they removed the frameworks it uses to run. I wish they weren't so complacent as to turn my hardware into bricks.
Maybe you just need to reinstall it? I just took a peek at it on my new laptop (which has never had anything but Yosemite installed on it) and it worked fine.
Airport Utility 5.6.1 was the last version that supported some of the older airports. Unfortunately Airport Utility 5.6.1 doesn't work (officially) on anything newer than Snow Leopard, but there's some modified versions floating around that work on 10.9
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 commercial), most of the meat lives in the chip, and with good open source firmware (DD-WRT et al.) it's probably just about as reasonable as anything else coming and going. I certainly have far more faith in a regular off-the-shelf SoC + open source firmware tuned to my own needs (and believe or not thisn't hard at all) than anything with propriety firmware, including (and especially, to me) Apple. Maybe the next best thing to do is to build your own WiFi router from totally off the shelf parts (not so hard to get into a small form factor any more).
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.
ARM is taking over from MIPS in the 802.11ac supporting products. MIPS is still around, but is now in the second tier of popularity alongside PPC. The single-core MIPS 24K and 74K that have been so popular just aren't fast enough for doing smart things at DOCSIS 3 speeds. They've also largely switched from NOR flash to NAND flash.
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]
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.
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.
i do think it is pretty hard to stop caring though, what happens generally is that if you start to get that demoralised you will leave and find something else. :)
Isn't Tomato way out of date? Wikipedia shows the last stable release was almost 5 years ago, and the website shows no dates on its releases (not a good sign). I ran Tomato for a long time and loved it, but I just got too nervous running such old software as the gateway to my network. Ended up upgrading to a cheap TP-Link router, switching to the latest and greatest OpenWRT release, and haven't had any complaints at all.
Ah, I wonder why doesn't the original project just fold up and point people at the currently maintained version. I'd still be very nervous about trusting my network to a random fork of mostly unmaintained software. At least with OpenWRT there's a very clear view into the (quite active) development, roadmaps to next releases, etc: https://dev.openwrt.org/roadmap
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.
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 heard is "programmers who don't know the size of their buffers are like drivers who don't know the size of their cars."
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().
>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.
Fair enough... it's not like snprintf has any noticeable overhead. Sometimes I use sprintf just to indicate to readers of the code that the output is not expected to be truncated, but that's probably too cowboy for my own good.
For the record, when writing new code, I'd strongly recommend that people consider using asprintf instead of either function.
Or a reminder that when someone sends you a list of things wrong, maybe you should read and understand it rather than applying a 2 second fix that doesn't actually fix anything?
Yes there are these things, although usually more focused on C++ these days.
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).
Modern, extremely popular compilers may not even support C89 features yet...
Citation needed please. Also, because C is not a true subset of C++, it has seemed that many big C projects will not compile on C++ compilers because of corner cases, so this may be something to watch for. Much of the incompatibility rises from additions in C99.
well spotted, that should have been C99, of which many features are not supported with the ms compiler. i believe that the variable array thing was pulled in C11 because so few compilers ever bothered to support it...
i see problems with it regularly where we use c code that goes through clang just fine, but cl complains. not putting declarations at the top of a file or scope is the obvious example that comes to mind and constantly snags people...
that being said there are even C++ problems, although smaller. for instance, its impossible to use the preprocessor variadic macros across cl, clang, gcc without getting warnings from at least one of them. i like to run with warnings as errors and the highest warning settings possible.
i'm not going to bother digging up references for informal conversation... but thanks for catching the mistake.
What is really hard is finding decent firmware engineers. Ones who care, and who can write secure code.
Even harder, finding a management chain that values security and that is willing to pay for it, and its continual upkeep (because security is a process, not a feature that you can complete and move on from).
I can't believe how laughably bad router security still is. It's fascinating how these exploits came to light. Where do you even start to map to the related system calls?
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.
It's the HP T5735. It's second hand from ebay. I got the fat version that has an extra PCI slot and I put a Realtek gigabit NIC in there. It's fast enough for home use, it does not saturate with my 200 megabit link. I use a TL-WR1043ND as an access point and VLAN-capable switch.
I switched from OpenWRT to pfsense a while back and I am never going back. It runs great in a virtual machine, if that's your thing and you already have a need for VMs.
HP T5735, there is a wide version of it with a PCI slot. I don't know about prices worldwide but 40$ is pretty much what I payed for a second hand one here in Germany.
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?
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.
Are there any left that are owned by semi-reputable big companies? Back when Cisco had Linksys there was some hope that they'd at least look after the vulnerability handling and patching process in a grown up way.
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.
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.