Stuff I don't understand, and maybe never will.

[David I Noel]

On 6/28/16, Ronald F. Guilmette <rfg at 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.“