This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: alloca avoidance patches


On 06/19/2017 11:59 AM, Florian Weimer wrote:
> As you might have seen, today a vulnerability was disclosed in
> glibc/Linux/GCC, concerning alloca/VLAs, large stack frames, and
> aliasing the stack and the heap.
> 
> I have posted an immediate stop-gap patch for the dynamic linker to fix
> CVE-2017-1000366/swbz#21624.  This should go in ASAP and should be
> backported.
> 
> I also have non-conforming patches which use NAME_MAX and PATH_MAX for
> additional mitigations.  I'll post them shortly, but I expect that only
> distributions will pick them up because they do not follow GNU standards
> and will not work on the Hurd.

In the case of NAME_MAX and PATH_MAX we should define something
for use internally in the loader and apply that limit as a
restriction for SUID binaries. The fact that this does not follow
the GNU standards, is unfortunate, but we must act on behalf of our
users.

The safety of our users and protecting them against exploits is
paramount in my opinion, and we should adopt such limits for SUID
binaries where it makes sense, even if we later back them out for
a better solution.

I think that even GNU/Hurd is susceptable to these kinds of attacks
since all modern operating systems follow the same models for stack
and heap usage. Therefore we still need the protections there, even
if temporary, until we have gcc's -fstack-check ready and operational
for compiling all of glibc.

To that end I have reviewed your 3 posted patches and suggested we
apply an arbitrary but small limit for GNU/Hurd SUID binaries.

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]