Date: Sat, 9 Jul 2005 09:59:04 +1000 (EST) From: Neo-Vortex <root@Neo-Vortex.net> To: ALeine <aleine@austrosearch.net> Cc: freebsd-hackers@freebsd.org, jeremie@le-hen.org Subject: Re: ProPolice: best way to fill canary Message-ID: <20050709095826.T18020@Neo-Vortex.net> In-Reply-To: <200507081513.j68FDrkh062029@marlena.vvi.at> References: <200507081513.j68FDrkh062029@marlena.vvi.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 8 Jul 2005, ALeine wrote: > root@Neo-Vortex.net wrote: > > > On Fri, 8 Jul 2005, Jeremie Le Hen wrote: > > > > > Hello hackers, > > > > > > I'm going to disturb you once again with ProPolice. The > > > original ProPolice patch, as well as most of FreeBSD variants > > > and Linux one, uses /dev/urandom to fill the "canary" with > > > random data (the canary is what is going to be put between > > > buffer and return address in the stack). OTOH, OpenBSD uses > > > kern.arnd sysctl to achieve this (this is a sysctl front-end > > > to the arc4random() function). > > > > Just one question, why does the canary have to be filled with > > random data? Why not just zero it? sure you get a single random > > value to find out how many zero's to use, but why waste that much > > good-quality random data (and of course if there isn't enough in > > urandom, you would have to make it loop till there is enough unless > > you make it just leave the rest as-is) > > > > IMHO there is no advantages (well, that i can see) of having it > > random data rather than just NULL... > > > > Feel free to correct me if i'm wrong... > > You're wrong, when the canary value is fixed and known (such as in > terminator canaries), there are cases where an attacker could manage > to reset the canary to the expected value and circumvent the protection > mechanism. That chance doesn't exist with random canaries. AFAIK, > ProPolice supports both terminator and random canaries. > > As for the original topic, I would prefer the sysctl front-end, IMO it's > more consistent with other BSDs and more clean and direct while extending > open(2) would only appear transparent at the expense of needlessly > increasing the complexity of open(2). I was meaning random length fixed value... and unless the attacker wants to set the return address to 0x0... ~NVX
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050709095826.T18020>