Conference noted::hackers_v1

Yeah, I agree.

 I started it once, and got some neat feedback.  However, everyone has
his own idea of the purpose of a NOTES file.  I enjoy the background
stuff, too.

 Asking for hints on protection violations, etc., sounds like Fagin and
his pickpocket gang.  I have no big hangup on passing out security
problems, but I would like to see a little more control.  There is a
SECURITY NOTES file on VORTEX for such things.  After all, if the systems
I'm on might be liable to attack, I'd like to know about it (preferrably
before the attempt starts).

 I hear a plea for a hacker's cookbook.  I promised to drop some stuff in
this NOTES file a long time ago...looks like I'd better get started...

	I think it is interesting to hear both ABOUT hackers and
ideas FROM hackers. Sometimes hearing ABOUT hackers lends information
on weaknesses in various security procedures.

	Well, I started this file to talk *about* hackers, but I don't mind
also having stuff *for* hackers.  How best to learn except by experience?
	Keep those cards and letters and (especially) hacks coming!
		<_Jym_>

	The availability of a anonamous mail utility would probably go a
long way toward increasing submissions of hacks!

	Any takers...

	There is an anonymous mail utility, but I don't think it would work
here.  What one needs is a device to change the username.  That requires
CMKRNL privs.  Changing the nodename is as simple as
		    $ define sys$node "_Vaxuum::"
(which is how I do it).
	Maybe an anonymous notes utility...
		<_Jym_>

    	If one had CMKRNL, how would the username be changed?

    Go in and hack the field JIB$T_USERNAME in the JIB for your process.
    You find the JIB from the field PCB$L_JIB.  You find the PCB from
    the System Address SCH$GL_CURPCB - for your own process only, that
    is.
    
    T

    	You must first understand that I don't know how to go
    about doing all that stuff. I was hoping for a 'just MACRO
    this file, then run it' answer with a neat little program
    attatched!
    	That would be ideal, but probably not practical from the
    programmer's point (your's) of view.
    
    Thanks anyway,  Mike

Not all 'hackers' know MACRO...

I have a copy of such a macro program that used to work in VMS V3.7,
but crashes the system under V4.2  I'm sure it's a minor bug
somewhere.  I'll send it along after I find the problem.

Scott Hesterman

re:30.10 by CANYON::OPERATOR "Scott Hesterman" 

> Not all 'hackers' know MACRO...

> I have a copy of such a macro program that used to work in VMS V3.7,
> but crashes the system under V4.2  I'm sure it's a minor bug
> somewhere.  I'll send it along after I find the problem.

Thanks for the warning! I just crashed my 750 with 25 furious DECmail, 
etc.  users working on it.....

Fortunately no-one found out that it was the system manager himself who
caused the crash....

Diego

; I know this program works, I tested it on VMS 4.3.
; Just save this reply and edit out any stuff that appears above these
; comments.
; rename the file to something.mar
; $ mac something.mar
; $ link something.obj,sys$system:sys.stb/select
; $ run something.exe        
; that's all there is to it.
;        
    		.LIBRARY	/SYS$LIBRARY:LIB.MLB/
		$JIBDEF
		$PCBDEF
		.PSECT	DATA,NOEXE
TERM_NAME:	.ASCID	/SYS$INPUT/
TERM_CHAN:	.WORD	0
STATUS:		.QUAD	0
PROMPT_STRING:	.ASCIC	/Enter new user name :  /
INPUT_BUFFER:	.ASCII	/                       /
		.PSECT	CODE,NOWRT
		.ENTRY		START	^M<>
		$ASSIGN_S	DEVNAM=TERM_NAME,-
				CHAN=TERM_CHAN
		BLBC		R0,EXIT
		MOVZBL		PROMPT_STRING,R1
		$QIOW_S		CHAN=TERM_CHAN,-
				FUNC=#IO$_READPROMPT!IO$M_CVTLOW,-
				IOSB=STATUS,-
				P1=INPUT_BUFFER,-
				P2=#12,-
				P5=#PROMPT_STRING,-
				P6=R1
		BLBC		R0,EXIT
		MOVZWL		STATUS+2,R1
		MOVB		#^X20,INPUT_BUFFER(R1)
		$CMKRNL_S	ROUTIN=KMODE_CODE
EXIT:		$EXIT_S	R0
		.ENTRY		KMODE_CODE	^M<>
		MOVL		SCH$GL_CURPCB,R1
		MOVL		PCB$L_JIB(R1),R6
		MOVC3		#12,INPUT_BUFFER,JIB$T_USERNAME(R6)
		MOVL		#1,R0
		RET
		.END START		

    YeGods, it works!!! Boy does it do wierd things around mail, etc....
    
    Obviously one needs CMKRNL to run it, but... you can set your username
    to an unknown name (ANONYMOUS) and then if you send mail, MAIL doesn't
    care where it's coming from.
    
    HOWEVER, if you set it to a KNOWN name, (like another account name)
    MAIL picks up THAT ACCOUNT'S PERSONAL NAME!!! Also if someone mails
    to you (you aren't you anymore :-) you don't get notified, of course,
    since you aren't you (your username isn't what it was before)...
    Also, since nothing else in your process header has been changed,
    you still maintain your own context... I though you couldn't do
    this sort of thing, I guess I am very wrong...
    
    Now all some bright person has to do is surreptitiously INSTALL
    it on a system with CMKRNL privs, then any joe or jane could change
    usernames... also with minor modifications I would assume other
    fields in P0 space (AUTHPRIVS for instance) could be changed for
    the duration of the process... neat hack - I need to watch out for
    this sort of thing...
    
    Anybody try this on a system with accounting enabled? I wanted to
    try it with an anonymous username on a system with accounting enabled
    but I wonder if the system would get upset...
    
    /intrigued
    

    
    Sorry, I forgot to mention the funny side effects with mail.
    

< Note 30.14 by BRSDVP::ANONYMOUS "Nothing can go wrong...go wrong...go wrong" >

Not to mention the effect on Notes, eh?

	    What version of VMS are you folks using?  The version I have
	(V4.2) won't let you run MAIL if your username isn't in the
	SYSUAF.DAT file.
	    I've got my own program to do this, but I've always had to
	send mail using an anonymous mail utility.
			<_Jym_>

re: .16

V4.4.  Can't get into MAIL either, but you can send things if you
do it from the command line.

Even weirder:  SIMON had set his username to PIPER, someone sent
mail in to PIPER, message ended up in Simon's .MAI, and I got the
"1 new message" when I went into MAIL.  Good thing we're all
friends here...

-piper

    The username you set to goes right into the accounting file.
    
    	Jon

    There is a field in your P1 space called CTL$T_USERNAME.  I had
    a similar program which ran on V3.x.  It copied the new name to
    both this field and the JIB.
    
    I suppose this field is used by DCL.  Anyone know what for?
    
    tom_p

		$QIOW_S		CHAN=TERM_CHAN,- 
				FUNC=#IO$_READPROMPT!IO$M_CVTLOW,-
				IOSB=STATUS,-        ^^^^^^^^^^^
				P1=INPUT_BUFFER,-    |||||||||||
				P2=#12,-             -----------     
				P5=#PROMPT_STRING,-       |
				P6=R1                     |
                                                          |
	Why convert to lowercase --------------------------

	Ciaran :-(

    re:.20
    
    Not convert to lower case - convert lowercase to UPPERCASE!...
    
    
    
    [From the I/O User's Reference Manual - Terminal driver section]
    
    IO$M_CVTLOW	Lowercase alphabetic characters (hexidecimal 61 to 7A)
    		are converted to uppercase when transferred to the user
    		buffer or echoed.  Only for IO$_READBLK, IO$_READVBLK,
    		and IO$_READPROMPT.

    I don't think anyone uses the username field in P1 anymore. In V2 (and
    before) of VMS, the username was stored in the P1 cell. In V3, the
    username moved to the JIB. After V3 came out, I wrote a program that
    changed only the JIB field, and it looked like no one paid any more
    attention to the P1 cell. As a matter of course, though, it would pay
    to change them both. Better safe than sorry. 
    
    	Jon

       You really should set your IPL to IPL$_SYNCH when accessing those
    types of data structures.  It's not nice to be changing them, and
    have something else happen at an IPL < 8, and might not feel too
    happy with your being in the middle of changing stuff.
    
       Alright - probably you won't have problems, but it's not impossible
    that something strange COULD occur.  For completeness and adherence
    to the VMS standards, you should raise your IPL to IPL$_SYNCH.
    
       Which also means that you have to be REAL sure that you won't
    page fault while in kernel mode, at the elevated IPL.  Locking the
    pages into your working set, or using some macros (ASSUME) to make
    sure the entire block of code does reside on ONE page, with a .ALIGN
    PAGE at the top.
    
       Of course, this is HACKERS, not ENGINEERS...
    
    					-mjg
    

>    The username you set to goes right into the accounting file.

	This reply was back a few and brings up a question.  I have used one
of the previously posted macro programs to change my username and then logged
out.
	My test was to see what went into the accounting file.  The answer:
My real process name.  

	Can this be hacked around?
    
Mac the hack

    
    The data in P1 space (CTL$T_USERNAME) is used for accounting (the
    JIB can't be used because it refers to the entire process tree...
    {subprocesses, remember?}). 
    
    An even more interesting hack comes courtesy of Bruce Ellis: 
    move nulls to the field PCB$T_TERMINAL, and you'll disappear from
    the userlist!
    
    Hint: when $cmkrnl is called, the address of the PCB is placed into
    register R4...
    				- HBM

    In general, it's not a good idea to rely on the system service
    dispatcher putting your PCB into R4. A better programming practice (so
    you don't forget and call the routine from someplace besides $cmkrnl)
    is to use CTL$GL_PCB as a pointer to the PCB. Don't use SCH$GL_CURPCB.
    If you're using it, change it to the CTL location. 
    
    Also, if you really want to vanish, you should decrement the user count
    that SHOW USERS looks at. And if you really, really want to vanish, try
    figuring out a way to vanish from the prying eyes of SHOW SYSTEM.
    
    	Jon

    The P1 cell is used for accounting, and also for queueing jobs.
    A batch or print job will inherit the username from this location,
    NOT from the JIB.
    
    As far as disappearing from the SHOW SYSTEM list:
    
    I thought of pointing my slot in the PCBVEC to NULL's, thereby making
    me no longer show up.  My PCB would still be in the scheduling queues,
    though, so I'd get cycles.  I asked a couple of people in VMS Development
    about this at different times (back when I was a customer at a DECUS
    Symposium); the response format was always the same, even though
    the content differed:
    
    `Why, <thus-and-so> would happen.  Wait.. {Pause} Hmmm..  I don't
    know.'
    
    Generally, the responses were that the system would crash, or my
    process would hang (due to EXE$NAMPID not being able to find me),
    but ALL held out hope that it *might* just work..
    
    I haven't gotten around to actually doing this; someday (perhaps
    even soon) I'll give it a try.  If I do, I'll try to remember to
    post the results here..
    
    #ken "Ghost In The Machine" Coar	;-)}

    Well, I'm in the VMS exec group, and I know what happens if you do. 
    
    In short, the system won't crash, but you may wish it had.
    
    The reasons follow:
    
    When your entry in the PCB vector points to the null process, you're
    gone. Really gone. Completely gone. Gone gone.
    
    Let's suppose that your process is sitting at the prompt in DCL and you
    use the Studly Patcher (a.k.a. >>>D/V/U) to put your PCBVEC entry
    to the null process. So far, so good. 
    
    Now you type return to DCL. Well, what has just happened is that you've
    completed an I/O. You were at LEF, and now the I/O is done. Okay, so
    you go into I/O post-processing. You get an AST to deliver the IOSB and
    stuff like that, and complete the I/O. 
    
    Guess what? Your process is gone, remember? 
    
    Well, IOPOST finds out from QAST that you're not there, and just shrugs
    its shoulders. Something is weird, 'cause you *were* there just a
    minute ago, you've still got channels and stuff, but things aren't *so*
    weird that it's going to bugcheck. It just completes the I/O.
    
    Now here you are, your I/O has completed, except that no one has told
    you about it. Well, this is a fine mess you've gotten yourself into --
    you're hung. Not only that, but you're gone. You can't even do a
    STOP/ID, $DELPRC, or anything to get rid of yourself. You're going to
    have to wait for a reboot to get deleted. 
    
    Okay, let's suppose you're a clever hacker, and you remembered to write
    down the PCB address of your process before you did this. You *did*
    remember to do that, didn't you? 
    
    Fortunately, if you're a *really* clever hacker, you'll log into
    another terminal, do a quick SHOW USERS <your-username>, and then go
    into SDA (analyze/system) and type SHOW POOL /NONPAGED /TYPE=PCB.
    Shouldn't be *that* hard to find the right one -- it's the one that
    *isn't* in SHOW USERS. 
    
    Whew. So we go back to the console and reset the PCBVEC entry. Well,
    you're still hung. That didn't fix anything. Okay, so it didn't work.
    STOP/ID the process. Well, you're still waiting for this I/O to
    complete. And it isn't going to. The $DELPRC system service, $CANCEL,
    and the drivers you had channels assigned to are going to have a short
    discussion about what to do about this. They're going to come to the
    conclusion that you're waiting for an I/O to complete (as if you didn't
    know), and will mark you as DELPEN (delete pending) and put you in
    RWAST state because you're waiting for an AST. That's what RWAST means
    -- waiting for an AST.
    
    Now guess what? You've probably seen this before, or at least heard
    about it. You're in RWAST, more STOP/IDs aren't going to change a thing
    (because you're DELPEN), you're still hung, and starting to feel
    foolish. The AST you're waiting for is the one you missed while you
    were invisible. 
    
    This is sort of like the riddle, "What time is it what an elephant sits
    on your VAX?" The answer is, "Time to reboot!"
    
    Well, this wasn't the worst case scenario. Let's look at a couple
    of worse things that could have happened.
    
    Let's suppose that instead of sitting at DCL, you were reading your
    mail. That means you have an RMS lock, because you were processing a
    bunch of files. Just to make it really fun, let's suppose you were
    using UIS on a workstation, too. 
    
    Well, while you were using that file, someone else wanted to do
    something, so they sent you a blocking AST. Well, you're gone,
    remember? Just the way you missed the IOPOST AST, you're going to miss
    the lock manager's AST. That means that not only are you hung, but any
    processes that tried to get you to give up your lock are hung, any
    people waiting on them are hung, and you really better hope you didn't
    do this on a machine in a large cluster! If the file you were dinking
    was SYSUAF (which MAIL does)... Well, for one, you won't be able to log
    in on another terminal. I'll leave two, three, and four to your
    imagination. 
    
    An interesting aside: I'm willing to bet that if you time this just
    right, you can hang some set of other processes without actually
    hanging yourself. 
    
    If you were on a workstation, similar lock hangs are going to happen,
    and you'll hang some set of processes that were waiting for the screen
    lock, the VPS (occlusion) lock, or the keyboard lock. Other interesting
    locks for other things will have similar effects. 
    
    The problem with this trick is that it works too well. You *do* vanish
    completely. You just don't want to disappear *completely*, you want to
    hide from SHOW SYSTEM, without hiding from VMS. 
    
    There apparently *is* a way to do this. A fellow I met who works in
    Europe sent me a program that *does* make you completely disappear.
    Most of the time. It doesn't work all the time, but it *does* have the
    interesting property that if it doesn't work, it crashes the system
    instead. I will leave how to do it as an exercise for the reader. I'll
    give another hint that it is both very elegant and very sleazy. 
    
    	Jon

Re  .28 
    
>    There apparently *is* a way to do this. A fellow I met who works in

As in 383.12  (or replies ) ???

Peb