This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 0/3] posix: Execute file function fixes
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, libc-alpha at sourceware dot org
- Date: Fri, 19 Feb 2016 17:14:49 -0200
- Subject: Re: [PATCH v2 0/3] posix: Execute file function fixes
- Authentication-results: sourceware.org; auth=none
- References: <1455905134-21014-1-git-send-email-adhemerval dot zanella at linaro dot org> <56C75FE3 dot 2030606 at cs dot ucla dot edu>
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.