freebsd security - Jun 2016 - Stuff I don't understand, and maybe never will.

Please forgive the following outburst/rant.  Sometimes, I just see something
that makes me want to scream "I can't take it anymore!"

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.

Every single thing about this article drives me crazy, almost like
fingernails scratching slowly over a blackboard, and, you know, I'm
sorry about this, but for some strange reason I felt compelled to
share this feeling with others.

In the first place, knowing virtually nothing about Windoze kernels,
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.)

Second, I'm having trouble understanding why these Google guys are
patting themselves on the back for finding bugs in *Windows 7* at this
late date.  I mean jeeezzzz.  Doesn't that OS have one foot in the
grave already?  It's swell that they were able to find bugs in this
now old and crusty OS, but I'm not persuaded that it is a cause for
breaking out the champaign, and I do have to wonder if maybe Google's
engineering talent and resources couldn't have been better spent finding
bugs in Windows 8, Windows 8.1, Windows 10, or, ya know, maybe even
Android (which, as I understand it, has more than its fair share of
security and other bugs).

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.  Well, I mean, like DUH!  This totally begs the question:
Particularly (but not exclusively) in a post-Snowden world, 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?

It may still be several years yet, but I do believe that over the long run,
the Snowden effect will slowly, but surely (and finally) rid the world
of closed source forever... and good riddance to it!


Again, my apologies for the rant.  I just had to vent spleen on all this
or else I'd have burst.  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/

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.?

Il giorno Tue, 28 Jun 2016 04:09:06 -0700
"Ronald F. Guilmette" <rfg at tristatelogic.com> ha scritto:
> Please forgive the following outburst/rant.  Sometimes, I just see
> something that makes me want to scream "I can't take it
anymore!"
> 
> 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.
> 
> Every single thing about this article drives me crazy, almost like
> fingernails scratching slowly over a blackboard, and, you know, I'm
> sorry about this, but for some strange reason I felt compelled to
> share this feeling with others.
> 
> In the first place, knowing virtually nothing about Windoze kernels,
> 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.)
> 
> Second, I'm having trouble understanding why these Google guys are
> patting themselves on the back for finding bugs in *Windows 7* at this
> late date.  I mean jeeezzzz.  Doesn't that OS have one foot in the
> grave already?  It's swell that they were able to find bugs in this
> now old and crusty OS, but I'm not persuaded that it is a cause for
> breaking out the champaign, and I do have to wonder if maybe Google's
> engineering talent and resources couldn't have been better spent
> finding bugs in Windows 8, Windows 8.1, Windows 10, or, ya know,
> maybe even Android (which, as I understand it, has more than its fair
> share of security and other bugs).
> 
> 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.  Well, I mean, like DUH!  This totally begs the
> question: Particularly (but not exclusively) in a post-Snowden world,
> 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?
> 
> It may still be several years yet, but I do believe that over the
> long run, the Snowden effect will slowly, but surely (and finally)
> rid the world of closed source forever... and good riddance to it!
> 
> 
> Again, my apologies for the rant.  I just had to vent spleen on all
> this or else I'd have burst.  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/
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to
> "freebsd-security-unsubscribe at freebsd.org"
I share your opinion and feeling, but I don't think that the Snowden
effect will be enough to get rid of the closed source world.

The closed source world exists because there are people who don't care
about how their devices work: all they want is to have their tech
gadgets let them do all they desire. Stop. And usually these people
judge those devices by looking at their aspect, not functionality
(and if they don't mind about functionalities, guess if they care about
security).

But, on the other hand, who encourage them at looking under the hood?
Companies? Absolutely not. Why they should, after all? The more users
know, the less they can base thier business on appereance and the "fancy
looking" factor. So PCs, smartphones, tablets, etc. are usually
presented as hard-to-understand blackboxes that just work.

(Note: not necessary all companies act so, but IMHO the ones under the
reflectors does...)

And, talking about Windows, this document came in mind:
https://www.over-yonder.net/~fullermd/rants/winstupid/1

I hope that, in a world where telecommunication devices are more and
more pervasive, in schools will teach to kids not only how to work with
computers, but even how computers work.

Sorry for the rant, but all of this is very sad.

Regards.

Maxnix

On 2016-06-30 11:30, maxnix wrote:
> I hope that, in a world where telecommunication devices are more and
> more pervasive, in schools will teach to kids not only how to work with
> computers, but even how computers work.
Unfortunately, this is also not too common. I have a son in High School in
California, most schools think tech training means buying a bunch of ipads, or
teaching the kids to use M$ word.

As a note on organizing, I would encourage anyone who is able, to attend the
"Hackers On Planet Earth" conference in Manhattan in late July:

https://xi.hope.net/schedule.html

There is a presentation on this subject by Richard Stallman:

"Freedom and Privacy in Our Lives, Our Governments, and Our Schools"

This is a great conference in general. If you are able, come mingle and
communicate with similarly informed and motivated people.

johnea