From owner-freebsd-security@FreeBSD.ORG Mon Apr 21 00:13:33 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCC48224 for ; Mon, 21 Apr 2014 00:13:32 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B758C137F for ; Mon, 21 Apr 2014 00:13:32 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s3L01NvZ062804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Apr 2014 17:01:23 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s3L01M8X062803; Sun, 20 Apr 2014 17:01:22 -0700 (PDT) (envelope-from jmg) Date: Sun, 20 Apr 2014 17:01:22 -0700 From: John-Mark Gurney To: hcoin Subject: Re: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140421000122.GS43976@funkthat.com> Mail-Followup-To: hcoin , freebsd-security@freebsd.org 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53540307.1070708@quietfountain.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 20 Apr 2014 17:01:23 -0700 (PDT) Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 00:13:33 -0000 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 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."