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

Re: [tor-bugs] #22563 [Applications/Tor Browser]: Many memory pages in tor.exe for Windows violate W^X



#22563: Many memory pages in tor.exe for Windows violate W^X
-------------------------------------------------+-------------------------
 Reporter:  arthuredelstein                      |          Owner:
                                                 |  arthuredelstein
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  windows tor-client win32 tor-relay   |  Actual Points:
  security hardening 031-backport,               |
  TorBrowserTeam201707                           |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by arthuredelstein):

 Replying to [comment:8 cypherpunks]:
 > As you "have stolen" this ticket from Core Tor :), it should be noted
 that the right fix for this bug is, as Jonathan Yong
 [https://sourceforge.net/p/mingw-w64/discussion/723798/thread/2f2c014b/#e385/9720/259e
 suggested], to "Use proper dllimport/dllexport in your code to avoid auto-
 imports." To check that you should compile Tor with `--disable-auto-
 import` for MinGW-w64.

 Thanks for the good suggestion. I tried it but I already run into an error
 when openssl is building. Namely:
 {{{
 libcrypto.a(cryptlib.o):cryptlib.c:(.text+0x9): undefined reference to
 `__stack_chk_guard'
 libcrypto.a(cryptlib.o):cryptlib.c:(.text+0x48): undefined reference to
 `__stack_chk_guard'
 libcrypto.a(cryptlib.o):cryptlib.c:(.text+0xd4): undefined reference to
 `__stack_chk_guard'
 libcrypto.a(cryptlib.o):cryptlib.c:(.text+0xe4): undefined reference to
 `__stack_chk_guard'
 libcrypto.a(cryptlib.o):cryptlib.c:(.text+0x106): undefined reference to
 `__stack_chk_guard'
 libcrypto.a(cryptlib.o):cryptlib.c:(.text+0x264): more undefined
 references to `__stack_chk_guard' follow
 /var/tmp/dist/mingw-w64/lib/gcc/i686-w64-mingw32/5.1.0/../../../../i686-w64-mingw32/bin/ld:
 libcrypto.a(cryptlib.o): bad reloc address 0x200 in section `.rdata'
 collect2: error: ld returned 1 exit status
 make[4]: *** [link_a.cygwin] Error 1
 }}}

 I did not investigate further, but my best guess is the -fstack-protector
 implementation (when used with mingw-w64) relies on auto-import. Looks
 like we would need an additional patch for gcc or mingw or someplace to
 fix this.

 > Arthur could also make Firefox compile with `--disable-auto-import` (and
 also explain Mozillians why not to use `-mnop-fun-dllimport`) and get
 another one bounty ;)

 Good point. I have opened #22917 to investigate this further. In the
 meantime I think we should go ahead with using the bumped version of
 mingw-w64 because it is working at least for now.

 > In general, MinGW-w64 should remove `--enable-auto-import` by default,
 because future releases of Windows can enforce security, and such tricks
 will fail. Maybe, Arthur, might explain MinGW-w64 guys that they shouldn't
 "fix" incompatible programs (by default at least) with this dirty hack,
 which Arthur made much less dirty!

 My dear cypherpunk, maybe you would like to start that debate on the
 mingw-w64 discussion page? :)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22563#comment:10>
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