On 04/20/2014 07:01 PM, John-Mark Gurney wrote: > hcoin wrote this message on Sun, Apr 20, 2014 at 12:25 -0500: >> On 04/20/2014 12:48 AM, Jamie Landeg-Jones wrote: >>> Bryan Drewery <[email protected]> wrote: >>> >>>> On 4/14/2014 7:32 AM, Jamie Landeg-Jones wrote: >>>>> As to the specific question, I don't think his ego would allow a bug >>>>> in openssh to persist, so even if it does, I'd suspect it's not too >>>>> serious (or it's non-trivial to exploit), and it's related to FreeBSD >>>>> produced 'glue'. >>>>> >>>>> This is total guesswork on my part, but I'd therefore assume he was >>>>> talkining about openssh in base, rarther than openssh-portable in >>>>> ports. >>>>> >>>> As the maintainer of the port I will say that your security decreases >>>> with each OPTION/patch you apply. I really would not be surprised if one >>>> of the optional patches available in the port had issues. >>> Ahhhh. good point. I forgot about third-party patches. >>> >>> Yeah, if he's not just blowing smoke, that would make the most sense. >>> >>> I don't reckon he'd leave an exploit open if it was purely related to >>> the unpatched source - even if there is some quirk which only makes >>> it only applicable to FreeBSD. >>> >>> Still, by not revealing it, he's only potentially hurting the users. >>> >>> I wonder how many blackhats are going to use this thread as a heads-up? >>> >>> Cheers, Jamie >>> _______________________________________________ >>> >> I wonder how many security holes, both those known and as yet unrevealed >> or unknown, would not be of any exploit value if in all security related >> libraries and applications the routine to free allocated memory >> allocation closest to the user app/library set the newly free memory to >> a known pattern or something from /dev/random before returning. And, >> similarly, a compiler option causing function returns using more than a >> few dozen bytes of stack space to erase the newly freed stack region >> just prior to resuming the caller. > there is an option to do this w/ malloc(3): > J Each byte of new memory allocated by malloc(), realloc(), or > reallocf() will be initialized to 0xa5. All memory returned by > free(), realloc(), or reallocf() will be initialized to 0x5a. > This is intended for debugging and will impact performance nega- > tively. > > This used to be eanbled by default on HEAD, but apparently isn't any > more... > There can be no doubt causing the free call furthest from the operating system to erase memory, (and just as importantly, a compiler option that erases the content of the stack space upon function return for all functions that used more than a couple dozen bytes of stack space in local variables) harms performance. It's also true doing both of these things would not fix the flaw that 'opened the window' onto these data. However it is true that doing so would make the exploit valueless as 'opening a window' onto erased data would reveal nothing and could erase trojan/virus 'hijack via code-injection then trampoline' opportunities. If the variable stack and free() functions erased data spaces, there would be no security value in having application edge malloc effectively be calloc. There may be marginal security value in having OS edge free() erase data before subsequent OS edge malloc of the same page to a process owed by a different userid. This entire discussion, (clear-on-free and clear-stack-on-function-return) are resource heavy ways of managing complexity. It is for the community to decide whether it is 'worth it' on a case by case basis given there is no way to prove a program 'correct' from a security perspective. Harry _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"