:: Re: [DNG] Nasty Linux systemd secur…
Forside
Slet denne besked
Besvar denne besked
Skribent: Andreas Messer
Dato:  
Til: dng
Emne: Re: [DNG] Nasty Linux systemd security bug revealed
Hi,

On Thu, Jul 22, 2021 at 07:53:58AM +0200, Didier Kryn wrote:
>     There's a choice of options in GCC to deal with stack protection.
> Eg:  -fstack-check
>
>     Plus a bunch of macros.
>
>     They all deal with allocation of automatic variables. For alloca(),
> instead, there's explicitely no check.


I don't find any reference about automatic variables in the docs regarding
this topic. Actually, the description of gcc's alloca() builtin states that
it behaves similar to automatic variables. However, all these macros will
not prevent you from stack overflow but only help you to detect one when it
already happened. Also, the way gcc implements the check (probing SP) works
for alloca and for automatic variables in the same way.

However, once you have detected a stack overflow, your application is
in an inconsistent state. Of course you can implement some kind of rescue.
(e.g using libsigsev) But you have to do a clean rewind of your app
state back to state before the overflow occurred. This can become quite
complex and hard to maintain. And then your're back to state before stack
overflow, but what is the application supposed to do then? Log and ignore
the request? Terminate? Ask the User?

The point is, an application should be designed such that a stack overflow
just can not occur. And this implies length checking, regardless if using
automatic vars or alloca.

>     In addition, the compiler is not informed of the invocation of
> alloca(); therefore the space allocated to non-static automatic
> variables may overlap with the space "allocated" by alloca().


No. This is wrong alloca() is implemented as compiler builtin and
does exactly the same as GCC does when allocating automatic vars on the
stack.

Prove: https://godbolt.org/z/abqK4T43c

The generated machine code is identical including the stack overflow
checking code.

cheers,
Andreas
--
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51