Crash a RISC machine from user-mode code:

James C Burley burley at world.std.com
Fri Aug 17 19:38:44 AEST 1990


In article <BURLEY.90Aug11024356 at world.std.com> burley at world.std.com (James C Burley) writes:

>5) However, if the random program manages to do things clearly out of the
>   accepted realm of "user program", and assuming it (and thus the user
>   or "wetware") cannot invoke "superuser" or some other "give me direct access
>   to the kernel" function, such as "poke the kernel's memory" or "write
>   to raw disk sector", then one may conclude that either the operating system
>   in control has a security hole, or perhaps the hardware itself has a
>   security hole.  THIS IS PART OF HOW RICHARD MORRIS'S PROGRAM TRASHED THE
>   NET: he knew passing a certain invalid value to a kernel-mode function from
>   user-mode would escape normal defensive programming (since there wasn't any
>   in that particular case), and allow his program to insinuate part of
>   itself (data/instructions) into the kernel's memory and then be executed
>   as kernel, not user, code.

The statements concerning Mr. Morris (whose first name is not Richard) are
incorrect.  After two people pointed it out to me, I retrieved my copy of
"The Internet Worm Program: An Analysis", Purdue Tech Report CSD-TR-823, by
Eugene H. Spafford and reread it.  (At least I can congratulate myself on
being able to find something in my files that I hadn't read for over a year
and a half!)

While the basic mechanism used was to effectively pass an "invalid value"
(in fact an overflowing string) to a "function" (in fact the fingerd daemon)
to acquire more "privileges" (in fact a TCP connection to a shell on a remote
system) than normally available for "part of [his program]" to use, nothing
Mr. Morris did involved gaining access to kernel mode on any of his machines.

I don't remember whether I misunderstood this back when I read the report;
probably I just forgot.  In my youth I cracked a few systems by gaining access
to special privileges and/or kernel mode, and more recently found and sealed
up a few cracks in operating systems and "privileged" utilities (I got paid
for the latter :-).  Also in designing privileged "daemons", I constantly
worried about the inability on the systems for which I was designing them to
validate the username for a network connection (the network part of the OS
didn't provide a "give me the user name for this connection" call).  So I
can't even plead ignorance of the concept of violating a user-mode daemon!

So forget the comments about Mr. Morris from my post; although I'm sure
kernel mode has been accessed by hackers using the mechanism I described, I
can't think of any I've ever known of personally to give as examples.  (Ok,
maybe some things I used to do on old TOPS-10 systems were similar, but that
was long ago on a mainframe far, far away :-)

Thanks to those of you who've already sent me appreciative email about my
long-winded posting, in any case.  And I sincerely apologize for failing to
reread Mr. Spafford's analysis of the Internet Worm before extemporaneously
throwing in comments about the Worm being an example of kernel-mode violation.
Now if I can just remember to trust my filing system more than my long-term
memory in the future...!

James Craig Burley, Software Craftsperson    burley at world.std.com



More information about the Comp.lang.c mailing list