[marshray]

> The access that HTP obtained does not, full stop, lead to root on Linode instances without at least one shutdown job or change of root password job showing up in your Linode's history that you did not ask for. ... the access they obtained does not lead to root on the Linode host fleet itself

I wouldn't bet on that.

> There will always be targets but harboring SwiftIRC is probably a malicious-actor magnet.

Isn't that the same logic Everydns/Dyn Inc. used when they censored Wikileaks?

> All it takes is one zero-day, and you will all be hit by one in your career, so cut Linode a little slack.

True dat.

[tiredofcareer]

> I wouldn't bet on that.

I don't need to wager, and can speak with authority based on what I know (which I'd prefer to leave vague). There are two vectors into a Linode's filesystem from the perspective of an internal attacker: having root on the Xen host or gaining a login on the Linode. Knocking over the database and Web server gives you neither unless the person reused their account's password as their root password, in which case it's behind a cryptographic hash and subject to the typical rules there. If you own the database, you do have LISH access which gives you the equivalent of a VGA console; if someone left that console logged in, it's a vector as well.

The only vector HTP would have had in the general case would be bouncing the Linode. It's a fairly sufficient air gap, in a way.

[marshray]

Thanks for the clarification.

ISTR being able to back up Linode images, migrate them around, and perform some other admin tasks from the web interface. So I still wonder if the "air gap" API is a bit more powerful than simply the ability to request a reboot. But, again, I don't know.

[tiredofcareer]

Those buttons just instruct the hosts to do things and don't actually have power themselves.

[marshray]

The buttons belie the existence of an API that can "instruct the hosts to do things". Some of those "things" are pretty powerful.

Without knowing what those things are, I'll just take your word for it that none of them could ever possibly be leveraged to compromise a host or guest without unmaskable and permanent messages appearing in the logs.