Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ASUS delivers BIOS/UEFI auto-updates over HTTP with no verification

teletext.zaibatsutel.net

Post reply on HN
Print view View original

191–200 of 200 posts

Re: ASUS delivers BIOS/UEFI auto-updates over HTTP with no verification

#191

Post by ryao »

izacus wrote: post #152
ryao wrote: post #63

Earlier quoted context omitted.

> The flip-side is that this isn't the sort of security most of us want, and the fact that router firmware is "insecure" from this perspective is what enables things like DD-WRT to exist in the first place. See also: iOS jailbreaking, Android rooting, console homebrew, etc. There is a difference between making updates available in a way that enables custom firmware and doing them in a way that permits MITM attacks. L…

Perhaps it was just a case of misunderstanding, but your sentence read like you were implying that preventing users from updating the firmwares was a good thing.

They did accomplish a good thing (preventing MITM attacks on firmware updates) as a side effect of doing something stupid (preventing users from flashing OSS). The right way to prevent MITM attacks would have been via HTTPS and PGP signatures that users are expected to verify when doing manual updates and is only verified automatically by auto-update mechanisms. Sadly, what was done was motivated by reasons that have nothing to do with security and consequently, is making equipment less secure.

Re: ASUS delivers BIOS/UEFI auto-updates over HTTP with no verification

#192

Post by Nullabillity »

TazeTSchnitzel wrote: post #190
Nullabillity wrote: post #188

Earlier quoted context omitted.

> Apple's devices tend to be more difficult to repair or upgrade yourself, yes, but this is not malicious, even if it is somewhat hostile. If they consciously take a hostile action (and let's face it, you don't accidentally design a new screw) then yes, I'd call that malicious. If you do that repeatedly then I'd consider you evil. > Also, I should point out that while Apple's phones don't let you install unapproved s…

Gatekeeper applies only to GUI apps and can be trivially turned off.

For now.

Re: ASUS delivers BIOS/UEFI auto-updates over HTTP with no verification

#194

Post by sleepychu »

joosters wrote: post #140
sleepychu wrote: post #79

Earlier quoted context omitted.

You can do it in certificate only mode. I think DNS challenge is even enabled now so you don't need to let it touch your running server at all. Of course it's a bit of admin every ~90 days but 4 times a year for free SSL isn't bad.

You're missing the point. The OP isn't claiming that Lets Encrypt is impossible to configure, so telling them that there are ways to make it work is a bit pointless. The key is that Lets Encrypt can be very difficult to configure and get things working. In a way, the numerous methods available to set up LE add to the confusion, you can search around and find lots of conflicting 'best' ways to do it.

Just for clarification those are two distinct issues. One: the LE client's apache magic fix up code can fail to handle fairly standard configs and mess things up. I addressed this directly, you don't need to use the apache magic configuration.

Two: ACME offers numerous ways to convince it that you own a domain name. My intent was to follow this up by saying you don't even need to be running an ACME client/mess with your apache config at all by using the dns-01 challenge variant over the http-01 variant.

> The key is that Lets Encrypt can be very difficult to configure and get things working. This is definitely a problem, it would be great to see a divorce between the apache config munger and the certificate fetcher. SSL available to the uninitiated is great but if they're on the command line then I'd like to believe they're capable of pointing their server at a specific location for certificates on disk.

Re: ASUS delivers BIOS/UEFI auto-updates over HTTP with no verification

#195

Post by pricechild »

matthewaveryusa wrote: post #153
pricechild wrote: post #146

Earlier quoted context omitted.

You don't need to verify it on the target system though?

You sign at the source with a private key, and you verify on the target with the public key. The trick is only someone with the private key can create a signature that the public key can verify.

The parent explained they might not trust verification on the target system. This might not necessarily be because the target is assumed malicious, but it may only have e.g. md5sum and not sha1sum available etc. (I'm obviously no expert... the hashing examples are just examples here)

I intended to suggest you could download it on a separate system which you do trust and verify it there. Then transfer it to the target system.

Re: ASUS delivers BIOS/UEFI auto-updates over HTTP with no verification

#196

Post by newman314 »

adam-ff wrote: post #189
newman314 wrote: post #126

Earlier quoted context omitted.

I wonder if someone has built a transparent proxy/router level implementation of HTTPS Everywhere... That might be quite useful.

That's like mailing a postcard to a company that puts it in an envelope for you.

Not really. I was thinking along the lines of a localized instance so it would be more akin to things being captured at the perimeter and getting converted there.

So outbound to an insecure HTTP url gets rewritten to pull from a HTTPS url instead etc.

Re: ASUS delivers BIOS/UEFI auto-updates over HTTP with no verification

#197

Post by bigiain »

merijnv wrote: post #185
bigiain wrote: post #166

Earlier quoted context omitted.

The other problem is many people wont have pre-existing copies of the required private key available. If your attacker is in a position to MitM your download of a signed binary, they're probably also in a position to MitM your retrieval of the public key. SSL/TLS certainly helps there (at least the attacker then also needs to be capable of acquiring root CA signed TLS certs for the download site and any readily avail…

> The other problem is many people wont have pre-existing copies of the required private key available. We're talking about software updates, you embed the key INSIDE the software to avoid this problem.

Ahhh, good catch... Agreed.

(Though with my overly-cynical hat on, I now just suspect you've only moved the problem to the previous update's authentication - and recursively back to the initial download. How do you protect against the initial download being MitMed and having an attacker's public key inserted - this is functionally the same as HSTS - if you can MitM the first visit you win...)

Re: ASUS delivers BIOS/UEFI auto-updates over HTTP with no verification

#198

Post by deno »

bigiain wrote: post #197
merijnv wrote: post #185

Earlier quoted context omitted.

> The other problem is many people wont have pre-existing copies of the required private key available. We're talking about software updates, you embed the key INSIDE the software to avoid this problem.

Ahhh, good catch... Agreed. (Though with my overly-cynical hat on, I now just suspect you've only moved the problem to the previous update's authentication - and recursively back to the initial download. How do you protect against the initial download being MitMed and having an attacker's public key inserted - this is functionally the same as HSTS - if you can MitM the first visit you win...)

You need to trust something at some point, be it TLS session and the server you’re talking with, or an SHA csum you verify with a friend (or using PGP’s WoT), and even further the process(es) and person(s) responsible for actually signing the releases.

As for “moving the problem,” it is worth it. Because it’s easier to verify the origin of the software once, then for every update. If there’s a new vulnerability in TLS this will only affect new installations. Verifying (& signing) packages offline is much more anti-fragile.

Re: ASUS delivers BIOS/UEFI auto-updates over HTTP with no verification

#199

Post by [deleted] »

JoshTriplett wrote: post #118
jamiesonbecker wrote: post #47

Earlier quoted context omitted.

Intel NUC has an option to directly pull down/install BIOS updates built into UEFI as well, and thus probably other newer Intel boards. Convenience and security are often orthogonal.

Convenience and security are often closely related: you need regular updates to maintain security, and if it isn't convenient, people won't do it. As long as the updates handle security properly (use HTTPS and verify signature), I don't see anything wrong with an "update" button in the BIOS.

[deleted]

Re: ASUS delivers BIOS/UEFI auto-updates over HTTP with no verification

#200

Post by LeifCarrotson »

DarkLinkXXXX wrote: post #173
LeifCarrotson wrote: post #162

Earlier quoted context omitted.

> See also: iOS jailbreaking, Android rooting, console homebrew, etc. Let's go back a step: Why do all of those things exist? It seems like it would be fairly easy. Use ARM TrustZone or Intel TXT trusted environments to host a non-writeable firmware, with one-time-programmable key storage, verifies that the contents of the boot memory are correctly signed by the key. If it is, then boot. If not, don't (copy in and ve…

Please, don't give them ideas.

I am just a junior dev with a minimum knowledge of cryptography. This cannot possibly be a unique or new idea. It's literally the purpose of those modules and the purpose of code signing. So what are the business reasons for why it isn't done this way? Some ideas:

0. They didn't think of it, and I just gave them the idea. Unlikely. 1. Resources required to implement this (hardware read-only keystore, crypto primitives in the bootloader, reboot scan time, backup boot image storage space plus incoming image storage space, etc) are too expensive. 2. The possibility of losing the key and having devices they mathematically can't modify without a complete recall and replacement is too terrifying. 3. They don't care relative to the effort to implement it. They talk and litigate like they care, why doesn't this message get carried down to the new product department? 4. Decision makers don't understand the difference between the "security" obfuscation measures they're being sold right now, and potential, actual mathematically secure models proposed to them. 5. They are incompetent to actually build this. They have some pretty smart people, and accomplish other impressive projects, so this seems unlikely. 6. There's a flaw in my scheme that makes it no better than existing methods that can be jailbroken.

Post reply on HN