Conference noted::hackers_v1

This doesn't have much to do with hacking.

Let me, instead, propose a new contest: what's the most elegent way
to keep a machine running (in spite of "the slings and arrows of
outrageous fortune which electronic flesh is heir to").

Some examples from the PDP-11:

1. If the terminal driver sees a delimiter input (i.e. a user types
   Carriage Return), it exits through the scheduler, rather than
   through the trap return.  (Actually, this is true for all device
   drivers when input/output completes.)  The scheduler, of course,
   runs the job with the highest priority.

   On one system, the line clock randomly lost interrupt enable.
   The system kept running users as it could schedule on *just* the
   various I/O interrupts.  The only way the service people could tell
   that the clock died was to note that the time of day didn't change.
   (I think this story's from Ted Sarbin.)

2. On early PDP-11's, the terminal interface (KL11) would drop interrupt
   enable.  The line clock would too (as noted above).  I remember hearing
   of one system (possibly RSTS/E, possibly not), where the clock interrupt
   service routine enabled interrupt on the console terminal, and the
   terminal driver enabled interrupt on the line clock.

Martin

    One nice way is to disable virtual memory management and wait (briefly).
    Another is to CMKR and HALT.

    If you find any NON-PRIVILEGED ways to crash a MACHINE, please send
    these directly to the VMS group and DON'T POST THEM HERE (though you
    might mention here that you found a good one).  I expect Mark Pilant
    would be willing to judge elegance amoung any security holes we might
    find.  If this be a contest, I'll offer the cookie.

    Quite a number of system services, for instance $ASSIGN, start out
    like this:
    
    	.entry exe$assign,^m<...
    	ifnowrt #2,(r11),30$	;can channel number be written?
    	clrw (r11)		;clear channel number in case of error
    	. . .
    30$:movzwl #ss$_accvio,r0	;set access violation status
    	ret
    
    For those of you unaccustomed to reading macro, the above code
    makes sure the user's parameter (passed by reference) is
    writable, then proceeds to write it.  If not writable, the code
    returns the ss$_accvio error.  Without the IFNOWRT check,
    the system would crash if (R11) is unwritable.
    
    My questions are:  Couldn't a nonprivileged user crash the
    system by managing to make the address become unwritable
    AFTER the IFNOWRT but BEFORE the CLRW ??
    
    How could a user do this ?  I have an idea.
    
    First, I was considering an infinite loop in a process that
    repetetively does $assign, while a timer ast uses repetetive $setprt
    to flip the writability of the page from writable to non-writable.
    Statistically, this would eventually hit the vulnerable phase.
    
    However, I don't believe this particular method would work,
    because since the $assign code is in kernel mode, the timer ast
    would never succeed in executing between the IFNOWRT and the CLRW.
    
    My next idea is to use TWO processes, which share the (R11) address
    via the $CRMPSC/MGBLSC services.  One process would do the $assign
    in an infinite loop, while the other would flip the page between
    writable and unwritable with $SETPRT.  I'd expect the vulnerable
    phase to soon be hit and system "brought to its knees".
    
    However, in my experimentation so far, I get a failure on the
    $SETPRT (error is "No privilege for attempted operation").  Can
    anyone think of something along these lines that would work ?
    I've started experimenting with $CRETVA/$DELTVA instead of the
    $SETPRT, but no luck yet.
        
    /Eric

    Not VMS, so I'm out of the contest, but there used to be a few ways
    to bring RSX on WOOKIE to a screeching halt.  Not sure if they have
    been fixed, but we try to stay away from those kinds of thing now...
    
    Willie
    

    I won't post the program (too simple...) but in college I got
    three processes locking up memory using a pascal program that
    "got" longwords continuously (while true do).  I tried to get 
    a fourth going but the 750 (with three meg) wouldn't take it.
    
    	The system was down for an hour, came up by itself.  The
    page fault quota was then modified by the system manager so it would
    not happen again.  
    
    	This "crash" was avoidable and was done as an experement.
    What else is college for?

    	I hate to think how long it would take the same program to crash
    a 780 with 12 meg.
    
    mac

    One clever one involves the MA780 shared memory.  Since the shared
    memory communicates with the CPU(s) via interupts (when something
    changes) you can turn the MA off with no ill effects.  However,
    if it is then turned back on (assume VMS is running through all
    this), the system will crash.  Why?  The MA said "Something changed"
    and VMS went to look.  The pointers in the shared structures are
    now garbage (due to cycle in power) and the system access violates.
    Given CMK priv, this is very easy to do from another computer connected
    to the shared memory.  Simply poke something that the other guy
    is looking at.  That computer goes away, but you are fine!!

	One of the "Hacktical jokes" mentions submitting a batch job
	that resubmits itself twice and says that "In V3.7 the queue
	manager	sometimes shut down in disgust at that sort of thing." 
	I remember someone doing this in college under V4.1 and more
	than the queue manager shut down in disgust ... 8^}

	As a matter of interest, what happens if the pagefile or the
	swapfile get full ?

<CFM>

    
 >   	As a matter of interest, what happens if the pagefile or the
 >	swapfile get full ?


    	The error the operator terminal was spitting out while my 
    "get memory" program was eating memory was "pagefile 75% full"
    with all kinds of warnings around it then "pagefile 95% full"
    and that was the last we heard from it for an hour or so!
    
    	So in answer to your question.....The system crashes.  Or at
    least it did on me (the 750 a few replies back).
    
    mac

    re: .-2
    
    Our twin 785's did that not too far back. The actual sequence of
    events was more interesting, though. Our problem was a too-small
    page-and-swap-file-size, coupled with a
    too-large-process-slot-quantity. What eventually happened was as
    close to a thrash as I have ever seen, with about seventy processes
    in LEFO, twenty in HIBO, and SWAPPER in (haha) LEFO for some reason.
    There were about three processes which could do things, but one
    by one they went away (lost in PFW land). We eventually had to reboot
    the cluster from the console, reconfigure the page and swap files,
    and change a number of other parameters. This stuck in my mind since
    it should never have happened in the first place (it turned out
    that with 32 meg apiece, we were only using about 1/3 of the memory
    at the time!)....

    My favorite one is the one where you fill your entire address space
    on a PDP-11 with RETI instructions (I think that's the one -- it's
    been a while).  This requires some rather tricky macro hacking to
    accomplish.
    
    What happens is that, by design, interupts are disabled for one
    instruction after a RETI.  Net effect is that the machine hangs and no
    interrupts get in from anything to get it out.
    
    A related set of fun ones are:
    
    On an older unix system (before 4.2), create a file name "./././././..."
    for a megabyte or so and try to open it.  If you have enough memory
    so that the pager doesn't get invoked in this, the system will pause
    for a significant period of time.  On 4.2 (and ultrix-32) pathnames
    are limited to 1024 characters and get copied into an system buffer
    before the name parse happens.  On older systems, the name was parsed
    directly from user space and there was no kernel imposed limit on
    the length.  I think somebody hung a PDP-11 unix system by getting
    his entire address space to have a reasonable file name such that
    when the counter wrapped at 64K, things still made sense.
    
    Another related one on 4.2 unix systems (fixed in 4.3 and ultrix)
    was a misimplementation of the fsync system call.  This call causes
    any delayed writes for a specified file to happen and stalls until
    they have made it to disk.
    
    The algorithm used was something like:
    
    	for block_num = 1 to last_block_in_file do
    	    see if the block is in the buffer pool
    	    if so, write it out
    	end for;
    
    On unix, you can have files with holes in them.  These files don't
    take up disk space for the holes.  If you did something like:
    
    	fd = creat("new_file", 0);
    	lseek(fd, 0x40000000, 0);  /* seek to byte number 40000000 (hex) */
    	fsync(fd);
    
    This would not crash the machine, but it would make it go away for
    a few minutes.  (Actually, on one machine I worked on, it caused
    the "system dead" watchdog timer to fire and rebooted but that's
    a different problem).
    
    Steve Glaser

    re: .10:   Isn't it amazing how what VMS would consider a bug, UNIX
    (*) systems consider a feature?   VMS customers would submit a SPR.
    Unix customers would look in awe at the hack.   Oh well.   :-)

    re .9
    
    >  ...what happens if the pagefile or the swapfile get full?...
    
    We had a runaway batch job once which created a HUGE log file
    (something like 17000+ blocks.  I (stupidly) tried to edit the file
    (without looking to see how big it was) with TPU and the system
    came to a grinding halt.  Seems that TPU uses  virtual memory to
    hold your edit session, and my process space just swelled up to
    fill the entire pagefile.  I figured out what was happening when
    I went upstairs to the computer room and saw console messages about
    the pagefile getting filled up.  Nobody could do anything until
    I used a stop/id on my process to free up those pages.
    
    						Bob

    You can always forget "W" on QIOW.  Watch how long it takes system
    to die.
    
    - Vikas

re: .10, .11

Related problem in RSTS:  In BASIC PLUS, if you accessed a disk block beyond
the current end of the file, the file would be extended.  The "block number"
was an UNsigned 16-bit value - just about the only place 16-bit integers were
considered to be unsigned.  An "off by one" error could easily get your
program to look at block -1 = 65535.

For "normal" users, who had quotas, this would use up their quota fairly
quickly.  On the system I ran into this on, I had a privileged account - so
RSTS loyally allocated every free block on the disk to me.  This allocation
was done in FIP, which was single-threaded and uninterruptible - so the whole
system went away for a long time - minutes.  Eventually, having failed to
get me all the blocks I wanted, it returned an error.  Then came the fun of
stalling the system for just as long by deleting the file....

							-- Jerry

    re .12:  That would not have happened if someone had not been silly
    enough to give you an enormous page file quota.
    
    Burns

Re .15 :

	Maybe we should have an extra cookie for the most 'elegant'
	method which exploits a sys$mangler's goof ?

	My favourite was when somebody discovered a priority 6 batch queue
	with infinite CPULIM and put an infinite loop on it (accidentally
	would you believe). Needless to say it soon disappeared much to the
	dismay of a few users who had been using it for quickie compiles.
	(This was in a busy college environment where you can guess the 
	potential usefulness of such a queue). 

<CFM>

    re .10:
    
    Are you sure that wasn't SPL on an 11/70?  
    
    	inst:	spl	0
    	start:	mov	inst,r0
    		mov	pc,sp
    	10$:	mov	r0,-(sp)
    	        br	10$
    		.end	start
  
    - M