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. Harry _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"