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?


On 18/08/2011 12:31 PM, Peter Rosin wrote:
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.
True, but you can shut that party down by not having +t on any of the library paths and by having those paths owned by the same user that owns the targeted libraries. Both are probably true by default the vast majority of the time.

Ryan


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