Make SSP use Windows-specifc RNG

According to skruffy by way of arma, SSP may not be applied on our Windows builds: https://trac.torproject.org/projects/tor/ticket/10065#comment:31

I am not sure why not, or how skruffy checked. It looks like we are using -fstack-protector in our wrapper scripts.

Did skruffy use a tool like: https://www.microsoft.com/en-us/download/details.aspx?id=11910

Is it possible that those tools are simply not recognizing the MinGW version of SSP?

added GeorgKoppen201502R TorBrowserTeam201502R component::applications/tor browser owner::tbb-team priority::medium resolution::fixed status::closed tbb-security type::defect labels

Trac:
Cc: arma to arma, gk

This bug is actually about this patch not getting applied:

https://gitweb.torproject.org/user/erinn/tor-browser-bundle.git/blob/17425dec3a13de51b717efeb8bdde1a4460d31fa:/gitian/patches/windows-crypto.patch

skruffy's reasoning is that since it's possible for a local user to replace the canaries, SSP is not actually enabled.

I am not clear from the context in this patch where the canaries normally come form on Windows. It looks like it is trying to use the Windows crypto provider instead of /dev/urandom? Is that correct? Or was it failing to access /dev/urandom because it didn't exist, and then using something else?

What is this patch applying to? gcc or binutils?

Trac:
Summary: SSP may not applied to Windows TBB? to Make SSP use Windows-specifc RNG

It looks like it is trying to use the Windows crypto provider instead of /dev/urandom? Is that correct?

Yes.

What is this patch applying to? gcc or binutils?

GCC.

In Windows you can to create any directories for any disks(C:, D:, .. Z:), only system directories (Windows directory, Program files, etc) are protected. Any process with privileges of any standard user can to create C:\dev\urandom file and to fill it by any stuff.

Ok, after the Firefox 31 madness calms down a bit, we should be able to apply this.

Has it been submitted to the mingw people?

Trac:
Keywords: N/A deleted, MikePerry201410R, TorBrowserTeam201410 added

Trac:
Keywords: TorBrowserTeam201410 deleted, TorBrowserTeam201411 added

Trac:
Keywords: N/A deleted, TorBrowserTeam201412R added

Trac:
Keywords: TorBrowserTeam201411 deleted, TorBrowserTeam201412 added

Trac:
Keywords: TorBrowserTeam201412R deleted, TorBrowserTeam201501R added

Trac:
Keywords: TorBrowserTeam201412 deleted, TorBrowserTeam201501 added

Trac:
Keywords: TorBrowserTeam201501R deleted, TorBrowserTeam201502R added

Trac:
Keywords: TorBrowserTeam201501 deleted, TorBrowserTeam201502 added

gk - You're on the mingw lists, right? Can you get this patch to them and see what they think?

Trac:
Keywords: MikePerry201410R, TorBrowserTeam201502 deleted, GeorgKoppen201502R added

gk - You're on the mingw lists, right? Can you get this patch to them and see what they think?

Trac:
Status: new to needs_review

Replying to mikeperry:

gk - You're on the mingw lists, right? Can you get this patch to them and see what they think?

Now, yes. http://sourceforge.net/p/mingw-w64/mailman/message/33336127/ contains the mail to the list.

Jacek looked at it (http://sourceforge.net/p/mingw-w64/mailman/message/33344781/) and made some suggestions which seemed reasonable and indicated that he thinks the patch is doing what it promises but could be enhanced. On the other hand he claimed to have not much knowledge about GCC/libssp and pointed to the gcc-patches mailing list (which I try next).

The mail to gcc-patches: https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00386.html

The patch got merged into GCC trunk as 19fef1633156a2c7ddd267b43d08f1b245a6e1f4. Commit d4950e565f93396ebbd310c71e49576af9224d25 contains the proper backport for our use case.

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

closed

moved to tpo/applications/tor-browser#13169 (closed)