Date: Mon, 13 Dec 2021 13:24:38 +0100 From: jvoisin <julien.voisin@...tri.org> To: musl@...ts.openwall.com Cc: jvoisin <julien.voisin@...tri.org> 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.