Re: Chasing bugs / vulnerabilties

[Chiaki Ishikawa <Chiaki.Ishikawa () PERSONAL-MEDIA CO JP>]

X-PMC-CI-e-mail-id: 13322

Hi,


I found "fuzz" pretty useful tool to
strengthen the HMI (human machine interface).

Many years ago, after learning how to run fuzz on DEC Ultrix and found
that some of the problems reported in a CACM article, which prompted
my inquiry in the first place, still existed, I tested input parse
module of a large engineering tool using fuzz-like tool (hacked
emacs-lisp program to randomly modify the "correct" input to simulate
human errors.).
It helped me in identifying many weakness and so that the module
was fixed before wider shipment.

I believe using fuzz for input-verification purposes is
a very handy tool as part of our arsenal.
It adds to our skill to detect problems which human reading
may skip unnoticed.

For example, the original CACM article mentioned a bug in input
routine of Emacs and I could not believe it. I HAD READ the
keyboard input routine MANY TIMES in order to port Emacs to
a computer with an estoric architecture and I thought
there could NOT be possibly a bug there.
Then I learned that the buggy signal handling was not meant to
tackle the very fast fuzz input: human keystroke was slow enough
to hide the problem until the discovery.

I agree that fuzz is not a replacement for human-inspection of the
code.

Aside from security, robustness agains human input errors is a serious
concern and fuzz-like tool is very useful.
(Here again, I would think we might need to produce DOMAIN-SPECIFIC
super-fuzz so to speak. Instead of just replacing or
deleting/inserting a character or two, we might want to
substitute the whole word/phrase in a domain-specific manner in user
input.)

Just a thought.



--
     Ishikawa, Chiaki        ishikawa () personal-media co jp.NoSpam  or
 (family name, given name) Chiaki.Ishikawa () personal-media co jp.NoSpam
    Personal Media Corp.      ** Remove .NoSpam at the end before use **
  Shinagawa, Tokyo, Japan 142-0051