[ano-ther]

Not that this isn’t bad, doesn’t this only apply when an update is available?

So you have to be on a shady hotspot, without VPN, AMD has recently published an update, and your update scheduler is timed to run.

That would be a little less than “immediately own anyone with ATI”.

[Ginden]

You need only a device on network to spam DHCP messages with malware DNS. So you don't need "shady hotspot", only compromised device within network.

[pmontra]

If somebody is MITMing a target person, they will respond positively to "update available?" calls from that person and then serve the tainted update. The article does not say what the frequency of auto update check is. Let's say one per day. If somebody is targeted it's one day away from RCE.

[thedanbob]

The update check is HTTPS, only the files themselves are HTTP.

[cestith]

TLS doesn’t mask the IP of the server. The updater probably isn’t using DNS over HTTPS. If I can determine that a user’s updater just hit the update check server, I can start impersonating the update server.

That takes it out of the one day away territory, but it does allow an attacker to only have a malicious HTTP capture up and detectable during the actual attack window.

Then, of course, if you’re also being their DNS server you can send them to the wrong update check server in the first place. I wonder if the updater validates the certificate.

[pmontra]

I missed that, thanks!

[rtpg]

Oh yeah fair point, the HTTPS-ness of the first step is a helpful backstop