Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Dec 2021 13:24:38 +0100
From: jvoisin <>
Cc: jvoisin <>
Subject: Re: [PATCH] Zero the leading stack canary byte

> As written this patch assumes a 64-bit uintptr_t, which isn't ok.
> Indeed 56 bits should be fine on a 64-bit arch, but dropping from 32
> to 24 on a 32-bit arch severely weakens the protection. So it probably
> needs to be conditional on 64-bit.
Will do.

> Also, zeroing the first byte means we can no longer catch buffer
> overflows of the form "off-by-one string length". This seems
> unfortunate. Putting the 0 byte at the end would solve that at the
> expense of allowing the canary value to be leaked via missing
> termination bugs, and overall I would lean towards catching actual
> buffer overflow bugs vs stopping canary leaks.
As discussed on IRC, what about zero'ing the second byte instead? This
would allow to catch overflows, as well as preventing canary
leaks/overwrite via string-manipulating functions.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.