Date: Wed, 29 Jun 2016 07:36:29 -0500 From: David I Noel <david.i.noel@gmail.com> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-security@freebsd.org Subject: Re: Stuff I don't understand, and maybe never will. Message-ID: <CAHAXwYA6Rsb0X=5PLXHwyfG%2Bms7sNk2LStJo_KTYi5jaaphqJw@mail.gmail.com> In-Reply-To: <44255.1467112146@server1.tristatelogic.com> References: <44255.1467112146@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/28/16, Ronald F. Guilmette <rfg@tristatelogic.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHAXwYA6Rsb0X=5PLXHwyfG%2Bms7sNk2LStJo_KTYi5jaaphqJw>