On Wed, Sep 14, 2016 at 05:41:55AM +0200, Theo Buehler wrote:
> On Tue, Sep 13, 2016 at 01:29:17PM +0200, Otto Moerbeek wrote:
> > As often, real life came in between. Did anybody do measurements? I
> > really would like to to see hard data.
>
> It seems that the price is relatively modest.
>
>
On Fri, Sep 16, 2016 at 09:30:15PM +0200, Otto Moerbeek wrote:
> On Thu, Sep 15, 2016 at 10:08:26AM -0400, Ted Unangst wrote:
>
> > Otto Moerbeek wrote:
> > > On Wed, Sep 14, 2016 at 12:53:05PM -0400, Ted Unangst wrote:
> > >
> > > > Daniel Micay wrote:
> > > > >
> > > > > The current OpenBSD c
On Thu, Sep 15, 2016 at 10:08:26AM -0400, Ted Unangst wrote:
> Otto Moerbeek wrote:
> > On Wed, Sep 14, 2016 at 12:53:05PM -0400, Ted Unangst wrote:
> >
> > > Daniel Micay wrote:
> > > >
> > > > The current OpenBSD code only wipes up to MALLOC_MAXCHUNK with junk @ 1,
> > > > and it similarly doe
Otto Moerbeek wrote:
> On Wed, Sep 14, 2016 at 12:53:05PM -0400, Ted Unangst wrote:
>
> > Daniel Micay wrote:
> > >
> > > The current OpenBSD code only wipes up to MALLOC_MAXCHUNK with junk @ 1,
> > > and it similarly doesn't wipe at all with 'U' (even though junk-on-free
> > > also serves the pu
On Wed, Sep 14, 2016 at 12:53:05PM -0400, Ted Unangst wrote:
> Daniel Micay wrote:
> >
> > The current OpenBSD code only wipes up to MALLOC_MAXCHUNK with junk @ 1,
> > and it similarly doesn't wipe at all with 'U' (even though junk-on-free
> > also serves the purpose of preventing information lea
> Daniel Micay wrote:
> >
> > The current OpenBSD code only wipes up to MALLOC_MAXCHUNK with junk @ 1,
> > and it similarly doesn't wipe at all with 'U' (even though junk-on-free
> > also serves the purpose of preventing information leaks, not just
> > mitigating use-after-free). IMO, optimizing l
Daniel Micay wrote:
>
> The current OpenBSD code only wipes up to MALLOC_MAXCHUNK with junk @ 1,
> and it similarly doesn't wipe at all with 'U' (even though junk-on-free
> also serves the purpose of preventing information leaks, not just
> mitigating use-after-free). IMO, optimizing large allocat
On Tue, 2016-09-13 at 13:27 +0200, Otto Moerbeek wrote:
> On Thu, Sep 08, 2016 at 06:42:33PM -0400, Daniel Micay wrote:
>
> > A bit off-topic: 'J' enables junk-on-init which is for debugging,
> > but it
> > also currently has security improvements for large allocations.
> > There's
> > only partia
On Tue, Sep 13, 2016 at 01:29:17PM +0200, Otto Moerbeek wrote:
> As often, real life came in between. Did anybody do measurements? I
> really would like to to see hard data.
It seems that the price is relatively modest.
I ran several 'make build's:
3rd gen X1, i7 5500U, 2.4GHz (amd64):
On Wed, Sep 07, 2016 at 06:29:07PM -0400, Ted Unangst wrote:
> There's some overlap here with canaries, but nothing wrong with that. :)
The diff breaks canaries since random_junk() overwrites them before they
are validated. The following straightforward modification fixes that:
> Index: malloc.c
On Thu, Sep 08, 2016 at 08:15:42AM +0200, Otto Moerbeek wrote:
> On Wed, Sep 07, 2016 at 06:29:07PM -0400, Ted Unangst wrote:
>
> > Instead of always using a fixed byte pattern, I think malloc should use a
> > random pattern. Now, this sometimes means it's harder to identify exactly
> > what's us
On Thu, Sep 08, 2016 at 06:42:33PM -0400, Daniel Micay wrote:
> On Wed, 2016-09-07 at 18:29 -0400, Ted Unangst wrote:
> > Instead of always using a fixed byte pattern, I think malloc should
> > use a
> > random pattern. Now, this sometimes means it's harder to identify
> > exactly
> > what's used
> On Thu, Sep 08, 2016 at 07:47:58PM -0400, Daniel Micay wrote:
>
> > A nice security property of 0xdf filling is that a use-after-free of a
> > pointer is guaranteed to fault in a typical environment since it ends up
> > pointing outside userspace (I assume that's the case on OpenBSD). A heap
> >
On Thu, Sep 08, 2016 at 07:47:58PM -0400, Daniel Micay wrote:
> A nice security property of 0xdf filling is that a use-after-free of a
> pointer is guaranteed to fault in a typical environment since it ends up
> pointing outside userspace (I assume that's the case on OpenBSD). A heap
> spray could
A nice security property of 0xdf filling is that a use-after-free of a
pointer is guaranteed to fault in a typical environment since it ends up
pointing outside userspace (I assume that's the case on OpenBSD). A heap
spray could potentially allow exploiting a random pointer. Perhaps it
would be bet
> BTW, we should revisit canaries and work further on moving them
> closer to requested size. There's a chance this diff wil complicate
> that.
Can switch the canary code to memcpy/memcmp (to handle unaligned
canaries) and could then use the last byte as an index to the start of
the canary. For la
On Wed, 2016-09-07 at 18:29 -0400, Ted Unangst wrote:
> Instead of always using a fixed byte pattern, I think malloc should
> use a
> random pattern. Now, this sometimes means it's harder to identify
> exactly
> what's used after free, so we should provide a means to get the old
> 0xdf
> pattern ba
On Wed, Sep 07, 2016 at 06:29:07PM -0400, Ted Unangst wrote:
> Instead of always using a fixed byte pattern, I think malloc should use a
> random pattern. Now, this sometimes means it's harder to identify exactly
> what's used after free, so we should provide a means to get the old 0xdf
> pattern
Instead of always using a fixed byte pattern, I think malloc should use a
random pattern. Now, this sometimes means it's harder to identify exactly
what's used after free, so we should provide a means to get the old 0xdf
pattern back.
Since we already have two junk modes, I thought I'd carry on al
19 matches
Mail list logo
