RWX page observed on Windows

With the legacy/trac#21514 (moved) patch applied, I observed a single RWX page on Windows. It would be good to track this down and fix it.

added TorBrowserTeam201706R in Legacy / Trac component::applications/tor browser in Legacy / Trac owner::tbb-team in Legacy / Trac priority::medium in Legacy / Trac resolution::fixed in Legacy / Trac severity::normal in Legacy / Trac status::closed in Legacy / Trac tbb-security in Legacy / Trac type::defect in Legacy / Trac labels

I see a similar single RWX page in Firefox 51.0.1 on Windows. So it's not special to Tor Browser.

I opened a Mozilla bug to track this issue in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1344034

https://dxr.mozilla.org/mozilla-esr52/search?q=PAGE_EXECUTE_READWRITE&redirect=false What about disabling ctypes?

├────451.92 MB (22.07%) -- commit
│    ├──122.20 MB (05.97%) -- image
│    │  └───14.77 MB (00.72%) -- (4 tiny)
│    │      ├───0.98 MB (00.05%) ── execute-writecopy [48]
│    │      └───0.44 MB (00.02%) ── execute-readwrite [48]

RWX pages in Tor and its ssleay32.dll, libeay32.dll, zlib1.dll don't bother you?

This sure does seem like an issue.

Is there some patch we could apply locally, while we wait for the Firefox people to get their act together?

Or maybe this is a good bite-sized bug to ask the Internet to help Firefox with?

Could somebody ask MS to fix Windows 7?

Address		Type		Size	Commit	Private	Blocks	Protection		Details	
68CD0000	Image (ASLR)	964	964	200	6	Execute/Read/Write	C:\Windows\System32\msmpeg2adec.dll	
  68CD0000	Image (ASLR)	4	4			Read			Header	
  68CD1000	Image (ASLR)	736	736	8		Execute/Read		.text	
  68D89000	Image (ASLR)	100	100			Execute/Read		RT_CODE	
  68DA2000	Image (ASLR)	80	80	80		Execute/Read/Write	.data	
  68DB6000	Image (ASLR)	12	12	12		Read/Write		.data	
  68DB9000	Image (ASLR)	4	4	4		Copy on write		.data	
  68DBA000	Image (ASLR)	4	4	4		Copy on write		RT_DATA	
  68DBB000	Image (ASLR)	4	4			Read			.rsrc	
  68DBC000	Image (ASLR)	20	20			Read			.reloc	
68E50000	Image (ASLR)	3 148	3 148	188	8	Execute/Read/Write	C:\Windows\System32\mf.dll	
  68E50000	Image (ASLR)	4	4			Read			Header	
  68E51000	Image (ASLR)	2 884	2 884	4		Execute/Read		.text	
  69122000	Image (ASLR)	40	40			Execute/Read		RT_CODE	
  6912C000	Image (ASLR)	44	44	44		Execute/Read/Write	.data	
  69137000	Image (ASLR)	16	16	16		Read/Write		.data	
  6913B000	Image (ASLR)	4	4	4		Copy on write		.data	
  6913C000	Image (ASLR)	28	28	28		Read/Write		.data	
  69143000	Image (ASLR)	4	4	4		Copy on write		RT_DATA	
  69144000	Image (ASLR)	16	16			Read			.rsrc	
  69148000	Image (ASLR)	108	108			Read			.reloc

Trac:
Keywords: N/A deleted, tbb-security added
Status: new to needs_information

Replying to cypherpunks:

https://dxr.mozilla.org/mozilla-esr52/search?q=PAGE_EXECUTE_READWRITE&redirect=false What about disabling ctypes?

This was a good suggestion. I tried it but the RWX page was still present. My next plan is to systematically check all the allocate and reprotect calls. Possibly this is best done by hooking the system calls, especially because this might be the result of a library call.

Replying to arma:

This sure does seem like an issue.

Is there some patch we could apply locally, while we wait for the Firefox people to get their act together?

Or maybe this is a good bite-sized bug to ask the Internet to help Firefox with? What Firefox? It's tor.exe itself and libs, Tor Expert Bundle for Windows.

I submitted a patch here: https://bugzilla.mozilla.org/show_bug.cgi?id=1344034#c4

I expect it will be straightforward to backport to TBB/ESR52. I'll wait for Mozilla's review before doing that.

Here's my Mozilla patch, rebased onto tor-browser-52.2.0esr-7.5-1, for review:

https://github.com/arthuredelstein/tor-browser/commit/21617

Trac:
Keywords: N/A deleted, TorBrowserTeam201706R added
Status: needs_information to needs_review

Replying to cypherpunks:

RWX pages in Tor and its ssleay32.dll, libeay32.dll, zlib1.dll don't bother you?

Thanks for reporting these; I opened legacy/trac#22563 (moved).

Nice work (as dmajor already said)! Applied to tor-browser-52.2.0esr-7.5-1 (commit dda0385c).

Arthur: I wonder whether we should make an argument on the Mozilla ticket for getting this included into esr52? It feels to me all Windows users should benefit from this security enhancement.

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

Replying to gk: Why are you so hurry about closing ticket about long-standing security problem? No conclusions about issues in comment:7 (from comment:4) were made, even a comment. There is some feeling that it's not enough for reopening the ticket (for you), so: softokn3.dll and freebl3.dll have W^X pages on Windows 10 (15063).

Trac:
Resolution: fixed to N/A
Status: closed to reopened

Also tor.exe on the same machine has something strange in memory:

0x7ffcab38b000, Private: Reserved, 13 971 860 kB,
0x7fff0000, Private: Reserved, 137 422 882 560 kB,

It looks related to legacy/trac#22255 (moved).

Replying to gk:

Arthur: I wonder whether we should make an argument on the Mozilla ticket for getting this included into esr52? It feels to me all Windows users should benefit from this security enhancement.

Good suggestion -- I put in a request: https://bugzilla.mozilla.org/show_bug.cgi?id=1344034#c9

Replying to cypherpunks:

Replying to gk: Why are you so hurry about closing ticket about long-standing security problem?

Because we fixed the particular issue this ticket was about.

No conclusions about issues in comment:7 (from comment:4) were made, even a comment. There is some feeling that it's not enough for reopening the ticket (for you), so: softokn3.dll and freebl3.dll have W^X pages on Windows 10 (15063).

Could you open follow-up tickets for these problems please with steps to reproduce for us? Thanks.

Trac:
Resolution: N/A to fixed
Status: reopened to closed

Replying to gk:

Replying to cypherpunks:

Replying to gk: Why are you so hurry about closing ticket about long-standing security problem?

Because we fixed the particular issue this ticket was about.

No conclusions about issues in comment:7 (from comment:4) were made, even a comment. There is some feeling that it's not enough for reopening the ticket (for you), so: softokn3.dll and freebl3.dll have W^X pages on Windows 10 (15063).

Could you open follow-up tickets for these problems please with steps to reproduce for us? Thanks.

I opened legacy/trac#22584 (moved). I wonder if the person who observed this could comment if it was necessary to visit any particular websites to trigger these RWX pages.

Replying to arthuredelstein:

Replying to gk:

Replying to cypherpunks:

Replying to gk: Why are you so hurry about closing ticket about long-standing security problem?

Because we fixed the particular issue this ticket was about.

No conclusions about issues in comment:7 (from comment:4) were made, even a comment. There is some feeling that it's not enough for reopening the ticket (for you), so: softokn3.dll and freebl3.dll have W^X pages on Windows 10 (15063).

Could you open follow-up tickets for these problems please with steps to reproduce for us? Thanks.

I opened legacy/trac#22584 (moved). I wonder if the person who observed this could comment if it was necessary to visit any particular websites to trigger these RWX pages. OK, as you show you're interested in solving these issues, and don't close tickets without explanations or follow-ups as somebody else, then I'll put comments in that ticket.

closed

moved from legacy/trac#21617 (moved)

added Bug label and removed 1 deleted label

added 1 deleted label and removed 1 deleted label

added Security label and removed 1 deleted label