Re: Patch to further harden glibc malloc metadata against 1-byte overflows

[Carlos O'Donell <carlos at redhat dot com>]

On 03/21/2017 07:14 PM, DJ Delorie wrote:
> Chris Evans <scarybeasts@gmail.com> writes:
>> As a follow up question: is there any appetite for any additional
>> glibc malloc metadata checks? While studying the code, I noticed a few
>> extra checks that could be added here and there. I don't think any of
>> them would be as useful as security defenses, but maybe they could
>> trap heap corruptions closer to the time they occurred. Any interest?
> 
> I'm open to more malloc hardening, sure.  Better to fix the holes
> *before* they're turned into exploits, as long as performance doesn't
> suffer too much.
> 
> If you're going to be a regular contributor now, though, we might
> consider streamlining the process a bit ;-)

Excellent work hardening glibc malloc further.

(1) Copyright assignment.

Obligatory link to "Contribution Checklist":
https://sourceware.org/glibc/wiki/Contribution%20checklist

Please make sure contributors have copyright assignment on file
with the FSF, otherwise we have a limit of ~15 lines of legally
significant changes. The current FSF copyright list does not have
Chris Evans on it.

With these 2 lines, Chris has 13 lines left before we need copyright
assignment.

(2) Needs a bug number.

This is a user visible change in behaviour i.e. we now catch another
overflow (which might have been benign in some case) and assert.

(3) Regression test.

We need a regression test for this. Please add one. We want to
have code coverage of the new assertion.

We should be militant about adding regression tests for all
of these security related features to make sure we don't
regress.

You'll have to wrap the test in a script (examples of this exist),
check the exit code, and have the script exit appropriately.

-- 
Cheers,
Carlos.