RFC: Cygwin 64 bit?
Peter Rosin
peda@lysator.liu.se
Thu Aug 18 16:32:00 GMT 2011
Den 2011-08-18 15:58 skrev Ryan Johnson:
> 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).
That's assuming there is no value for the perp in *not* touching
the attacked software. Any hashes for the files belonging to the
attacked software would still be correct, for example.
But I agree too, it's not like it's the end of the world...
Cheers,
Peter
More information about the Cygwin-developers
mailing list