On 7/12/25 17:41, Robert J. Hansen wrote:
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.)
Correct, I'm talking about targeted attacks. Random drive-bys are not
of much personal or professional concern. This is of course my risk
model, and I don't expect it to be relevant to anyone else. :)
Both *should* be of concern, since a targeted attacker could certainly
use "drive-by" techniques, both to evade detection and possibly your
defenses, if you are so focused on targeted attacks that you miss something.
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.
If it's a single-user box, sure. Of course, many single-user boxes
make privilege escalation ridiculously easy, so why not? (Everyone who
has put NOPASSWD: ALL into their sudoers file, please raise your hands...)
I just checked to make sure that is *not* in there... (I would not be
surprised to find that some distributions have it by default...)
Why risk the exposure (and correction) of a privilege escalation
exploit when everything Mallory wants is right there without it?
Because even on single-user boxes, persistence and cleaning up one's
tracks is much easier done with escalation than without. If
persistence and concealment is part of the attack profile, you need
escalation.
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.
Then Mallory needs escalation. If you're going to do things like look
through the system logs and scrub them appropriately, you need to
escalate.
This is why I believe a competent Mallory always escalates. It's
simply not possible to do a thorough cleanup job without escalation.
If Mallory only wants a smash-and-grab, then persistence is a needless
risk. Client exploits typically do *not* produce log entries in the
first place, so there is nothing to clean up.
In fact, log scrubbing might *be* an indicator of an intrusion: you full
well that your browser crashed with SIGSEGV, where the hell is the
segfault in the log?
In that environment, a smartcard is not sufficient; you need an
isolated box.
Frankly, I think you need a lot more than a smartcard, too, starting
with a radical rethink of "why am I hosting such valuable files on a
machine connected to the internet?" :)
Consider the scenario of software release signing keys. Obviously the
signature must reach a network-connected machine in order to publish
it. Mallory wants to sign a Trojan horse with your key. You want to
prevent that, or at least detect the intrusion immediately and announce
that a spurious signature exists before Mallory can smear your good name.
-- Jacob
_______________________________________________
Gnupg-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
