security model

Jacob Bachmeyer jcb62281 at gmail.com
Sun Jul 13 07:04:09 CEST 2025


On 7/12/25 22:42, Robert J. Hansen wrote:
>> 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.
>
> Jacob, please don't tell me what should be of personal and 
> professional concern to me.
>
> You don't know what my risk environment is. For all you know I'm part 
> of a security operations center at their APT desk, and the drive-bys 
> are handled by a different unit. All I said is: my area of personal 
> and professional interest is in targeted attacks by people who know 
> what they're doing.

Fair enough; my experience has all been on smaller scales.  I have never 
had "a different unit" that handled some of the problem.  That must be 
nice...

> That said: yes, professionals and amateurs can run the same exploits. 
> *Why* they are running the exploits, and their long-term goals in 
> running the exploits, will differ.
>
> I'm having a hard time thinking of something that would justify a 
> targeted attacker doing a low-skill smash and grab without 
> persistence. If the haul is valuable enough to justify that, then 
> isn't it also enough to do the job *well*, including keeping it under 
> the radar and persisting?

Persistence and evading detection are a tradeoff for the attacker.

Further, Mallory may not have the goals you assume.  If Mallory is a 
professional, making the attack look like a low-skill smash and grab 
could, for example, be a strategy to avoid raising alarm at the targets 
that they *are* targets.

>> If Mallory only wants a smash-and-grab...
>
> Professional Mallory doesn't want a smash-and-grab.
>
> Professional Mallory wants a haul. There's some trove of data that 
> justifies the time, resources, and expense of Professional Mallory. If 
> Professional Mallory has any choice in how to gain access, 
> Professional Mallory will persist the access: because if this box has 
> a top-flight haul today, who knows what it will have in six months?

Logically, the box is most likely to have about the same, except that a 
second copy of the same haul is valueless to Mallory. Assuming Mallory 
is *not* trying to make a splash, keeping as quiet as possible reduces 
the chance of the victim realizing that tighter security is needed.

In short, there is no amount of persistence that can save Mallory's 
access once the target becomes aware of it and gets serious about 
kicking Mallory out.

I agree that many attackers still do not seem to understand this 
issue---the xz backdoor was discovered in part because of "Jia Tan" 
poorly balancing this tradeoff---but the attackers who *do* understand 
it are the ones I most worry about, precisely because of views like the 
one you are stating that assume they do not exist.

> Professional Mallory persists. Count on it.

That depends on the expected reliability of Professional Mallory's 
initial access.  (unless Mallory is really stupid...)

If Mallory expects to get back in just as easily six months from now, 
why leave something that an attentive admin might notice (like "why are 
there two 'syslogd' files in /sbin?" or "why is /sbin/hwclock so 
small?") if that can be avoided because the Web app is a security 
dumpster fire running on a years-obsolete CakePHP version?

(Those are actual examples from years ago at a past $WORK that is no 
longer in business, by the way.  The second "syslogd" was actually 
'syslogd ' (note the space) and hwclock had been replaced with a shell 
script that launched a back door before running the real hwclock that 
had been hidden in /lib and disguised as a shared object.)

>> Client exploits typically do *not* produce log entries in the first 
>> place, so there is nothing to clean up.
>
> Consider the simplest form of drive-by, the stolen credential. Are you 
> telling me Mallory's connection and exfiltration aren't going to 
> appear in SFTP logs? Or that these logs don't need scrubbing?

Clients keep SFTP logs?  Are you assuming that Mallory steals the user's 
password and then connects to sshd on the user's box to make off with 
the user's files?  I would be more concerned about Mallory "cutting out 
the middleman" and simply making off with the user's files instead of 
bothering to leave an initial keylogger.

(I am also not considering the case where the user is tricked into 
putting their system login credentials into a phishing page, 
admittedly.  I have never had to support users who were that naive.)

I have been talking about attacks on clients, not servers, because GnuPG 
is most typically run on client nodes.  Indeed, as far as I know, the 
PGP security model is focused on clients---the boxes physically used by 
the users.  Servers are categorically untrusted in PGP.


-- Jacob





More information about the Gnupg-devel mailing list