On 30 December 2017 at 06:44, Otto Moerbeek wrote:
> On Sat, Dec 30, 2017 at 06:53:44AM +, kshe wrote:
>
>> Hi,
>>
>> Looking at this diff and the previous one, I found some more possible
>> cleanups for malloc.c (the patch below is to be applied after both of
>> them, even if the second one h
> In the end all double frees still will be caught by the actual free
> code, just with a delay. The delayed free buffer double free check is
> just a way of catching it as soon as possible to make debugging
> easier. That's the reason the originla code could just do the check
> on the slot being
On Sat, 2017-09-23 at 09:32 +0200, Otto Moerbeek wrote:
> On Fri, Sep 22, 2017 at 04:35:39PM -0400, Daniel Micay wrote:
>
> > A linear search works well for the current small quarantine (16) but
> > won't work
> > well if you ever want to have a larger / configurable
A linear search works well for the current small quarantine (16) but won't work
well if you ever want to have a larger / configurable quarantine size. It would
also be nice to make this fast enough to enable by default.
We (CopperheadOS) use an open addressed hash table for this based on the
exist
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
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
> Seems valuable. Note, though, that you're developing on top of the
> multi-pool malloc patches:
>
> https://marc.info/?t=14587167622&r=1&w=2
>
> http://www.drijf.net/openbsd/malloc/
>
> So there are probably conflicts.
Yeah, there will be some small changes required to where it integrates
This uses a hash table to maintain a set of delayed allocations, allowing full
and efficient double-free detection. The current code can only catch it when
the two pointers being swapped are equal, so double-frees that could be caught
are missed. A naive loop over every delayed chunk would work fin
Sorry, my mail client was being stupid. Lets try again in good old mutt:
diff --git a/stdlib/malloc.c b/stdlib/malloc.c
index bc328d2..aa6f0a3 100644
--- a/stdlib/malloc.c
+++ b/stdlib/malloc.c
@@ -1224,8 +1224,9 @@ malloc(size_t size)
r = omalloc(d, size, 0, CALLER);
d->active--;
The ENOMEM errno wasn't being set in some code paths where it was gated
behind mopts.malloc_xmalloc:
diff --git a/stdlib/malloc.c b/stdlib/malloc.c
index bc328d2..aa6f0a3 100644
--- a/stdlib/malloc.c
+++ b/stdlib/malloc.c
@@ -1224,8 +1224,9 @@ malloc(size_t size)
r = omalloc(d, size, 0, CA
> - Curently fixed at 4 pools with a fixed thread -> pool mapping.
> - All pools are always initialized, even for single threaded programs,
> where
> only one pool is used.
> - Especially realloc gets quite a bit uglier.
> - I'm pondering storing the thread -> pool mapping in the thread
> struc
On Wed, 2015-12-09 at 07:47 -0500, Ted Unangst wrote:
> This is a kind of two steps forward, one step back diff.
>
> I would like for the canary to be placed directly adjacent to the end
> of the
> user specified size. No slack. To accomplish this, we record the
> original size
> of the allocation
On Sun, 2015-12-06 at 17:10 -0700, Theo de Raadt wrote:
> Kept out of circulation? It sounds like it would be incredibly
> expensive data-structure wise for the kernel to even attempt such a
> gaurantee..
I was just expecting it to be a FIFO ring buffer. It would have a limit
on the number of map
It would also be interesting to try out a more aggressive form of
freeunmap for 64-bit where the allocations are purged with MADV_FREE
and then the virtual memory is kept out of circulation with a similar
FIFO queue approach. Could potentially do it by default when malloc
hints are enabled, so it w
It would be great to land this simple initial implementation and move
from there. I have ideas on how to make these features better but I'm
wary of doing a lot of work out-of-tree. If it lands in some form, that
would go a long way to encouraging further work on it. I basically just
don't want to e
> It may also be viable as a security feature in some situations, not just
> a way of finding bugs. Depends on how far away the UAF is from the free
> call since one other free is all that's needed to lose reliable
> detection. It might work better with a FIFO ring buffer rather than the
> current
be viable as a security feature in some situations, not just
a way of finding bugs. Depends on how far away the UAF is from the free
call since one other free is all that's needed to lose reliable
detection. It might work better with a FIFO ring
(without mangling it this time...)
diff --git a/stdlib/malloc.c b/stdlib/malloc.c
index 424dd77..c408594 100644
--- a/stdlib/malloc.c
+++ b/stdlib/malloc.c
@@ -182,6 +182,7 @@ struct malloc_readonly {
int malloc_freeunmap; /* mprotect free pages PROT_NONE? */
int mall
On 26/10/15 04:19 PM, Daniel Micay wrote:
> This is an improved revision of my earlier patch.
>
> It now validates the junk data in the delayed_chunks array in an atexit
> handler
> too, rather than just when allocations are swapped out.
>
> It will now catch this simple
This is an improved revision of my earlier patch.
It now validates the junk data in the delayed_chunks array in an atexit handler
too, rather than just when allocations are swapped out.
It will now catch this simple UAF 100% of the time:
#include
#include
int main(void) {
size_t i;
char *
On 25/10/15 06:20 PM, Ted Unangst wrote:
> Daniel Micay wrote:
>> This patch adds an opt-in malloc configuration option placing canaries after
>> small allocations to detect heap overflows on free(...). It's intended to be
>> used alongside guard pages for large allocatio
On 23/10/15 07:22 AM, Janne Johansson wrote:
> With this patch on -current and
> ln -sf CJ /etc/malloc.conf
> a lot of things stopped working, like "man ls" and "tmux".
> With only C or only J, the system seems to work ok, but with both it
> doesn't.
> Will check the resulting core files.
> ntpd an
Er, here it is without the screwed up whitespace (whoops):
diff --git a/stdlib/malloc.c b/stdlib/malloc.c
index 424dd77..7c33a7a 100644
--- a/stdlib/malloc.c
+++ b/stdlib/malloc.c
@@ -182,6 +182,7 @@ struct malloc_readonly {
int malloc_freeunmap; /* mprotect free pages PROT_NONE?
This patch adds a form of use-after-free detection based on validating that
the junk data is still in place when swapping out an allocation from the
delayed chunk cache. It will probably nearly double the cost of the junk free
feature that's enabled by default since it needs to do a whole extra pas
Hi,
This patch adds an opt-in malloc configuration option placing canaries after
small allocations to detect heap overflows on free(...). It's intended to be
used alongside guard pages for large allocations. Since it's essentially
adding extra padding to all small allocations, a small heap overflo
27 matches
Mail list logo