[tor-bugs] #22660 [Core Tor/Tor]: Guard against stack smashing attacks in tor

[Tor Bug Tracker & Wiki]

#22660: Guard against stack smashing attacks in tor
-------------------------------------+------------------------------------
 Reporter:  teor                     |          Owner:
     Type:  defect                   |         Status:  new
 Priority:  Medium                   |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor             |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:  tor-hardening, security  |  Actual Points:
Parent ID:                           |         Points:  0.5
 Reviewer:                           |        Sponsor:
-------------------------------------+------------------------------------

Old description:

> If we tor with -fstack-check (GCC, it's a no-op in clang[0]), it will
> protect against stack smashing attacks that jump the stack guard page(s):
> {{{
> Recompile all userland code (ld.so, libraries, binaries) with GCC's
>   "-fstack-check" option, which prevents the stack-pointer from moving
>   into another memory region without accessing the stack guard-page (it
>   writes one word to every 4KB page allocated on the stack).
> }}}
> III. Solutions, https://www.qualys.com/2017/06/19/stack-clash/stack-
> clash.txt
>
> {{{
> -fstack-check
> Generate code to verify that you do not go beyond the boundary of the
> stack. You should specify this flag if you are running in an environment
> with multiple threads, but only rarely need to specify it in a single-
> threaded environment since stack overflow is automatically detected on
> nearly all systems if there is only one stack.
> Note that this switch does not actually cause checking to be done; the
> operating system must do that. The switch causes generation of code to
> ensure that the operating system sees the stack being extended.
> }}}
> http://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Code-Gen-Options.html#Code-
> Gen-Options
>
> This protects against:
> {{{
> - a local-root exploit against ld.so and most SUID-root binaries
>   (CVE-2017-1000366, CVE-2017-1000379) on amd64 Debian, Ubuntu, Fedora,
>   CentOS;
> }}}
>
> There are remote attack possibilities mentioned in the paper as well.
>
> We might also want to add:
> {{{
> -Wl,-z,noexecstack and -Wl,-z,noexecheap
> }}}
> https://www.owasp.org/index.php/C-Based_Toolchain_Hardening#GCC.2FBinutils
>
> [0]: for clsng, we could use -fsanitize=safe-stack instead, but that's
> more intrusive: https://blog.quarkslab.com/clang-hardening-cheat-
> sheet.html

New description:

 If we tor with -fstack-check (GCC, it's a no-op in clang[0]), it will
 protect against stack smashing attacks that jump the stack guard page(s):
 {{{
 Recompile all userland code (ld.so, libraries, binaries) with GCC's
   "-fstack-check" option, which prevents the stack-pointer from moving
   into another memory region without accessing the stack guard-page (it
   writes one word to every 4KB page allocated on the stack).
 }}}
 III Solutions, https://www.qualys.com/2017/06/19/stack-clash/stack-
 clash.txt

 "
 -fstack-check
 Generate code to verify that you do not go beyond the boundary of the
 stack. You should specify this flag if you are running in an environment
 with multiple threads, but only rarely need to specify it in a single-
 threaded environment since stack overflow is automatically detected on
 nearly all systems if there is only one stack.
 Note that this switch does not actually cause checking to be done; the
 operating system must do that. The switch causes generation of code to
 ensure that the operating system sees the stack being extended.
 "
 http://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Code-Gen-Options.html#Code-
 Gen-Options

 This protects against:
 {{{
 - a local-root exploit against ld.so and most SUID-root binaries
   (CVE-2017-1000366, CVE-2017-1000379) on amd64 Debian, Ubuntu, Fedora,
   CentOS;
 }}}

 There are remote attack possibilities mentioned in the paper as well.

 We might also want to add:
 {{{
 -Wl,-z,noexecstack and -Wl,-z,noexecheap
 }}}
 https://www.owasp.org/index.php/C-Based_Toolchain_Hardening#GCC.2FBinutils

 [0]: for clsng, we could use -fsanitize=safe-stack instead, but that's
 more intrusive: https://blog.quarkslab.com/clang-hardening-cheat-
 sheet.html

--

Comment (by teor):

 My internal wiki wysiwyg is broken.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22660#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online