This firmware is probably no better or worse than what you'd usually find on a consumer grade router from BestBuy. The difference is that this one controls AC power!
Hey manufactures: If you think there's nothing more to the Internet of Things than adding a relay and a power socket to the same insecure schlock you've been pushing for years, you're about to create a very interesting(1) near-future for us all.
Also, this is the third remote code execution vulnerability blogged in about as many days. Seems like dlink is having major quality issues with their software/firmware, which is spooky considering the things the device is supposed to do (manage power on an AC outlet). They did release a patch for the first problem but failed to review and fix similar flaws in the immediately surrounding code.
D-Link don't actually do anything like what you or I might call R&D or even software development. These products are absolutely riddled with security flaws, but the brands haven't caught on yet. I think really understanding why requires a bit of background, which I'll attempt to provide:
Brands like D-Link solicit stuff from "white label" vendors (who most people will have never heard of); the models they like the best get D-Link branded and get a chance at shelf space around the world. The brands do have input into things like the web interface, enclosure design and/or setup procedures (e.g. WPS button). What the brands do is valuable, but they usually do not have deep insight into how the product actually works or how it's developed.
The white-label vendors are like artists, trying to produce "hits", and the major brands are like record labels who can introduce things to a wide audience.
Naturally, the brands try to find suppliers who can provide the best features at the lowest hardware cost. The software side is often not looked at very closely.
When a researcher reports a vulnerability, this usually goes through the brand. Unfortunately, since they're not very technical, the brand tends to mangle the communications to the white-label. The white-label is scrambling to make their upstream customer (i.e. D-Link) happy, not the consumer. Communications problems are exacerbated when (as quite often happens) the firmware developer at the end of this chain does not have strong english.
Finally, in the case where the firmware is riddled with such bugs, it's in the interest of the white-label to HIDE this fact from the brand.
I think what needs to happen is that D-Link need to have high quality security reviews conducted as part of their vendor / hardware selection process. It's likely to happen, but it'll take years for the benefits to flow through to consumers.
On the Telco side, most places are now putting their home gateways and so on through fairly rigorous security reviews during the selection and deployment process. The hardware vendors are slowly learning embedded security via that route. No-one likes to lose multi-million unit sales.
[source: I've worked both in wifi router firmware development and pentesting, including embedded device security reviews].
I wonder if 3 vulnerabilities in 3 days means this device has exceptionally bad firmware compared to other similar devices or is just suddenly getting a lot of attention from skilled hackers.
Guessing by how frail software on these types of devices (routers, access points, home automation stuff, DSL modems, cable boxes, consumer NAS enclosures, etc etc) often feels, I fear it's the latter.
In my stints doing QA, I've found that developers seldom look beyond the immediately presented problem/issue, even when that problem makes it apparent that further review and consideration is warranted if not demanded. [1]
Further, all too often, minimum mitigations -- sometimes, the word "solution" cannot even be accurately applied to these -- are conceived and implemented.
When you see repeated problems cropping up like this, based upon experience, I can express the opinion that the organization and/or the individuals involved are not really paying attention or respecting sufficiently the security aspects involved.
Hopefully, the repeated bad press will begin to change this. But... those in the organization responsible for setting or sanctioning such initiative, are often all-to-well insulated from the immediate "real world".
--
[1] P.S. I guess I should qualify this to say that I'm speaking of what I consider to be a typical "corporate" environment. Lots of politics and inertia and, all too often, "just do what you're told".
It's bad; it's not exceptionally bad compared to similar devices though. So I agree with you.
I do think embedded devices as a whole are getting a lot more attention lately - because they're so fun to hack.
A consumer home router is often quite similar in terms of hardware to a Linux box from say 1995 (with differences due to Moore's law versus Kryder's law). 20 years as a rule of thumb is OK. Unfortunately the development practices you see tend to be 20 years out of date as well [shoddy, non-memory safe code, with no automated tests, talking to the network].
This is partly why hacking embedded devices is fun; it's like the 90's again! [I think every pentester has dreamed about the idea of being transported to 1995, knowing what they know now...]
Every time I see these sorts of vulnerabilities I think that these devices are becoming far too complex for their own good --- in this hacking series I've already seen mention of:
- HNAP -> SOAP -> XML
- HTTP
- Linux
The first 2 items above are protocols that are primarily text-based and have no easy way to determine things like lengths. This is bad because it often causes whoever is writing the code to use an arbitrary length that "will probably be big enough", and IMHO that is never a good thing, for various reasons including security.
Making it controlled by a simple, fixed-length (or length-delimited where absolutely required) binary protocol would've reduced or even eliminated many of these overflows, because such protocols are far easier to write correct code for. E.g., if a command is always 8 bytes, then you are always going to use a buffer of 8 bytes and read 8 bytes. Those that need variable-length data can prefix the data bytes with a length, and that must always be read first and acted on, since reading too much or too little just won't work. No need to parse text lines of arbitrary length, (un)escaping, etc. Each additional layer of complexity, each step that needs to be done, is an opportunity for bugs to be introduced.
Also, this is a device that absolutely does not need to be running Linux; its functionality would probably be achievable with an 8-bit microcontroller and WiFi module, running none or maybe a minimal realtime OS. Instead of over 4MB of firmware, a few tens of K would be sufficient. I've seen some very nice and robust embedded devices, and some that seem more like the developers just took a standard Linux devboard, put some code on it that looks like it works, then shipped it. This device is very much one of the latter.
The CoAP protocol does exactly this and is designed for the exact kind of restricted requirements you specified. It uses similar concepts to Restful HTTP to make the transition easier, but uses a binary protocol instead. You can even get gateways between it and HTTP should you need to use that for some reason (client side JavaScript etc).
>Also, this is a device that absolutely does not need to be running Linux; its functionality would probably be achievable with an 8-bit microcontroller and WiFi module, running none or maybe a minimal realtime OS.
This would make it much mode expensive. They just took a router that they already had and added a relay to a gpio pin. The actual cost of the hardware is probably the same. Re-engineering from the ground up? It should be done but the likes of D-Link aren't going to do it.
Why do people always implement stuff like this in CGI (C or C++)?
Using nginx+php/perl/python would work just the same and prevent a whole slew of vulnerabilities in embedded devices, while at the same time reducing maintenance and development costs.
I agree with the sentiment but running nginx+Python on an embedded MIPS device? That's getting pretty ridiculous! Better to go the other way (lower-level), I think.
I don't think using Python is significantly more ridiculous than the current practice of either using shell scripts or your own C code to parse form-data and generate HTML. In fact, it's probably a lot less ridiculous.
nginx has approx. 20MB footprint for 4 worker threads, add another 20MB for php... RAM is cheap these days, the cost of "ACME: Routers xxx,yyy,zzz hacked" headlines should be higher than the cost of equipping every router with 128MB of RAM.
Even if you do the actual scripts in CGI, alone using nginx for the HTTP part would kill off many of the security problems arising from buggy HTTP header/auth parsing.
Hey manufactures: If you think there's nothing more to the Internet of Things than adding a relay and a power socket to the same insecure schlock you've been pushing for years, you're about to create a very interesting(1) near-future for us all.
(1) In the Chinese curse sense: http://en.wikipedia.org/wiki/May_you_live_in_interesting_tim...