From owner-freebsd-security@freebsd.org Wed Jun 29 12:36:31 2016 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDEBEB730F5 for ; Wed, 29 Jun 2016 12:36:31 +0000 (UTC) (envelope-from david.i.noel@gmail.com) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87DD82209 for ; Wed, 29 Jun 2016 12:36:31 +0000 (UTC) (envelope-from david.i.noel@gmail.com) Received: by mail-vk0-x230.google.com with SMTP id m127so4129791vkb.3 for ; Wed, 29 Jun 2016 05:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=NsgYVz3TvHWYSZ7Lt+aoc9VE3no0VqG2x4ibR7wlWlk=; b=sQaCjo28R0RpDfzqV6o3wZ3o0CdipY3fzNYoCF+/G6SloU7MiSqtXx8Ki5NOk+RXMS /pnYN9v5Q2+LFj4iXT/qtrjC9ChK2Zsk3hTeMqogB5VR9Hwyrr+gGNmvbWiTXwfNNgNO OCcB4D7g88nk42vO2a55ZX5XA9o2qQpD7CSBJBITjVnjtFQs1twO+2hzr+KqIxNg6TiV XNc62qpxYvsAXhFWmCutS+aBrAlqk84q1zlhXXm9MTkH8am6cDA7o3d/TuXijDTcWOwE 5ECjhqYTKXU3v7nGfhfpcpP/7BhcX7ejVO7vbsnH2uDJy1QWv7zy261LqN69PAJYB2kD yRhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=NsgYVz3TvHWYSZ7Lt+aoc9VE3no0VqG2x4ibR7wlWlk=; b=WAoCptOhlMX5TXheiOhPcF+nm/ZH4q502/eSo/evg7Mlzn/bxCMEvUZE6fBjSLafF0 BMNPAmVxeTC8/p9sTn4OKzzLFF10i/sd9iIpI0ysWvwF4k/P7yT21siUaBet/HhouhFZ g/j2ne8hypEINdjBiJNPGISxBqNkRl7hIj6kDXfHKoi/EcMyCXC1zIgjfG8on0PLUn// i8sEu9KF2PKsqUZwc7smekgDIBPdmroqgr9TbE+RoSOnZ66rJJSG54okkp1Wzd0Y5mou XnqEvrhQoHNbbCyDRM7QQmDR0QIcB/t2D6sFTmPzKL6ulClj327Ghvzrm2Gq5bRMfsXa P1oQ== X-Gm-Message-State: ALyK8tKBM2lqQ7WvYLEPCYzGcbwzKMY2o9VbM8XL8jw07yXluuCvTwsbJn8Tjiyu45GCcrjHG/FWoc+VVn/E1g== X-Received: by 10.176.5.103 with SMTP id 94mr2981847uax.129.1467203790578; Wed, 29 Jun 2016 05:36:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.100.2 with HTTP; Wed, 29 Jun 2016 05:36:29 -0700 (PDT) Reply-To: David.I.Noel@gmail.com In-Reply-To: <44255.1467112146@server1.tristatelogic.com> References: <44255.1467112146@server1.tristatelogic.com> From: David I Noel Date: Wed, 29 Jun 2016 07:36:29 -0500 Message-ID: Subject: Re: Stuff I don't understand, and maybe never will. To: "Ronald F. Guilmette" Cc: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 12:36:31 -0000 On 6/28/16, Ronald F. Guilmette wrote: ... > I've just seen a link to the following in my twitter feed: > > http://googleprojectzero.blogspot.com/2016/06/a-year-of-windows-kernel-fo= nt-fuzzing-1_27.html > > Short summary: Apparently a team @ Google spend a whole bloody year, > just to find a handful of bugs in the Windows 7 kernel. ... > I was floored by the assertion (and the perhaps well known fact... to > everybody except me) that something as ridiculous as font processing > was actually embedded into the Windoze 7 kernel. I mean seriously, > who ever thought that THAT was a good idea?? Putting that kind of > crap inside a *kernel* goes against pretty much my entire understanding > of what a kernel should be. (And apparently, even MS was wised up to > the incomprehensible stupidity of this now, and has moved this crap > outside the kernel in Windows 10, as the article itself states.) > > Last but by no means least, the authors bemoan the difficulties they > had finding *security* bugs in code they didn't have access to the > source code for. ... > is anybody > in their right minds who actually gives a serious rats's ass about securi= ty > really going to continue to just hope and pray that they'll be safe while > putting all their secrets on top of a closed source OS? ... > Some of the stuff I encounter these days is just > almost too absurd for words. > > Regards, > rfg > > P.S. I myself developed a trivial (but powerful) sort of fuzzing tool > about ten years ago. To this day, I'm disappointed that nobody but me > ever saw fit to actually use the thing. > > Here it is and its free: http://www.tristatelogic.com/m4r/ I agree with the essence of your message: that this article brings up some very important lessons we should all use as something to think about--what should and what should not be running in kernel space (or as root[1]) by default, what are the risks, the performance trade-offs, and whether those trade-offs worth the security gains of making the changes vs some alternative/s (and if so what is that/are those alternative=E2=80=99s?) Also, highlighting the continued relevance of fuzzing and the shared frustration at the lack of its more wide-spread adoption and recognition as a useful, relevant, and valid tool for finding bugs in code. Is anyone actively fuzzing FreeBSD? As far as the kernel, all I can see is that it's listed as an =E2=80=9CIdea= =E2=80=9D on the Wiki (https://wiki.freebsd.org/IdeasPage -- 5.4). Beyond the kernel, what about the ports collection? Some of them are an absolute^W^W^W could probably use a once-over with AFL or others. Why not start a =E2=80=9CFizz[2.1] *BSD Day=E2=80=9D?[2.2] David 1. One simple example could be: ... a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-16:24/ntp.patch # fetch https://security.FreeBSD.org/patches/SA-16:24/ntp.patch.asc # gpg --verify ntp.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch ... ...a much less simple example would be something along the lines of X. 2.1. I figured in the spirit of things: Can=E2=80=99s, =E2=80=9CFree as in = beer=E2=80=9D, etc... 2.2 Though unless the final note in the =E2=80=9CDescription=E2=80=9D on th= e Wiki is accurate it seems the Fuzzing/"Fizzing" will have to be limited to the ports collection: =E2=80=9CA native tool would be good but perhaps just running the Trinity tool under the linux emulator, and memguard, would reveal general bugs in the kernel.=E2=80=9C