Backdoor Found In TP-Link Routers 197
New submitter NuclearCat writes "Polish security researchers have found a backdoor in TP-Link routers, allowing an attacker to not only gain root access to the local network, but also to knock down the router via a CSRF attack remotely. (Further information — Google translation of Russian original). According to the researchers, TP-Link hasn't yet responded to give an answer about issue. The good news: Users who replaced their TP-Link firmware with Open/DD-WRT firmware can sleep well."
English news article (Score:5, Informative)
The H Security: Treacherous backdoor found in TP-Link routers [h-online.com]
Re:What about OpenWRT? :) (Score:2, Informative)
From the summary:
The good news: Users who replaced their TP-Link firmware with Open/DD-WRT firmware can sleep well."
(emphasis mine)
Re:I have to wonder why they bother... (Score:2, Informative)
For a lot of routers the chipset manufacturers aren't as friendly towards open source as they could be (eg broadcom), which is largely the reason why many popular routers are unsupported or work-in-progress for openwrt/dd-wrt etc.
Re:I have to wonder why they bother... (Score:5, Informative)
As far as I know, that's more or less what Asus does. I have an RT-N66U and it's an absolute dream box. It's based on one of the open source firmwares (I can't remember which one though, DD-WRT, OpenWRT or Tomato), Asus releases the source code to the firmware and you don't have to do anything fancy to install a custom variant of it, just upgrade your firmware manually like you would on any other router except pick the custom firmware file.
Re:Looks like the firmware upgrade (Score:5, Informative)
Should be fixed, yes. Critical to your network security? Not really.
It requires someone to convince a local user to click a link which not only executes an HTTP request against the router but also somehow starts up a TFTP service on the machine that executes that request, with some crafted files served from it to compromise the router when it asks for them.
It's a home router (and "routers" in the headline is accurate but misleading - precisely two are listed as vulnerable), so to be honest, I'm not at all surprised that this is possible. Hell, UPnP is more a security threat than this backdoor and that's enabled by default in a lot of places.
However, if TP-Link (whose products I quite like, especially their wireless repeaters) had just issued an update that stopped this happening, I'd not have even cared about it one jot and it would disappear into the void of things that have been patched already. It's the non-response that gets me. Someone at TP-Link couldn't even be bothered to say "We're looking into it"?
CS students no longer take economics classes? (Score:5, Informative)
Bullshit.
Broadcom does not even need to pay to make drivers. Open source the documentation and let others make the drivers.
Broadcom is trying to avoid the fact that they make a commodity product. If they would acknowledge that they do, they could benefit from drivers that were compatible with multiple vendors chipsets.
CS students no longer take economics classes?
Their product is NOT commodity; their functionality IS commodity. This is an INTENTIONAL line in the sand they are drawing to keep the products legal in the US, since you are not permitted to license an SDR in the US except as the aggregate of both the hardware for the SDR and the firmware which gets loaded into the hardware, and the driver which drives the hardware. This is an FCC regulation intended to keep people from easily eavesdropping or interfering with Military, Police, Fire, and other emergency services bands. It also makes it more difficult to turn a cheap SDR into a scanner by running it in receive-promiscuous mode, which would let you hear cell phone and other end-pointed transmissions, as well as allowing you to fake the IMEI for the device in order to clone other people's phones.
They DO NOT WANT an open source driver that documents their hardware interfaces so someone can clone their chip registers, since documenting the operation and order of operations on their chip registers represents disclosure of Trade Secret information not protectable by patents.
They would prefer that this never happen, since it means that if they have a large chunk of the market, they can keep other people from entering the market by making them work to get parity with their closed source drivers shipping in a third party OS, like Windows. Buy Windows? Broadcom just works, buy someone else's chips? Good luck, since you will have to fight to get your drivers signed, and fight Microsoft with getting them to ship your drivers with their OS so that your competing chipset also "just works".
It's an intentional non-monopoly anticompetitive practice (and therefore this side of the legal line) which raises costs for your competitors to the same levels as your costs, since you already have sunk costs that you need to recover. Making it so some clone factory can take advantage of all your sunk costs, and no matter what you do, they will undercut your pricing in the market.
This is EXACTLY the same reason the old Adaptec SCSI controllers went to the HIM architecture, and EXACTLY why the Diamond Viper video cards required a matched driver for the PAL coding matching the BIOS with the card, which made them a bitch to use without thunking down to INT 10. Both companies were preventing their cards being cheaply cloned and being used with the drivers they wrote. John Hamm, who made the decision on the HIM layer at Adaptec was later the CEO of one of the startups I worked at.
Note that the video driver stuff is not the same; the 3D engine uses patented processes in software, so they can't Open Source those without granting the license to use their patents, royalty free, so long as the code is licensed under similar terms.
Hardware accelerated decode for H.264 and MPEG would require licensing the Sorenson patents on a per chip basis. By pushing the cost of licensing off to the OS vendor as part of the licensing of the OS, they make it someone else's problem, which brings down the unit cost on the GPUs, so long as they are not used for that purpose, and you end up with bulk licensing applying across multiple GPUs when it comes from the OS vendor, which spreads the pain around to your competitors. So even though the decode could be fully done in hardware, there's always a software loopback part that requires the license, since the hardware won't do it on its own without the loopback.