Subject: Re: static linking for NetBSD
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 09/16/2003 03:00:15
[ On Monday, September 15, 2003 at 21:35:32 (-0400), der Mouse wrote: ]
> Subject: Re: static linking for NetBSD
> > 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, but
you're right there are a few minor tweaks necessary in the kernel to
really lock things down the way they should be locked down.
> 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 I didn't point out, but which has been
pointed out several times previously by others, 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 on the other hand if you dynamically link the same
program with libc then those functions, along with all the rest of libc,
_is_ available immediately in the address space of the process. This
means keeping sensitive programs small, and static-linked, can
dramatically increases the effort necessary for any attacker to exploit
something like an integer overflow.
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <email@example.com>
Planix, Inc. <firstname.lastname@example.org> Secrets of the Weird <email@example.com>