Re: ssp, __strcpy_ck: just to be sure

[tlaronde%polynum.com@localhost]

On Tue, Nov 17, 2020 at 03:07:05PM -0500, Mouse wrote:
> >> But [...] __ssp_overlap succeeded to pinpoint the overlap with the
> >> buffer declared as an (fixed size) array but not when it was
> >> dynamically allocated.
> > Correct, the SSP primitives will only ever work for static buffers.
> 
> But they are designed and intended to catch stack-smashing potential,
> are they not?  In that case, this is what I'd expect, because a
> dynamically allocated buffer is not on the stack and thus inherently
> has no stack-smashing potential.
> 
> Unless "dynamically allocated" here means something like a
> variable-sized array or alloca(), which isn't what it sounded like.

My initial fuzzy understanding was, too, that it has something to do
with Stack Smashing Protection. But it appears that checking bounds for
string functions was added _too_ under the same SSP flag with
FORTIFY_SOURCE. ssp(3) indeed says "Buffer Overflow Protection Library"
"perform bounds check [...] in order to avoid data buffer or stack
buffer overflows".

But it is added too that it uses __builtin_object_size(3) so this is why
I wanted to have confirmation by more informed people that I had
correctly read the doc (and partly the sources): that the check wasn't
designed to work with dynamic allocation (to be sure I had indeed
adressed the problem in the code that was aborting and not simply
made the symptoms disappear by chance).

-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C