[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #13359 [Tor Browser]: Linux: update fails because bundled libstdc++.so.6 is not found

#13359: Linux: update fails because bundled libstdc++.so.6 is not found
-----------------------------+----------------------
     Reporter:  mcs          |      Owner:  gk
         Type:  defect       |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Tor Browser  |    Version:
   Resolution:               |   Keywords:  ff31-esr
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+----------------------

Comment (by mcs):

 Replying to [comment:1 gk]:
 > Replying to [ticket:13359 mcs]:
 > > Can we use -rpath at link time instead or will that cause other
 problems?
 >
 > My first guess is that it will break one part of our hardening. We had
 the RPATH for a while available, see #9150. Then some jerk showed up on
 the forum and explained how this may easily be exploited:
 https://blog.torproject.org/blog/tor-browser-365-and-40-alpha-2-are-
 released#comment-74540. If your solution leads to the same issue I'd
 rather avoid that.

 Make sense, although I am not sure what the security impact is if we were
 to use $ORIGIN with -rpath.  On the other hand, I found this:
 http://seclists.org/fulldisclosure/2010/Oct/257 (setuid program
 vulnerability caused by use of $ORIGIN).

 > I wonder how tor is starting properly up at all after the update as it
 definitely needs the LD_LIBRARY_PATH. Or are we just lucky to have the
 libs on our system and thus, we don't see this problem during testing?
 Assuming the LD_LIBRARY_PATH is somehow working for tor but not Tor
 Browser, what is happening if you put the libstdc++ into the directory
 where all the libs are that tor needs and do the update then (assuming we
 put the library there and not into /Browser)? Could you test that
 scenario?

 I did not test that scenario, because I confirmed that without
 LD_LIBRARY_PATH set on my system, all of the tor dependencies are
 satisfied by system libraries (probably not a good thing):
 {{{
 cd tor-browser/Browser
 LD_DEBUG=libs ./TorBrowser/Tor/tor
      31204:     find library=libz.so.1 [0]; searching
      31204:      search cache=/etc/ld.so.cache
      31204:       trying file=/lib/x86_64-linux-gnu/libz.so.1
      31204:
      31204:     find library=libm.so.6 [0]; searching
      31204:      search cache=/etc/ld.so.cache
      31204:       trying file=/lib/x86_64-linux-gnu/libm.so.6
      31204:
      31204:     find library=libevent-2.0.so.5 [0]; searching
      31204:      search cache=/etc/ld.so.cache
      31204:       trying file=/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5
      31204:
      31204:     find library=libssl.so.1.0.0 [0]; searching
      31204:      search cache=/etc/ld.so.cache
      31204:       trying file=/lib/x86_64-linux-gnu/libssl.so.1.0.0
 ...
 }}}

 Ideally, running tor or firefox without setting LD_LIBRARY_PATH would do
 the right thing.  On the other hand, we don't want to introduce an exploit
 path.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13359#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs