[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#866686: libc6: The stack clash fix is insufficient, because it doesn't increase the stack guard gap for thread stacks



On 2017-06-30 23:56, Mikulas Patocka wrote:
> Package: libc6
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>    * What led up to the situation?
> 
> The stack clash patch modifies the kernel so that there is 1MB gap below the
> stack. If a single function allocates 1MB or less space on its stack frame, it
> would hit the gap and it couldn't overwrite heap.
> 
> However, the stack gap for thread stacks is still 4k, meaning that the whole
> stack clash exploit could be still used against multithreaded programs.

The guard size for threads can be changed by calling the
pthread_attr_setguardsize function before the thread creation. POSIX
clearly defines the default thread guard size to be PAGESIZE:

"The default value of the guardsize attribute is PAGESIZE bytes. The
actual value of PAGESIZE is implementation-dependent and may not be the
same on all implementations."

>    * What exactly did you do (or not do) that was effective (or
>      ineffective)?
>    * What was the outcome of this action?
> 
> Run pmap on any multithreaded process and you can see that there is only 4k gap
> below the thread stack, for example:
> 00007f931d83d000      4K -----   [ anon ]
> 00007f931d83e000   8192K rw---   [ anon ]
> 00007f931e03e000      4K -----   [ anon ]
> 00007f931e03f000   8192K rw---   [ anon ]
> 00007f931e83f000      4K -----   [ anon ]
> 00007f931e840000   8192K rw---   [ anon ]
> 00007f931f040000      4K -----   [ anon ]
> 00007f931f041000   8192K rw---   [ anon ]
> 00007f931f841000      4K -----   [ anon ]
> 00007f931f842000   8192K rw---   [ anon ]
> 
>    * What outcome did you expect instead?
> The libc should be modified so that there is 1MB guard area below the thread
> stack.
> 

I am not sure we should violate POSIX there. This probably has to be
discussed with upstream first.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: