Hacker News new | past | comments | ask | show | jobs | submit login

This is just what you would expect would eventually happen with AMT. Frankly it should be possible to physically disconnect a jumper on the motherboard that completely PHYSICALLY disables things like AMT.

I'd like that for the whole ME.

I won't respond to replies.

There is an undocumented pin which, when properly pulled {up|down} on startup, a.k.a. strapped, causes the ME to bypass its internal boot ROM and read from an external bus.

It is used internally to develop the ME and its firmware. It may not continue working after the OEM blows the last e-fuses -- it may be necessary to start from chips in the "partially fused" state that Intel ships out to OEMs.

A sufficiently motivated attacker, knowing it exists, could find it and exploit it. A sufficiently motivated defense, knowing it exists, could find it and use it to (re)gain control over their ME firmware.

The attackers have an advantage right now: currently deployed ME firmware is vulnerable. I'd like the defense to have all relevant information at their disposal.

And this exploit would have the same impact: you have to set up this feature in order to be affected.

Not entirely. It's locally exploitable even without configuration. Ideally, a physical disable would prevent that.


> An unprivileged local attacker could provision manageability features gaining unprivileged network or local system privileges on Intel manageability SKUs

This appears to imply an "exploit $site-backend -> provision AMT -> be vulnerable to network/local attack (for provisioned AMT) -> get AMT system privileges" route.

Except in large companies it's almost always enabled...

But then these companies wouldn't use the hardware disable, would they ?

I would. And then I'll play dump when the sysadmin asks why my machine isn't in the list.

Then the sysadmin enables it and if you disable it again they fire you.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact