On 6/28/16, Ronald F. Guilmette <r...@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-font-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 security > 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’s?) 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 “Idea” 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 “Fizz[2.1] *BSD Day”?[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’s, “Free as in beer”, etc... 2.2 Though unless the final note in the “Description” on the Wiki is accurate it seems the Fuzzing/"Fizzing" will have to be limited to the ports collection: “A 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.“ _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
