akhiani@ricks.enet.dec.com (Homayoon Akhiani) (08/09/90)
This is what I got through EMAIL:(Very intresting)
From:
DECWRL::"zaphod.mps.ohio-state.edu!usc!samsung!mitech!gjc@tut.cis.ohio-s
state.edu" "MAIL-11 Daemon" 31-JUL-1990 00:03:39.91
To: info-vax@kl.sri.com
CC:
Subj: how to crash a RISC machine from user-mode code: !!!
I am posting this to info-vax because lots of people on this list
would have SUN-4's or other RISC machines to try it on, and we VAX
users could use a good chuckle from time to time.
The motivation here: As I was reading about the SPARC architecture I
thought, gee, it must be quite a pain to do the analysis of all the
billions of different machine-state combinations one could get executing
a sequence of a few random instructions. And I *do* mean random. Not
well behaved stuff like compilers are supposed to generate, but really
random data executed as code. Buggy programs are jumping off into data
space all the time.
Extract this as crashme.c, cc -o crashme crashme.c and then try this:
%crashme 1000 10 200
On the few SUN-4's I've tried: this allows a user-mode program to
crash the system. Is it a hardware bug (hard to fix) or just a
software bug? I don't know. Report back your findings to me
and I will summarize. (Try it with different argument combinations).
/* crashme: Create a string of random bytes and then jump to it.
crashme <nbytes> <srand> <ntrys>
THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL
HE BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR
ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
A signal handler is set up so that in most cases the machine exception
generated by the illegal instructions, bad operands, etc in the procedure
made up of random data are caught; and another round of randomness may
be tried. Eventually the a random instruction may corrupt the program or
the machine state in such a way that the program must halt.
Note: This program has never caused any problem on a VAX, or other CISC
architecture with a protected-mode operating system, but on certain
RISC machines it has been observed to allow a user-mode program to
crash the machine.
*/
#include <stdio.h>
#include <signal.h>
#include <setjmp.h>
long nbytes,nseed,ntrys;
unsigned char *the_data;
jmp_buf again_buff;
void (*badboy)();
void again_handler(sig, code, scp, addr)
int sig, code;
struct sigcontext *scp;
char *addr;
{char *ss;
switch(sig)
{case SIGILL: ss = " illegal instruction"; break;
case SIGTRAP: ss = " trace trap"; break;
case SIGFPE: ss = " arithmetic exception"; break;
case SIGBUS: ss = " bus error"; break;
case SIGSEGV: ss = " segmentation violation"; break;
default: ss = "";}
fprintf(stderr,"Got signal %d%s\n",sig,ss);
longjmp(again_buff,3);}
set_up_signals()
{signal(SIGILL,again_handler);
signal(SIGTRAP,again_handler);
signal(SIGFPE,again_handler);
signal(SIGBUS,again_handler);
signal(SIGSEGV,again_handler);}
compute_badboy()
{long j,n;
n = (nbytes < 0) ? - nbytes : nbytes;
for(j=0;j<n;++j) the_data[j] = (rand() >> 7) & 0xFF;
if (nbytes < 0)
{fprintf(stdout,"Dump of %ld bytes of data\n",n);
for(j=0;j<n;++j)
{fprintf(stdout,"%3d",the_data[j]);
if ((j % 20) == 19) putc('\n',stdout); else putc(' ',stdout);}
putc('\n',stdout);}}
try_one_crash()
{compute_badboy();
if (nbytes >= 0)
(*badboy)();}
main(argc,argv)
int argc; char **argv;
{long i;
if (argc != 4) {fprintf(stderr,"crashme <nbytes> <srand> <ntrys>\n");
exit(1);}
nbytes = atol(argv[1]);
nseed = atol(argv[2]);
ntrys = atol(argv[3]);
fprintf(stdout,"crashem %ld %ld %ld\n",nbytes,nseed,ntrys);
fflush(stdout);
the_data = (unsigned char *) malloc((nbytes < 0) ? -nbytes : nbytes);
badboy = (void (*)()) the_data;
fprintf(stdout,"Badboy at %d. 0x%X\n",badboy,badboy);
srand(nseed);
for(i=0;i<ntrys;++i)
{fprintf(stderr,"%ld\n",i);
if(setjmp(again_buff) == 3)
fprintf(stderr,"Barfed\n");
else
{set_up_signals();
try_one_crash();
fprintf(stderr,"didn't barf!\n");}}}
-----end of crashme.c----------
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
From: DECWRL::"usc!samsung!mitech!gjc@ucsd.edu" "MAIL-11 Daemon" 2-AUG-1990
03:25:34.83
To: info-vax@kl.sri.com
CC:
Subj: SUMMARY: How to Crash a RISC, or Revenge of the VAX?
OK. Here is a quick summary of the HOW TO CRASH A RISC machine from
a USER-MODE program test. Reports have arrived that all of these machines
can be crashed using CRASHME.C:
IBM RT, MIPS, DECSTATION 5000, SPARC.
On the two CISC architectures tried, VAX/VMS and SUN-3, the program
either completed or exited with a core or register dump, as expected.
Some background/motivation. My experience with microcode programming
taught me that some sequences of MICROINSTRUCTIONS could wedge or jam
the hardware in such a way that recovery was impossible without
a reboot of some kind. The RISC architectures have some of the same
properties of MICROCODE in that certain instruction sequences have
UNDEFINED behavior. Now one of the great costs in a CISC machine is
usually the trouble the designers go through to make sure that
every instruction returns the MACHINE to a KNOWN STATE. That way
the behavior of every instruction can be well defined, tested, and
documented, individually verified and tested, and by simple induction
be valid for arbitrary SEQUENCES of instructions. (In general).
Engineers of RISC machines don't bother to do this, which is one of
the reasons they are CHEAPER (the hardware, not the engineers).
The problem of proving that an arbitary sequence of instructions "N"
long will not crash the machine is much more costly if N > 1.
(To say the least, if you know anything about mathematical logic).
If there are M instructions (and M is probably around 1 BILLION)
then there may be about M^N cases to check. And what is N?
For a classic CISC machine a price is paid to make N = 1, or
at least small. But for a RISC machine, might N be 10 or more?
Anyway, no need to make too big a deal about this. Probably all the
vendors can fix things in software alone, and certainly CISC chips
with bugs in them have been shipped in the past too.
Just a reminder though. There is no free lunch. There really is
a trade-off between ROBUSTNESS-PRICE/PERFORMANCE-TIME_TO_MARKET.
-gjc
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======peter@ficc.ferranti.com (Peter da Silva) (08/09/90)
In article <1826@mountn.dec.com> akhiani@ricks.enet.dec.com (Homayoon Akhiani) writes: > OK. Here is a quick summary of the HOW TO CRASH A RISC machine from > a USER-MODE program test. Reports have arrived that all of these machines > can be crashed using CRASHME.C: > IBM RT, MIPS, DECSTATION 5000, SPARC. > On the two CISC architectures tried, VAX/VMS and SUN-3, the program > either completed or exited with a core or register dump, as expected. On the 80386 in either 80386 protected mode or 80286 protected mode the program crashed the system. On the machine running in 80286 mode it was caught by the kernel debugger, but I was not able to restart and get a ^C in to stop the program before it crashed again. Ah, Intel. Tests on a 68000 (yes, a real 68000) running System V.2 will be done shortly. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (08/10/90)
In article <C:25L+@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1826@mountn.dec.com> akhiani@ricks.enet.dec.com (Homayoon Akhiani) writes: >> OK. Here is a quick summary of the HOW TO CRASH A RISC machine from >> a USER-MODE program test. Reports have arrived that all of these machines >> can be crashed using CRASHME.C: >> IBM RT, MIPS, DECSTATION 5000, SPARC. > >> On the two CISC architectures tried, VAX/VMS and SUN-3, the program >> either completed or exited with a core or register dump, as expected. > >On the 80386 in either 80386 protected mode or 80286 protected mode the >program crashed the system. On the machine running in 80286 mode it was >caught by the kernel debugger, but I was not able to restart and get a ^C >in to stop the program before it crashed again. > >Ah, Intel. Ah Unix (presumably)!! Lets try **MSDOS** (386 mode): >crashme 1000 10 200 BADBOY at 27472. 0x6b50 0 Abnormal Program Termination: Memory protection fault. CS:EIP = 000c:00006B53 i.e. no crash. MicroWay NDPC compiler. To date, I have not ever had a crash with either this compiler or their Fortran except after invoking specific OS calls that specifically defeat protection (i.e. allowing me to poke values into the kernal.) Doug McDonald
pjg@acsu.buffalo.edu (Paul Graham) (08/10/90)
peter@ficc.ferranti.com (Peter da Silva) writes: [a program which executes random bytes causes problems on an 80386] | |Ah, Intel. Tests on a 68000 (yes, a real 68000) running System V.2 will |be done shortly. since this particular program exploits (at least on a sparc) an o.s. bug it hardly seems fair to blame intel or perhaps praise motorola based on their hardware.
domo@tsa.co.uk (Dominic Dunlop) (08/10/90)
In article <1826@mountn.dec.com> akhiani@ricks.enet.dec.com (Homayoon Akhiani) writes: > This is what I got through EMAIL:(Very intresting) > > From: DECWRL::"zaphod.mps.ohio-state.edu!usc!samsung!mitech!gjc@tut.cis.ohio-state.edu" "MAIL-11 Daemon" 31-JUL-1990 00:03:39.91 > To: info-vax@kl.sri.com > Subj: how to crash a RISC machine from user-mode code: !!! > > I am posting [crashme.c] to info-vax because lots of people on this list > would have SUN-4's or other RISC machines to try it on, and we VAX > users could use a good chuckle from time to time. > ... > On the few SUN-4's I've tried: this allows a user-mode program to > crash the system.... [Other respondents have reported the shooting down of other RISCs, and (somewhat) less catastrophic results on a few CISCs.] Well. On my ``A/UX tsa 1.1 SVR2 mc68020'' (Mac IIx running A/UX 1.1) crashme does not actually crash the system. (I used the standard C compiler, which has an AT&T/Unisoft/Apple pedigree (if that's the right word).) However... $ crashme 4096 0 64 crashem 4096 0 64 Badboy at 4199624. 0x4014C8 0 Got signal 4 illegal instruction Barfed 1 Got signal 4 illegal instruction Barfed 2 Got signal 11 segmentation violation Barfed 3 Got signal 11 segmentation violation Barfed 4 Got signal 11 segmentation violation Barfed 5 Got signal 4 illegal instruction Barfed 6 Got signal 4 illegal instruction Barfed 7 Got signal 11 segmentation violation Barfed 8 Got signal 4 illegal instruction Barfed ... A short time after this, the program gets stuck in a silent loop. Some time later, my system sprouts a rash of "Warning: swap space is low"s, the disk threatens to shake itself to bits, other processes start aborting, and response becomes snail-like. But crashme eventually responds if sent a quit signal, and, after more feverish disk activity, the system recovers. I don't know precisely what's going on, but presume it's something a purpose-built malevolent user-mode program could do on any system (whether CISC or RISC) without user time and memory space quotas... -- Dominic Dunlop
merriman@ccavax.camb.com (08/11/90)
In article <49041@seismo.CSS.GOV>, stead@beno.CSS.GOV (Richard Stead) writes: [stuff deleted] > Who could possibly care > that a random instruction sequence crashes a risc box? Some villain wanting to mount a denial-of-service attack. And if certain strange instruction sequences can bypass the operating system and hardware protections which are supposed to prevent this sort of thing, perhaps there are other sequences which will do even more insidious things, like allow a guest account to become superuser. Remember the Internet Worm. [more stuff deleted] > > Richard Stead > stead@seismo.css.gov George Merriman (I hope my bank does not use unix to keep track of MY money!)
stead@beno.CSS.GOV (Richard Stead) (08/11/90)
In article <1826@mountn.dec.com>, akhiani@ricks.enet.dec.com (Homayoon Akhiani) writes: > This is what I got through EMAIL:(Very intresting) > > From: > DECWRL::"zaphod.mps.ohio-state.edu!usc!samsung!mitech!gjc@tut.cis.ohio-s > state.edu" "MAIL-11 Daemon" 31-JUL-1990 00:03:39.91 > > I am posting this to info-vax because lots of people on this list > would have SUN-4's or other RISC machines to try it on, and we VAX > users could use a good chuckle from time to time. ... > From: DECWRL::"usc!samsung!mitech!gjc@ucsd.edu" "MAIL-11 Daemon" 2-AUG-1990 > 03:25:34.83 I think the risc users are going to get a chuckle out of this. > [long gooey, passionate VAX-CISC romance deleted, along with code with > simple jump to random data] > Just a reminder though. There is no free lunch. There really is > a trade-off between ROBUSTNESS-PRICE/PERFORMANCE-TIME_TO_MARKET. > > -gjc Pretty Silly. Do VAX-CISC programmers spend their days branching to random data? I thought programmers were paid to create software that did real things. I would hope that I never write a code that branches to random data. Or if I ever do, I would fix it pretty damn quick. (My definition of a code that branches to random data is "broken"). Who could possibly care that a random instruction sequence crashes a risc box? That's WHY we have compilers - so we don't generate such things. In any case, VAX-CISC and 68020's have been around for a long time - all the random instruction sequences that could crash those have probably been identified and fixed in software. The oldest popular risc architecture is sparc, and that's only been around a short time. I don't need this kind of ROBUSTNESS to protect me from bad programming - I do that well enough myself, thank you. Let the bad programmers pay through the butt for vaxen and deal with slow, archaic architecture (and, most likely, VMS - a regular Gulag of operating systems compared to Unix). Richard Stead stead@seismo.css.gov
burley@world.std.com (James C Burley) (08/11/90)
NOTE: -LONG- POSTING, look at the summary at the bottom first if you don't
want to read a single long posting on crashing systems!! I'd boil it down,
but I've already spent too much access $$ just composing the thing, so I
apologize to everyone for the length and to those who knew me as a software
tech writer long ago (I've always been an overly verbose engineer :-)!
--------
Hmm, this discussion was at first very interesting to me but seems to have
gotten off the track I was hoping for...let me explain:
1) As I recall, the original posting talked about somebody wondering if the
new RISC machines were bullet-proof in user mode (essentially, based on
their wording -- something about "register paths" and such), and
proposed running a program that jumped to random data. The result of
such a program is the execution of random defined AND UNDEFINED
instructions.
2) This kind of program should ONLY be run under so-called "user-mode"
protection, i.e. under operating systems like UNIX, OS/2 (I think), VMS,
A/UX, and so on, and only on CPUs where those systems offer (and have
enabled) memory protection, fault catching, preemptive scheduling, and
such like. Thus it is NOT USEFUL to run the program on systems like
IBM PCs running DOS, XENIX (I think), or Macintoshes running Apple's non-
UNIX OS. (Maybe A/UX fits in this category too?) Why? Because no matter
what it does (short of reducing oil prices), any hand-written program could
have done the same -- including (caution!) erasing your hard disk!
Doubt I've lost anyone so far....
3) There's no doubt that jumping to random junk produces no useful productive
work in the normal sense; nobody is suggesting this is a good way to use
any kind of computer. BUT, by running random junk, one may increase the
likelihood of discovering a "hole" in the system (hardware or kernel,
usually) compared to running regular code generated by a compiler or even
regular assembly code written by users. It may even have a better chance
than examining the instruction set architecture and trying to purposely
write code that breaks the machine.
4) If such a program does anything that any normal user mode program may
conceivably do, then it should not be considered worth noting. This is
especially the case (even for weird things like deleting files) if the
program is run after some other useful program has been run and still has
parts of it sitting around in memory; the random program could easily jump
to it. Other things included in this "not interesting behavior", IMHO:
a) Putting the process into an infinite loop (but the system as a whole
still works to the same extent it would if one actually ran a
hand-coded infinite loop).
b) Spewing junk to the terminal screen, or hanging for input from the
terminal.
c) Signaling conditions caught by the OS.
d) Logging out, playing with files, network connections, or other things
like that.
e) Thrashing the swapper or pager (again, assuming any user program can
do it).
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.
I highlight this issue because it IS important: if your operating system
provides a "hole" through which any user (who can write and execute raw
machine code if even only via BASIC POKE instructions, but certainly via
use of assembler/loader) can do something not normally allowed in user
mode, then your operating system has a security hole. (I'm not talking
about the non-user-mode systems like MAC OS, PC/MS-DOS; I mean Unix, VMS,
PRIMOS, and so on.) Very likely, the hole can be found and fixed (though
the fix is painful if the "bug" is really a convenient "entry point" for
utilities needing special features; I've dealt with fixing this kind of
thing many times, usually involving timesharing systems' batch and printer
queue utilities).
But if the problem is that the underlying CPU allows a user mode program
to somehow circumvent documented user mode protection, then the problem
cannot be fixed without either switching to another kind of CPU (not easy;
porting is a problem) or preventing users from writing machine code (the
acceptable answer if you are providing only pure end-user services; for
example, the Prodigy on-line service allows no programming, so conceptually
could be implemented entirely on Apple IIs without having any architectural
exposure from a security perspective -- of course, performance is another
issue :-).
IF a system is "hackable" from the hardware perspective, the manufacturer
of that CPU better find and fix the problem fast, and perhaps even provide
inexpensive replacements to their customers. Otherwise their machine
becomes a "target" of evil hackers, and administrators will learn to avoid
any system based on their CPU especially when it comes to attaching such
a system to any network or putting any sensitive data on it.
SAMPLE WAYS TO TELL if your system has a "hole" like this, based on the
behavior of the "random-jumping" program:
a) Running the program crashes the entire system, but there is no known
way of so doing with a hand-written user program. (The culprit may
be the OS or the CPU, but check the OS carefully first.)
b) The program manages to rewrite part of the (protected) kernel
without crashing the system or calling any "may I write the kernel"
function. (Likely to be a CPU bug.)
c) The program somehow causes Iraq to unilaterally disarm.
Again, if the random program does something you cannot imagine ANY user
mode program doing (not just a correct or "well-written" one), then you
might well be looking at a security hole. ("Security" meaning either
a user can access things he/she shouldn't be able to, or is able to
trash or crash things he/she shouldn't have access to, like the CPU
itself.)
6) If you think the random-jumping program has exposed a hole in your system,
be it RISC or CISC, first determine (by reading the documentation or
asking an expert on your configuration of CPU and OS) whether your system
even ATTEMPTS to catch all possible user-mode violations. If your CPU
allows, for example, I/O instructions in user mode, then although it
wouldn't fit MY definition of "user mode", it would mean a user mode
program could do almost anything (including rewriting a swapping/paging
kernel or other kernel-mode programs right out from under themselves by
rewriting their disk images), so the random-jumping program would simply
be something to avoid running any more!
But, if you are running, say, under VAX/VMS, or on a 68030 running a
memory-protecting UNIX, or some such thing, and the random-jumper does
something out of bounds, then perhaps you've discovered one or more "holes"
in the system. If you can reproduce the problem reliably (if the program
always creates the same random data each time, for example), then you might
be able to step through it and find the actual instruction or instruction
sequence that causes the crash. (HINT: if it takes long in terms of
instruction steps, and your system provides a user-mode n-stepper, find
a large value of "n" to step the program that results in a crash, then use
a binary search technique to lower "n" until you have a value that falls
just short of the crash.)
Once you've narrowed down the problem to a few instructions, if they're
user mode and don't involve a kernel call, you might have a true-blue
CPU bug: document the problem and discuss with another expert on that CPU
(especially, try and reproduce on other chips in case yours just has a
local flaw, and on other slightly different models of the same CPU, e.g.
a 486 if the failure is on a 386, a 68030 if on a 68040, etc), then if
you still think it's a hardware problem, report it to the manufacturer.
However, it's likely that a supposed CPU problem is really an OS problem
if the offending instructions cause a valid trap to the OS that the OS
mishandles or fails to handle, so make sure the offending instructions
aren't trapping to kernel mode at all.
If you find the problem's in the OS, for example a call to an OS function
with absurd arguments that don't get "noticed" until it's too late, then
(again, after checking with experts and other copies and different versions
of the OS) let the OS writer know. And, depending on your own sense of
ethics, perhaps let everyone else (via a newsgroup) know as well, so they
can plan their own defenses if they are using that OS.
(I wouldn't personally recommed advertising a CPU hole; if you're wrong
about somebody's OS, it's fairly easy for them to prove assuming you've
narrowed the problem down adequately, and in any case people can actually
defend their systems fairly rapidly via patches, but if you're wrong about
someone's CPU, they can't show everyone the schematics to prove it and
you may have tarnished the manufacturer's image permanently, and meanwhile
there isn't much most people can do about it quickly. Wait for the
manufacturer to verify/refute the problem and take their own steps, IMHO.)
7) Remember that even if you're the ONLY USER of a system with a "hole", you've
still got a security problem unless you're also the ONLY PROGRAMMER of
every new (or recent) program running in user mode on your system. If
someone else knows of a hole in a particular OS/CPU combination, they might
use that knowledge to write a trojan horse program that pretends to be one
thing but, when it detects a system for which it has a "kernel access"
code to exploit a security hole, does bad things like attaching viruses
to other programs or erasing disks. (IMHO, the best protection against
this kind of situation is to only use "free software" that comes with source
code and never use the binaries, but always do the rebuilds yourself, and
only after inspecting the source code via a quick perusal: it is much
harder to hide a code missile in source code than in binary code. Be
suspicious of any data tables without adequate explanation, especially if
they can get "jumped" to. Unfortunately, scanning assembler code can
be much harder than scanning HLL code like C, Pascal, or (best of all due
to lack of pointers and such) Fortran and Cobol.)
I know this has been a long posting, but I've tried to explain what I think
are the important issues about a random-jumping program. Again, please don't
get excited if such a program goes into an infinite loop, or signals
conditions that your OS catches -- any user program can do those things.
DON'T run such a program on ANY system that doesn't offer full user mode
protections like memory, I/O, scheduling, and others; you might just end up
trashing your hard disk or some such thing. Finally, if you DO run the
program on an "interesting" (i.e. protecting) system and it produces
"interesting" (i.e. not-normally-allowed-in-user-mode) results, PLEASE look
into it further and, if possible, involve an expert -- you may have taken
a step towards preventing the next major virus or trojan horse infiltration!
(I mean, if YOU can find the problem, so can someone else who wants publicity
for being a mediocre, obnoxious hacker!)
James Craig Burley, Software Craftsperson burley@world.std.combjornmu@idt.unit.no (Bj|rn Munch) (08/11/90)
In article <30273.26c33972@ccavax.camb.com>, merriman@ccavax.camb.com writes: |> In article <49041@seismo.CSS.GOV>, |> stead@beno.CSS.GOV (Richard Stead) writes: |> [stuff deleted] |> > Who could possibly care |> > that a random instruction sequence crashes a risc box? |> |> Some villain wanting to mount a denial-of-service attack. Or just about anyone running a buggy program. It's bad enough that the program crashes, you shouldn't have to risk (RISC :-)) bringing the whole machine down or do unknown things to other processes. And there are always people running buggy programs, for example those who are debugging them.... A compiler won't guarantee against executing "random" instructions. You may forget to initialize a function pointer, or write past the end of an array on the stack, thereby disrupting a return address. Just my $.02 (15 |re) worth... _______________________________________________________________________ Bj|rn Munch | Div. of Comp. Science & Telematics, bjornmu@idt.unit.no | Norwegian Institute of Technology (NTH), PhD Student (well, soon...) | Trondheim, Norway
mod@masscomp.ccur.com (2915) (08/12/90)
In article <1990Aug10.101110.13698@tsa.co.uk> domo@tsa.co.uk (Dominic Dunlop) writes: > ... >... after this, the [crashme] program gets stuck in a silent loop. Some >time later, my system sprouts a rash of "Warning: swap space is low"s, >the disk threatens to shake itself to bits, other processes start >aborting, and response becomes snail-like. But crashme eventually >responds if sent a quit signal, and, after more feverish disk activity, >the system recovers. > >I don't know precisely what's going on, but presume it's something a >purpose-built malevolent user-mode program could do on any system >(whether CISC or RISC) without user time and memory space quotas... >-- >Dominic Dunlop I agree, because I'm just such a user ;-> Here's a program that causes behaviour exactly as you described: /* * this program seems to make most swapping/demand paging * systems do unpleasant things... (like run out of swap space.) */ #define MMU_PAGESIZE (4096) /* or whatever... */ main() { int array[ MMU_PAGESIZE / sizeof( int ) ]; return( main( array[ 1000 ] ) ); /* Force a reference. */ } The things done here could also be done a dozen other ways, but the general effect is to consume so much RAM so fast that you choke and die. Chances are that executing the random instructions in crashme caused some other part of the program to be modified and it then began to do something such as this program does. Fun Stuff!
kdq@demott.COM (Kevin D. Quitt) (08/12/90)
In article <49041@seismo.CSS.GOV> stead@beno.CSS.GOV (Richard Stead) writes: > >Do VAX-CISC programmers spend their days branching to random data? > Who could possibly care >that a random instruction sequence crashes a risc box? You certainly have a colloquial attitude. Do you, perhaps, work only on single-user machines? Just because you can use something without breaking doesn't mean it's seriously flawed. If there is *any* set of instructions that, from the user level, can crash a privelege-based system, then that system is *broken*. Again, just because it's broken doesn't mean it can't be useful for limited applications - like single user operation. But when you try to stress the system, it's going to fail. -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
bruce@seismo.gps.caltech.edu (Bruce Worden) (08/13/90)
In article <477@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: >In article <49041@seismo.CSS.GOV> stead@beno.CSS.GOV (Richard Stead) writes: >> >>Do VAX-CISC programmers spend their days branching to random data? >> Who could possibly care >>that a random instruction sequence crashes a risc box? > > You certainly have a colloquial attitude. Do you, perhaps, work >only on single-user machines? Just because you can use something without >breaking doesn't mean it's seriously flawed. If there is *any* set of >instructions that, from the user level, can crash a privelege-based >system, then that system is *broken*. > Again, just because it's broken doesn't mean it can't be useful for >limited applications - like single user operation. But when you try to >stress the system, it's going to fail. ...and this attitude is simply asinine. To insist that something will fail under certain circumstances when it so clearly does not is the height of arrogance. Our installation has been using Sun Sparc hardware for a couple of years and this "problem" has never surfaced. And this is not a CS department brimming with talented programmers. None of the people writing programs are trained programmers. The servers here are heavily stressed day in and day out running not only the usual collection of editors, compiliers, system and network processes, but also running numerical models and other user code. These systems provide excellent service for dozens of users; they have most certainly not "failed". Not bad for a "*broken*" system useful only for single user operation. Wake up. Risc may not be perfect (is anything?), but it is providing price/performance that has never before been available. Even IBM has jumped on the Risc/Unix bandwagon. Meanwhile, Sun streaks to yet another quarter of record sales and profits selling these seriously flawed systems. -------------------------------------------------------------------------- Bruce Worden bruce@seismo.gps.caltech.edu 252-21 Seismological Laboratory, Caltech, Pasadena, CA 91125 --------------------------------------------------------------------------
rang@cs.wisc.edu (Anton Rang) (08/13/90)
[ This isn't really a C issue; I'm redirecting it to comp.misc. ] In article <49041@seismo.CSS.GOV> stead@beno.CSS.GOV (Richard Stead) writes: >Do VAX-CISC programmers spend their days branching to random data? Nobody that I know of actually does this on *purpose*. However, it's not that hard to screw up a program so that it does this. For instance, passing the wrong argument (or an uninitialized pointer) to a routine expecting a function pointer can do it. Or trashing the stack by going past array bounds. Lots of possibilities. >Or if I ever do, I would fix it pretty damn quick. Same here. Nobody's saying that branching to random data is good. >Who could possibly care that a random instruction sequence crashes a risc box? Well...if I have my own workstation, and always have all my work in progress saved before I run a program (generally true for the most part, since I'm paranoid) I don't care that much, though it's still annoying . If I'm sharing the machine, I *don't* want it to crash twice a day because the guy down the hall is trying to find the stack-clobbering bug in his code. Educational environments are even more prone to this. If you have a Sun-4/490 shared between 200 users, you don't want somebody to be able to crash the machine at will ("denial of service" attack). There are students out there who will think this is a great joke.... I hope that the problems shown up by this test can all be fixed in software; I expect that they can, and that the vendors will do so. In general, nothing a user-mode process can do should be able to crash the machine...otherwise, what's the point of privileged instructions, kernel mode, etc.? Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+
kdq@demott.COM (Kevin D. Quitt) (08/14/90)
In article <1990Aug13.053147.11714@laguna.ccsf.caltech.edu> bruce@seismo.gps.caltech.edu (Bruce Worden) writes: >In article <477@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: ... >> If there is *any* set of >>instructions that, from the user level, can crash a privelege-based >>system, then that system is *broken*. >> Again, just because it's broken doesn't mean it can't be useful for >>limited applications - like single user operation. But when you try to >>stress the system, it's going to fail. > >... These systems provide excellent >service for dozens of users; they have most certainly not "failed". Not >bad for a "*broken*" system useful only for single user operation. > Please read what I said. I did *not* claim they were only useful for single user mode, just that it was one condition where it could be used. Another situation is where you have users of (well debugged) applications, which appears to be your situation. >Wake up. Risc may not be perfect (is anything?), but it is providing >price/performance that has never before been available. Where did this come from? I'm not talking about RISC - I'm talking about ANY type of computer system, RISC, CISC, DTL doesn't matter. If it is a multi-level privelege system, and the hardware can fail to provide the necessary protection to the operating system, then the hardware is broken. Period. -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
jgmicon@sandia.UUCP (Jeff G. Micono ) (08/14/90)
In article <49041@seismo.CSS.GOV>, stead@beno.CSS.GOV (Richard Stead) writes: > Pretty Silly. > > Do VAX-CISC programmers spend their days branching to random data? I no, but programmers DO make mistakes, and some people are malicious... > thought programmers were paid to create software that did real things. > I would hope that I never write a code that branches to random data. Or > if I ever do, I would fix it pretty damn quick. (My definition of a > code that branches to random data is "broken"). my definition of broken is a system in which a user mode program (however generated) can crash the system. what if your "broken" program corrupted the OS, how could you fix it without rebooting? > Who could possibly care > that a random instruction sequence crashes a risc box? That's WHY we > have compilers - so we don't generate such things. and compilers NEVER generate wrong code... > In any case, VAX-CISC > and 68020's have been around for a long time - all the random instruction ^^^^^^^^^^^^^^^^^^^^^^^^^^ really? i would estimate this to be a very large number. very large. .> sequences that could crash those have probably been identified and fixed > in software. The oldest popular risc architecture is sparc, and that's only fixed in software? do you know anything about computers? > been around a short time. I don't need this kind of ROBUSTNESS to protect i sure need the architecture to provide a foundation so the OS can give me "robustness" to protect me from idiots like you! > me from bad programming - I do that well enough myself, thank you. > Let the bad programmers pay through the butt for vaxen and deal with vaxen == vaxeln? > slow, archaic architecture (and, most likely, VMS - a regular Gulag > of operating systems compared to Unix). obviously, you've never had the opportunity to work with VMS on a project which was large and written for regular people to use,and not experts (a la Unix applications) Unix -- just what is the print command these days? I can't wait for Mach to come out and lay this VMS/Unix war to rest once and for all... > > Richard Stead > stead@seismo.css.gov Jeff Micono
vinoski@apollo.HP.COM (Stephen Vinoski) (08/15/90)
In article <1826@mountn.dec.com> akhiani@ricks.enet.dec.com (Homayoon Akhiani) writes: > OK. Here is a quick summary of the HOW TO CRASH A RISC machine from > a USER-MODE program test. Reports have arrived that all of these machines > can be crashed using CRASHME.C: > IBM RT, MIPS, DECSTATION 5000, SPARC. > On the two CISC architectures tried, VAX/VMS and SUN-3, the program > either completed or exited with a core or register dump, as expected. The HP/Apollo Series 10000 machines do not crash; rather, the crashme process dies with an "unimplemented instruction" fault. -steve | Steve Vinoski (508)256-6600 x5904 | Internet: vinoski@apollo.com | | Testability and Diagnostics | UUCP: ...mit-eddie!apollo!vinoski| | HP Apollo Division, Chelmsford, MA 01824 | ...uw-beaver!apollo!vinoski| | Kuwait summer blockbuster: "Iraq-nophobia" -David Letterman |
root@pyrshadow (0000-Admin(0000)) (08/15/90)
In article <1826@mountn.dec.com> akhiani@ricks.enet.dec.com (Homayoon Akhiani) forwards the following from (gjc): > Reports have arrived that all of these machines >can be crashed using CRASHME.C: >IBM RT, MIPS, DECSTATION 5000, SPARC. > >On the two CISC architectures tried, VAX/VMS and SUN-3, the program >either completed or exited with a core or register dump, as expected. [Peter da Silva has since crashed a 386, and Dominic Dunlop's A/UX 68020 got somewhat confused. Peter: what happened to the V.2 68000 ?] I ran this program continuously with different seed values on a (new) MIS-2 and an (old) 9805. They've been running overnight, and they're still running, merrily catching bus errors. Both machines use Pyramid's proprietary RISC CPU, both run OSx. >Some background/motivation. My experience with microcode programming >taught me that some sequences of MICROINSTRUCTIONS could wedge or jam >the hardware in such a way that recovery was impossible without >a reboot of some kind. The RISC architectures have some of the same >properties of MICROCODE in that certain instruction sequences have >UNDEFINED behavior. Now one of the great costs in a CISC machine is >usually the trouble the designers go through to make sure that >every instruction returns the MACHINE to a KNOWN STATE. That way >the behavior of every instruction can be well defined, tested, and >documented, individually verified and tested, and by simple induction >be valid for arbitrary SEQUENCES of instructions. (In general). Looks like some SWEEPING generalisations CREPT in there. Damn CAPS lock KEY keeps getting STUCK ... there, that's better. >Engineers of RISC machines don't bother to do this, which is one of >the reasons they are CHEAPER (the hardware, not the engineers). A(nother) sweeping generalisation if ever I saw one. Of course, that doesn't mean it's untrue. I always thought they (the processors) were cheaper because they were simpler. If, in fact, they were cheaper at all. ECL SPARC, anyone ? >The problem of proving that an arbitary sequence of instructions "N" >long will not crash the machine is much more costly if N > 1. >(To say the least, if you know anything about mathematical logic). >If there are M instructions (and M is probably around 1 BILLION) >then there may be about M^N cases to check. And what is N? >For a classic CISC machine a price is paid to make N = 1, or >at least small. But for a RISC machine, might N be 10 or more? Seems to me that this argument is completely the wrong way around. Say you've got a machine that executes fixed length (say 16-bit) instructions on fixed (in this case, even-byte) boundaries. If you can prove that it behaves properly for each of these instructions (and can trap odd-byte instruction fetches) then you can prove by induction that it behaves properly for all possible instruction sequences. If, on the other hand, you have a machine that executes variable-length instructions, you get into the combinatorial explosion that the original poster is concerned about. You have to prove that the machine behaves for all operand lengths, for any and all instruction prefixes, and (since you can now jump into the middle of an instruction) for execution of partial instructions. This is a much more difficult job than handling the fixed-length instruction case. Consider the guys at Intel who, just when they think they've validated their microinstruction sequencer, have to deal with segment override and bus lock prefixes. [Well, presumably it's not sprung on them as such a surprise, but you get the point.] Guess which end of this spectrum RISC machines lie at. [If anyone wants to discuss this further, I'd suggest comp.arch ... there hasn't been a good RISC/CISC row in there for weeks now. I've changed the header to send followups to that group.] >Anyway, no need to make too big a deal about this. Probably all the >vendors can fix things in software alone ... Maybe. If the hardware works up to some minimum level, then yes. > ... and certainly CISC chips >with bugs in them have been shipped in the past too. But surely never a VAX :-) Oh, BTW, I'm not trying to grind a RISC axe here. Seems to me that this problem is pretty much independent of RISC/CISC, with the slight exception that a RISC chip _ought_ to be easier to characterise and validate than a CISC chip. Whether that gets done properly with either (or indeed any) architecture is a rather different matter. Regards, Mike. moliver@pyramid.com {allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver
bruce@seismo.gps.caltech.edu (Bruce Worden) (08/15/90)
In article <481@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: >In article <1990Aug13.053147.11714@laguna.ccsf.caltech.edu> bruce@seismo.gps.caltech.edu (Bruce Worden) writes: >>In article <477@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: >... >> > Please read what I said. I did *not* claim they were only useful for >single user mode, just that it was one condition where it could be used. >Another situation is where you have users of (well debugged) applications, >which appears to be your situation. You may assume that to be our situation, but it is not. I never said anything about running "well debugged" applications. Applications are developed here all the time, and, as I said before, not by professional programmers. Now YOU read what YOU wrote: >>> .... But when you try to >>>stress the system, it's going to fail. This bug existed on Suns (for example) for at least a couple of years (it was only fixed a few months ago with release 4.1 of the OS.) Surely in that time enough people stressed them to make it apparent that they were "broken systems." You would think the word would have leaked out somewhere that they were "failing" (like maybe one of the dozens of users groups or the various news groups that deal in some capacity with Sun?) Don't you think this bad press would hurt Sun's sales? Don't you think we would have heard about it? Don't you think Sun would have fixed it sooner? I do. Maybe it is just not happening. (The point of my original posting, which you chose to ignore.) So either very few people are stressing their Suns (not likely), or you are just plain wrong (more likely.) The only legitimate issue of discussion that the crashme program brings up, and lord, the one I wish it was limited to, is that of system security. If the crashme program crashes your system, talk to an expert, it represents a potential security problem. >If it is a multi-level privelege system, and the hardware can fail to >provide the necessary protection to the operating system, then the hardware >is broken. Period. How interesting. Good thing it's not a hardware bug (at least on Sparc). -------------------------------------------------------------------------- Bruce Worden bruce@seismo.gps.caltech.edu 252-21 Seismological Laboratory, Caltech, Pasadena, CA 91125 --------------------------------------------------------------------------
jc@atcmp.nl (Jan Christiaan van Winkel) (08/15/90)
) OK. Here is a quick summary of the HOW TO CRASH A RISC machine from ) a USER-MODE program test. Reports have arrived that all of these machines ) can be crashed using CRASHME.C: ) IBM RT, MIPS, DECSTATION 5000, SPARC. ) ) On the two CISC architectures tried, VAX/VMS and SUN-3, the program ) either completed or exited with a core or register dump, as expected. On the Altos 2086 running Xenix 3.3as1, the system displays: System memory timeout error on the console and dies... -- ___ __ ____________________________________________________________________ |/ \ Jan Christiaan van Winkel Tel: +31 80 566880 jc@atcmp.nl | AT Computing P.O. Box 1428 6501 BK Nijmegen The Netherlands __/ \__/ ____________________________________________________________________
pdg@hpcupt1.HP.COM (Paul Gootherts) (08/16/90)
I tried this on an HP9000 Series 800 Model 835 (a PA-RISC machine) and
it did not crash. The program got an "Illegal Instruction" and dumped
core, but nothing worse happened (I ran the program several times).
Paul Gootherts
Hewlett-Packard Co
Internet: pdg@hpda.hp.com
UUCP: {hplabs,ucbvax}!hpda!pdgkarl@haddock.ima.isc.com (Karl Heuer) (08/16/90)
In article <1990Aug15.052856.28006@laguna.ccsf.caltech.edu> bruce@seismo.gps.caltech.edu (Bruce Worden) writes: >In article <481@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: >>.... But when you try to stress the system, it's going to fail. > >[Disagree.] Clarify. Are you saying that (a) the `crashme' program never causes your machine to crash, (b) such a crash does not constitute `failure', or (c) that isn't what you count as `stressing the system'? Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
bruce@seismo.gps.caltech.edu (Bruce Worden) (08/16/90)
In article <17425@haddock.ima.isc.com> karl@kelp.ima.isc.com (Karl Heuer) writes: >In article <1990Aug15.052856.28006@laguna.ccsf.caltech.edu> bruce@seismo.gps.caltech.edu (Bruce Worden) writes: >>In article <481@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: >>>.... But when you try to stress the system, it's going to fail. >>[Disagree.] >Clarify. Are you saying that (a) the `crashme' program never causes your >machine to crash, (b) such a crash does not constitute `failure', or (c) that >isn't what you count as `stressing the system'? I am saying (a) that the `crashme' program would have crashed the system under SunOS 4.0.3 and earlier (the fact that it no longer does is irrelevent save for pointing out that it was an OS bug and not a hardware bug), and (b) that such a crash does not constitute `failure' unless it significantly detracts from the machine's utility. By `significant' I mean more than a few percent of a given installation's system crashes are caused by the bug. (c) I would claim that heavy use by a number of people developing and running applications (finite element and finite difference models, processing seismic data, processing GPS data, GUIs, et al.) on a networked system with all the trimmings does, in fact, constitute stressing a system. If it does not, then his point is still not valid because there isn't much more you could do to stress a system, short of running it underwater. Furthermore, (d) we have had no significant problem with this bug. Finally, (e) I have not heard, nor has anyone I have talked to about this issue, of anyone, anywhere having a significant problem with this bug on a Sun. Conclusion: A system with the described behavior (crashing from user mode code) while stressed for a significant period of time has not failed by any reasonable definition of the word. A conclusion supported, at least circumstantially, by the strong popularity of the system during the period in question. Frankly Karl, I'm suprised that you did not kill this subject long ago. I would have if I hadn't been stupid enough to jump into it in the first place and felt responsible to follow up. No insult, rather a compliment, intended. -------------------------------------------------------------------------- Bruce Worden bruce@seismo.gps.caltech.edu 252-21 Seismological Laboratory, Caltech, Pasadena, CA 91125 --------------------------------------------------------------------------
rogerk@mips.COM (Roger B.A. Klorese) (08/16/90)
>In article <1826@mountn.dec.com> akhiani@ricks.enet.dec.com (Homayoon Akhiani) writes: > OK. Here is a quick summary of the HOW TO CRASH A RISC machine from > a USER-MODE program test. Reports have arrived that all of these machines > can be crashed using CRASHME.C: > IBM RT, MIPS, DECSTATION 5000, SPARC. Prove it. My Mips RS2030 RISCstation cruised through it, repeatedly, and kept running fine. Caught every bogus instruction... -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 MS 4-02 950 DeGuigne Dr. Sunnyvale, CA 94086 voicemail: +1 408 524-7421 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I'm the NLA" "If the world were a logical place, men would ride sidesaddle." -Rita Mae Brown
karl@haddock.ima.isc.com (Karl Heuer) (08/17/90)
In article <1990Aug16.051437.21661@laguna.ccsf.caltech.edu> bruce@seismo.gps.caltech.edu (Bruce Worden) writes: >... such a crash does not constitute `failure' unless it significantly >detracts from the machine's utility. That's one usable definition. Others will disagree, perhaps because they are more afraid of malicious users than you are. Anyway, I think this is the key, and if the parties will agree to disagree, we can truncate this before it becomes a flame war. >Frankly Karl, I'm suprised that you did not kill this subject long ago. I don't use kill files. I actually look at every article, at least briefly, in this newsgroup and a few others. Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
andrewt@cs.su.oz (Andrew Taylor) (08/17/90)
In article <40885@mips.mips.COM> rogerk@mips.COM (Roger B.A. Klorese) writes: >> OK. Here is a quick summary of the HOW TO CRASH A RISC machine from >> a USER-MODE program test. Reports have arrived that all of these machines >> can be crashed using CRASHME.C: >> IBM RT, MIPS, DECSTATION 5000, SPARC. > >Prove it. My Mips RS2030 RISCstation cruised through it, repeatedly, and >kept running fine. Caught every bogus instruction... Either you have upgraded from RISC/os 4.5 or you weren't trying hard enough. Both our R2000 and R3000 based machines can be "crashed" by the execute random data program. A panic is caused by an illegal floating-point instruction in the delay slot of an illegal branch (instruction codes 0x07CB0D69, 0x46A7CC7D will do). The fp instruction traps and goes into a routine which sees the branch and wants to know where it will go. The routine called to calculate this realises the branch is illegal but does the wrong thing and calls panic. Trivial to fix. The original poster asserted that the program causes no problems on a SUN-3. It does cause problems on our Sun-3/50 runing SunOS 4.1. It can produce a cpu-bound process which can not be killed. The only way we've found to remove it is reboot. Various people have posted that machine X or operating system Y can't be crashed. What they really mean is they tried a few random instructions and they didn't cause problems. From our experience trying a bit harder could produce a different result. Seems like implementors could usefully use this program for crude testing. Andrew Taylor
burley@world.std.com (James C Burley) (08/17/90)
In article <BURLEY.90Aug11024356@world.std.com> burley@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@world.std.com
rmj@tcom.stc.co.uk (Rhodri James, the beardless wonder) (08/17/90)
In article <1990Aug16.051437.21661@laguna.ccsf.caltech.edu> bruce@seismo.gps.caltech.edu (Bruce Worden) writes: >In article <17425@haddock.ima.isc.com> karl@kelp.ima.isc.com (Karl Heuer) writes: >>In article <1990Aug15.052856.28006@laguna.ccsf.caltech.edu> bruce@seismo.gps.caltech.edu (Bruce Worden) writes: >>>In article <481@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: > >>>>.... But when you try to stress the system, it's going to fail. > >>>[Disagree.] > >>Clarify. Are you saying that (a) the `crashme' program never causes your >>machine to crash, (b) such a crash does not constitute `failure',[...] > > [...] (b) that such a crash does not constitute `failure' unless it >significantly detracts from the machine's utility. By `significant' I >mean more than a few percent of a given installation's system crashes >are caused by the bug. Here I have to side with Karl. Given that the crash can happen with a program following a rogue function pointer off into the wide blue yonder, something which is not implausible in a development environment, then just ignoring it is very short sighted. However you look at it, your system is then shown to be vulnerable to crashing, deliberate or accidental. You might consider the degree of risk acceptable in your conditions, I certainly wouldn't accept it in an academic or commercial development environment. Again; you may consider the risk acceptable, just don't ask me to. I'll see you after the next crash. The problem is basically that your definition of "failure" is much less stringent than mine or Karl's, or a fair number of other contributors to this argument at a guess. -- * Windsinger * "Nothing is forgotten..." * rmj@islay.tcom.stc.co.uk * Mike Whitaker * or (occasionally) * "...except sometimes the words" * rmj10@phx.cam.ac.uk * Phil Allcock
vladan@idt.UUCP (Vladan Djakovic) (08/17/90)
In article <1150@cluster.cs.su.oz>, andrewt@cs.su.oz (Andrew Taylor) writes: > >Prove it. My Mips RS2030 RISCstation cruised through it, repeatedly, and > >kept running fine. Caught every bogus instruction... > > Either you have upgraded from RISC/os 4.5 or you weren't trying hard enough. > Both our R2000 and R3000 based machines can be "crashed" by the execute random ... M-120 running UMIPS 4.0 did not crash after 50+ runs with different seeds. If anybody ever managed to actually crash R[2|3]000 please post exact parameters given to crash. Any other arguments are immaterial. -- ############################################################################ # Vladan Djakovic, IDT (Integrated Device Technology), Santa Clara, CA # # ... uunet!idt!vladan (All opinions are mine. Whose else?) # ############################################################################
peter@ficc.ferranti.com (Peter da Silva) (08/20/90)
(c) This does not constitute stressing the system. Any system should be written with the expectation that any arbitrary sequence of bits may be executed by an application, unless it is written such that this is explicitly prevented (eg, Burroughs). -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com (currently not working) peter@hackercorp.com
bks@alfa.berkeley.edu (Brad Sherman) (08/29/90)
The crashme program completely hung an IBM RS6000 (AIX ver. 3.1). This was on the third set of program parameters. Brad Sherman (bks@alfa.berkeley.edu) ------------ One difference between ants and humans is that while ants send their old women off to war, humans send their young men. -E.O.Wilson