RFC: Cygwin 64 bit?
Ryan Johnson
ryan.johnson@cs.utoronto.ca
Thu Aug 18 13:59:00 GMT 2011
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).
More likely it just adds a new facet to the existing dll purgatory which
poor unfortunate developers already have to navigate. Which, ironically,
is usually resolved by putting everything you care about in the same
directory as the executable (so maybe that's another reason to leave
dlls in/bin).
Ryan
More information about the Cygwin-developers
mailing list