On 7/11/25 04:34, Robert J. Hansen via Gnupg-devel wrote:
But many side channels, such as those arising from speculative
execution, are observable by an unpriviliged third party user of a VM
host (and not just cloud, on-prem is no different in principle).
Sorry to jump in here, but for 25 years I've told people "only run GnuPG
on hardware you control." That also applies if your underlying hardware
is a virtualized environment.
I side with Jacob here. Once Mallory has access to your hardware, it's
game over.
Thank you.
[...]
If I'm Mallory my order of operations is, roughly:
* Gain access
* Persist the access
* Elevate the access
* Prepare for termination of access
I don't hit the target unless I know how to do all four and have the
process automated.
Either you plan much farther ahead than the common cybercrook or we are
talking about targeted attacks instead of the much common "spam"
attacks. (That said, GnuPG is *supposed* to stand up against targeted
attacks.)
Unprivileged Mallory is either (a) a brief period of time before
becoming Privileged Mallory, or (b) a popular myth among security
researchers.
[...]
The catch is that the "juicy" stuff is typically *in* the user's account
on a single-user box... and therefore accessible without elevation if
Mallory is hitting the client.
Why risk the exposure (and correction) of a privilege escalation exploit
when everything Mallory wants is right there without it? (I note that
*I* might also be overestimating Mallory's intelligence or
underestimating arrogance here.)
Brief access as the "unprivileged user" is all Mallory needs for a
smash-and-grab. Persistence increases the risk of detection and
elevation requires an additional exploit that might be captured and
analyzed.
In my model, Mallory's ideal goal is make off with your data and/or
private keys and/or an unauthorized signature without leaving a trace
aside from possible intentional tampering.
This is one of the problems I have with tokens instead of
passwords---the former basically must be stored on the machine somewhere
accessible to the user's account, while the latter can be memorized or
stored offline (or [*sigh*] kept in "passwords.txt" on the user's desktop).
[...] if you're in an environment where OpenPGP traffic
is the highest-value target and would be a single-trove haul to justify
the incursion. If that describes your risk landscape I strongly advise
against doing any key operations on the box: use a smartcard instead.
In that environment, a smartcard is not sufficient; you need an isolated
box. If Mallory can gain persistence as the user, then Mallory need
only wait until the user unlocks the smartcard and can then abuse the
card right under the user's nose.
-- Jacob
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
