Re: [PATCH v2 0/3] posix: Execute file function fixes

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 19-02-2016 16:33, Paul Eggert wrote:
> On 02/19/2016 10:05 AM, Adhemerval Zanella wrote:
>> * Regarding stack allocation safeness for exec function family I saw no
>>    safe solution.
> 
> This is a significant regression from the current behavior. We need a better solution. Otherwise, I fear that it will be too easy for attackers to exploit stack-overflow vulnerabilities by attempting to execute commands with many arguments.
> 

I do not agree it is a regression since it fixes two important issues: 
exec async-signal-safeness and vfork usage. Also the vector of attack
might be limited, since for calling these function will issue a lot of 
stack will usage for argument passing.

As I said, current dynamic memory allocation usage is plainly wrong and
lead to the two mentioned issues.  We can go to arch-specific implementation
that abuse the ABI with, but again I think they are hacks and just add
more maintainability burden and runtime differences among the platforms.

A possible solution is add thread specific scratch buffer, but again this
is not async-safe. 

>>    libc has no obligation in make sure the stack allocation is suffice to
>>    fix runtime constraints.
> 
> Is this really true?  Then why does libc have __libc_use_alloca? Why not dispense with __libc_use_alloca and have libc impose no limits on stack allocation?

The current '__libc_use_alloca' is a fragile and arbitrary stack control flow
and since it does not track total stack usage against runtime imposed limit
it does not add anything related to security. Currently as is I see no
compelling reason to continue using it.