Hacker News Reader

Comment by okket | Hacker News Reader

> That file contains a bunch of links to firmware updates, all of which are also downloaded over http (and not https). The firmware images themselves appear to be signed, but downloading untrusted objects and then parsing them isn't ideal.

Why? What security benefit do you gain by using HTTPS when you already check the signature/hash of the firmware file?

View on HN

Parser exploits aside, HTTPS would help ensure the signed image you received was the one you asked for. So say there's an exploitable security flaw in 1.1.5 of the firmware and the firmware requests an upgrade from http://whatever.com/images/latest.img. Someone could return the legitimate 1.1.5 image instead, and assuming no other version validation, cause a downgrade that will allow further attacks.

If you assume there IS further version validation, then the question is how do you know what version you should be expecting without HTTPS?

To prevent downgrade attacks, include a list of banned signatures/hashes of previous versions in an upgrade? Plus only allow higher version numbers?

Downside: Reverting is not possible if you make a serious mistake in an upgrade. If you can't initiate another upgrade process, bricking is possible...

I don't know much about the world of really small devices aka IoT, but from my laymen perspective: Is a full TLS stack still a huge obstacle there? Sane signature checks are at least a step in the right direction.

A device running 1.0 could still be upgraded to a vulnerable signed 1.1 when a patched 1.2 with blacklist is current on the site.

A device running a vulnerable signed 1.1 could still be denied an upgrade to 1.2 by a MITM blocking port 443 even if you used HTTPS.

Yeah but it's kind of irrelevant because the device is already vulnerable in your example. The point of this was to say that you can turn a safe device into a vulnerable device as part of a multi-phase attack.

So assuming the version is signed (likely given they seem to have done this competently) the worst an adversary can do is prevent upgrades? They could do that by blocking HTTPS too.

I think so, but I don't think it's actually a correct assumption. The article talks about the list of firmware versions (and where to download them from) as being fetched from a JSON file delivered over HTTP. That json file isn't signed in any way, so you could first intercept that, change the links and expected versions, and you're home free.

Generate a new package every day or week and include current date. Do not allow to update to package older than X.

Synchronize time using one of the time signals available in the area or use signed channel for time sync. Using radio time signal it can be easy to spoof it if your location is known by the intruder, but makes it practically impossible for remote exploits. But radio signals may have bad reception inside a house.

Metadata leakage aside: If you run a parser on unauthenticated input, bugs in your parser can be exploited. This is partly why mac-then-encrypt is a bad idea (you have to decrypt to verify the MAC.)

One could take the view that a full TLS stack is so complicated that it is much more likely to contain exploitable flaws than some simple signature checking code.

There are plenty of off the shelf TLS stacks, but people tend to end up hand-rolling their own signature validation code badly.

And all of them are universally terrible and a MAJOR hassle to integrate with any embedded system. If you read mbedTLS or PolarSSL run far far away.

Maybe people hand-roll their own signature validation code badly, but those same people will just as much screw up or plain disable the CA verification.

If you have the knowledge to use the primitives from something like NaCl, you have nothing to gain from using a full TLS stack but pain building, upgrading, programming your firmware and massive middleware problems in the field. And when they inevitably find issues in the TLS stack you used, your device is now fucked since there is no virtual address space, W^X, even stack cookies..

Undoubtedly true, assuming you use something well-scrutinized like signify or gnupg for that signature verification.

There's a parser on unauthentic input either way. Given the choice to do it online with NSS or OpenSSL or offline with the same library, I think it's a hair safer to do it offline---but this will be swamped by other factors particular to the project.

Yeah, don't get me wrong. Not implementing TLS because you're worried about attack surface is a bad idea. But if all you're doing is verifying a gpg signature on some firmware, a TLS stack is probably overkill.

> Not implementing TLS because you're worried about attack surface is a bad idea.

[citation needed]

If you're doing things that should be done over an encrypted channel, but forego TLS (or a suitable alternative like Noise Framework or WireGuard) because it adds attack surface, you are adding more risk than you are removing. A better solution would be to separate the parts of the stack that are sensitive from the parts that do things that you don't trust/are not in your control. This could be openbsd/POSIX style separation between your sensitive and the TLS-terminating process, or ideally placing them on completely separate machines. (Just make sure you trust your internal network if you aren't going to encrypt traffic on the inside...)

> Why? What security benefit do you gain by using HTTPS when you already check the signature/hash of the firmware file?

B/c without HTTPS you can't verify you're actually talking to IKEA's update servers. Even if there's firmware signature implemented an attacker could still MITM you over HTTP and simply not serve you a file with updates. Which means that they can prevent your devices from upgrading, i.e to receive an update that closes a known flaw they might be exploiting.

Closing an easy attack vector by using HTTPS seems a safe bet here, with no particular drawbacks. Are there chip-level power concerns that could make their IoT thing unable to do SSL, but able to validate firmware signatures?

HTTPS for firmware download is a maintenance nightmare. In a couple of months, TLS 1.3 is going to be finalized, and then calls for everyone to drop support for TLS 1.2 will begin. But they can't drop TLS 1.2 support, without breaking firmware updates for all the unopened boxes out there.

They probably should have signed the json listing of firmware images though, in addition to just the firmware images.

People even support TLS 1.0 for Enterprise clients. I feel like you'll support your legacy protocols for at least 20 years.

I guess what they could do to avert that is to have versioned (by subdomain) upgrade sites where each version is as secure as the associated device.

Reply on news.ycombinator.com