On 18/08/2011 9:24 AM, Corinna Vinschen wrote:
On Aug 18 15:10, Peter Rosin wrote:
Den 2011-08-18 11:20 skrev Corinna Vinschen:
So, nobody except Earnie is interested in the way dlopen opens shared
objects? Nobody even replied to the idea of the pseudo algorithm below.
Does really nobody care?
I have one little reservation, I don't like it when adding a seemingly
unrelated file can break old stuff. For example, let's say that I in the
future have an application that relies on the fact that it can dlopen
"libfoo.so" and get "cygfoo.dll". Everything works fine. If I then
install something that brings in a real "libfoo.so" things will break.
It's even a security problem because a carefully crafted rouge
libfoo.so can appear to work but do unwanted stuff behind my back.
That's a good point. I don't know how critical that is. Maybe it would
help to change the order, along these lines:
incoming: libfoo.so
1. check: cygfoo.dll
2. check: libfoo.dll
3. check: libfoo.so
But, of course, regardless of the order, there's always a chance to
slip something in.
In theory it does sound bad, but I'm not sure how much of a hole it
leaves in practice: the fact that the adversary has to resort to
different names rather than simply replacing the targeted library
means they have pretty limited control. They can't just
delete/rename their target, nor can they stick a decoy earlier in
[LD_LIBRARY_]PATH, so they have to resort to exploiting this name
overloading. The only way around it that I can think of right off
would be if some directory in the search path has the 't' permission
set (like /tmp does), so they can add new files even though they
can't mess with other files there. That seems unlikely (or at least,
easily fixed).