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

[Ronald F. Guilmette]

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-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[David I Noel]

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

[maxnix]

Il giorno Tue, 28 Jun 2016 04:09:06 -0700
"Ronald F. Guilmette" <r...@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-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to
> "freebsd-securi...@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

[Ronald F. Guilmette]

In message <20160630203013.1038690d@max-BSD>,

maxnix <maxni...@gmail.com> wrote:

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

This is excellent! Thanks for sharing!

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

I think that if schools could at least just teach kids why they have
good reason to be properly aware of, and concerned about the perils
of their devices, *and* if they could also teach kids about the long
tails they are all leaving for themselves on social media... which
may perhaps never disappear in their lifetimes... then that alone
would be progress.


Regards,
rfg


P.S. I've been firmly convinced for at least a couple of decades now
that crap software (and crap firmware) was all fostered, encouraged,
and made possible by U.S. legislation and/or court interpretations
thereof which have made it virtually impossible to even get past first
base if one attempts to file a product liability claim based on a
software (or firmware) defect.

In essentially every other industry, crappy dangerous products, sold
to the public en mass (and generally with no warnings) can be taken
to task in a U.S. court of law. But not software. In this way,
software is in rare and elite good company with other marvelous
products which are also and likewise immune from product liability
actions, in particular tobacco and firearms.

And to anybody who wishes to retort "Yea, but software doesn't kill
people!" I respectfully suggest that you first google for "Therac-25".

[Chris BeHanna]

On Jun 30, 2016, at 15:56, Ronald F. Guilmette <r...@tristatelogic.com> wrote:
> In essentially every other industry, crappy dangerous products, sold
> to the public en mass (and generally with no warnings) can be taken
> to task in a U.S. court of law. But not software. In this way,
> software is in rare and elite good company with other marvelous
> products which are also and likewise immune from product liability
> actions, in particular tobacco and firearms.

Groan. I just love FUD, don't you?

Firearms are most definitely NOT "immune from product liability actions." If one fails to function in the manner it was designed, and someone is injured as a result, the manufacturer most certainly is NOT immune from liability. If it fires out of battery and the user gets a faceful of burning powder and brass, yup, liability. If the firearm catastrophically fails and it's not user error, the manufacturer is most certainly NOT immune from liability. If the weapon fires while the safety is engaged, or when dropped muzzle-first, the manufacturer is most certainly NOT immune from liability.

Now, if the nonsense you're peddling is that you're upset that manufacturers aren't liable for the blatant, deliberate, criminal misuse of their products, that's quite a different thing. We don't, for example, hold an auto manufacturer responsible if a crazed soccer mom or a loser twenty-something mows down a sidewalk full of people, nor should we, nor do we hold the FreeBSD Foundation liable if someone uses FreeBSD to craft a worm or virus, or to commit some other cybercrime.

--
Chris BeHanna
ch...@behanna.org

[Lyndon Nerenberg]

> On Jun 30, 2016, at 1:56 PM, Ronald F. Guilmette <r...@tristatelogic.com> wrote:
>
> And to anybody who wishes to retort "Yea, but software doesn't kill
> people!" I respectfully suggest that you first google for "Therac-25".

Followed by "always mount a scratch monkey."