This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Cygwin 64 bit?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]