Date: Sun, 20 Apr 2014 17:01:22 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: hcoin <hcoin@quietfountain.com> Cc: freebsd-security@freebsd.org Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140421000122.GS43976@funkthat.com> In-Reply-To: <53540307.1070708@quietfountain.com> References: <534B11F0.9040400@paladin.bulgarpress.com> <201404141207.s3EC7IvT085450@chronos.org.uk> <201404141232.s3ECWFQ1081178@catnip.dyslexicfish.net> <53522186.9030207@FreeBSD.org> <201404200548.s3K5mV7N055244@catnip.dyslexicfish.net> <53540307.1070708@quietfountain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <bdrewery@FreeBSD.org> 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...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140421000122.GS43976>