>>> The _benefit_ of static binaries is that the processes run from
>>> them _cannot_ dynamically load new code.
>> If you believe that you are deluding yourself.  At most, they cannot
>> dynamically load new code using the OS's dynamic-linker facilities,
>> and I'm not entirely sure of even that.
> Well it's a lot more complex than that to subvert static binaries,

Who said anything about subverting anything?  "_Cannot_ dynamically
load new code" says nothing whatever about intent (cf. "subvert", which
does carry implications about intent).

>> There is a security benefit accruing to static linking related to
>> dynamic loading, but this isn't it.  I've had a few stabs at stating
>> what it is, but haven't found any short way of putting it - anyone?
> Perhaps this is what you mean:

> One of the bigger benefits [...] is that when you static link program
> that doesn't call, for example system() or popen(), those functions
> are simply not available at all in the text segment of the running
> process, but [...] if you dynamically link [...] then those
> functions [are available]

That wasn't what I primarily had in mind, but it's a good point.

What I was looking for was more like "cannot be attacked through
startup-time dynamic linker subtrefuge", but that's not quite right; it
also bears on having the dynamic linker available at run-time for the
potential use of injected malware.

Of course, _in theory_, once you're running code of the attacker's
choice, the game is lost.  But the number of land-mines the attack has
to tap-dance through is significantly higher if it has to do its own
dynamic-link-alike or include its own versions of whatever it needs.
Furthermore, as you correctly but indirectly point out, not all attacks
inject and execute arbitrary code.  Something like a synthesis of all
of these is what I was after.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B