[Pan-users] Re: Is this normal behavior in PAN?

[Duncan]

David Shochat <address@hidden>
posted address@hidden,
excerpted below, on  Wed, 18 Feb 2009 06:04:12 -0500:

> I tried last night to post my results through the gmane NG, but for some
> reason, that did not work. So I'll repeat myself here. The short answer
> is that there is no difference in the ldd output whether I do it while
> running XFCE or GNOME. Every line of ldd output ends with a 32-bit hex
> value in parentheses and that part does differ. However it also differs
> if I simply run the ldd command on pan in the same environment twice in
> succession. I used awk to remove the final hex bit and the resulting
> filtered output is the same in all cases. I'd be glad to post the output
> anyway, if you want to see it.

Rats!  I was hoping they differed in (ideally) exactly one library or 
library version.  I thought we might be on the way to a solution to that 
one!

... And I don't think it's possible to do ldd with gnome because gnome is 
actually a bunch of component applications, not a single monolithic 
beast.  I suppose one could try switching out components from GNOME or 
switching in components from it to XFCE/KDE and see where the problem 
stops or starts occurring, but to really do that properly and without 
huge amounts of trial and error would require a lot of knowledge of 
component application dependencies and possible substitutes, a far higher 
level of detail than most would know, and for someone with that level of 
knowledge, there's likely a far more direct troubleshooting route.

There's another step one could take if they knew their way around readelf 
and function symbols, and there's a reasonable chance I could bumble my 
way thru it here, but it's not something I know enough about to try to 
explain.

FWIW, AFAIK those hex values in parentheses are library load addresses.  
On x86(32), from what I've read, a library has a "natural" load address 
where it works best as function address lookups are direct from the 
table.  If two different libraries overlap, however, one has to be moved 
to load at a different logical address from the viewpoint of that app, 
and every function reference then suffers a performance penalty due to an 
additional layer of indirection.  If I'm not mistaken, this is what is 
referred to as text-relocations, aka textrels.  If I understand things 
correctly, there's also some loss of efficiency in regard to shared 
libraries being able to exist as a single copy in memory -- the relocated 
instance can't be memory-shared as naturally located instances normally 
are.

amd64 aka x86_64 works a bit differently.  64-bit libraries must always 
be compiled as position independent code -- in essence, assigned a random 
address at runtime.  This is the -fPIC that Gentoo amd64 users and other 
amd64 users that install from source find so frustrating on occasion, 
because if it's not added to the code as it's compiled, the linker can't 
link the final library together and spits out an error.  But, simply 
adding it to your normal CFLAGS isn't so good an idea as actual 
applications (as opposed to libraries) still suffer the performance 
penalty x86 does.

All that said, regardless of the performance penalty, runtime address 
randomization is a better security practice, since a cracker attempting 
to exploit a buffer overflow to do anything "interesting" will have a 
MUCH easier time if he can count on knowing a function's normal memory 
address ahead of time.  While a compile-time determination won't affect 
from-source users that much since they'll all have their own anyway, if a 
cracker is familiar with a particular binary distribution and version, he 
can exploit that knowledge when targeting anyone else running that 
particular library binary, on x86(32) at least.  So it's a question of 
security vs. performance.  Common desktop distributions choose 
performance, but particularly hardened "server" distributions may choose 
to take the performance penalty to get the additional security.  The 
other alternative, as I mentioned, is compiling your own or distributing 
in small enough batches that it's effectively too small a target to be 
worth worrying about.  But that's one of the advantages of x86(64), as 
the security issue doesn't exist on it, for libraries anyway.

The equivalent flag for actual application relocation is -fPIE (E as 
opposed to C, E=executable, C I think is Code, but that doesn't 
distinguish application executable from library, so Common may be easier 
to remember).  -fPIE, position independent executable, has the same 
performance penalty on both 32-bit and 64-bit.  It is however a somewhat 
smaller target security-wise since most of the "interesting" functions 
tend to be in libraries anyway.

Based on the above, I'd /guess/ that you aren't running x86(32), or, if I 
understand correctly, most of those addresses would remain the same from 
call to call, as long as the libraries themselves weren't changed.  
However, I don't seem to be doing so well with my guesses at this point...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman