[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::hackers_v1

Title:-={ H A C K E R S }=-
Notice:Write locked - see NOTED::HACKERS
Moderator:DIEHRD::MORRIS
Created:Thu Feb 20 1986
Last Modified:Mon Aug 03 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:680
Total number of notes:5456

110.0. "favorite dcl bugs" by WSGATE::MPALMER () Fri Apr 12 1985 15:37

has anyone found any cute dcl bugs lately?  my two favorites are from
a while back...

good ole
$ SET dir/VERS=1 *

and
$ DEF SYS$OUTPUT ""
T.RTitleUserPersonal
Name
DateLines
110.1VAXUUM::DYERSat Apr 13 1985 06:276
	I like this one.

		    $ A := if 1 then A
		    $ A

#6	<_Jym_>\
110.2SPRITE::OSMANWed Apr 17 1985 15:1919
These are kind of cute.  They seem to fall into two classes.  The "a := if
1 then a" and "def sys$Output """ ones are in the class of things that
cause register dumps followed by process crash.

The "set dir *" (yes, this simplified version "works" as well), is in
the class of things that print garbage on the screen.

Does anyone have some juicier classes ?  Perhaps a class that crashes
system instead of just the process ?

Perhaps a class that does something privileged ?

Back to the class of printing garbage on the screen, perhaps someone can
find a sequence of appropriate working commands followed by a screen-garbage
command, cleverly chosen so that the garbage "does something".  For instance,
maybe we can find one such that the garbage curses, or perhaps the garbage
nicely clears the screen, or you devise it !


110.3VAXUUM::DYERThu Apr 18 1985 05:094
	I wouldn't call this a DCL bug, but it's a bug in many DCL procedures.
If a procedure prompts for something using INQUIRE (instead of READ SYS$COMMAND)
you can specify lexical functions.  My favorite is 'f$verify(1)'.
#6	<_Jym_>\
110.4SPRITE::OSMANThu Apr 18 1985 18:5621
It took me quite awhile to realize the bug you are illustrating.

I tried INQUIRE and fed it 'f$verify(1)' (yes, you need to type the
apopstrophes !).   Nothing strange happened, other than verification
being turned on as expected.

I finally realized that the bug is sort of a security one.  A .COM file
may possibly trap ctrl/Y and turn off verification in order to keep its
inner workings a secret.

But by typing 'f$verify(1)', the user manages to peek at what's happening
anyway !

Is this really a security problem ?  If it's possible to protect files
such that "@" works but "TYPE" doesn't, then yes, if not, then no, since
in latter case even if f$verify hack were "fixed", user could copy the
.COM file, remove the "set noverify" from within it, then run it.


Thanks for the entry.

110.5LATOUR::AMARTINSat Apr 20 1985 01:384
Yes, it is a security bug.  I used it on my wife's INUSE procedure to discover
the magic password only yesterday.
				/AHM

110.6ORPHAN::BRETTSun Apr 21 1985 00:4211
                    
$loop:
$ 	inquire/nopunct PASSWORD  "What is the magic word? "
$	set noverify
$	if "''PASSWORD'" .nes. "FOOBAR" then goto loop
      
can be broken in a variety of ways.   My favorite is

What is the magic word? "YES"" then exit !"

/Bevin
110.7VAXUUM::DYERSun Apr 21 1985 03:5710
	Some of these problems can be gotten around by careful use or avoidance
of the single- and double-quotes.  And, of course, using READ SYS$COMMAND
instead of INQUIRE.
	I call it a bug because the command procedures with this problem are
not handling unfriendly user input gracefully.
#6	<_Jym_>\

P.S.:  I like Bevin's magic word.  I usually use "1 then exit !" for this...
P.P.S.:  BTW, Bevin, what happens when you type GOTO LOOP in the middle of
BRB (-:)???
110.8KOALA::ROBINSMon Apr 22 1985 13:347
The toolshed 'interface' USED to check for this and, if you had entered
'f$ver(1)' or some such hackery, print "Hackers not welcome" and log you
out automatically.
I don't think it's written in DCL any longer, though.

.Scott.

110.9SPRITE::OSMANMon Apr 22 1985 20:3750
When I read about how somebody broke someone's "INUSE" procedure, I checked
mine, and was proud to see that it doesn't seem to be breakable in that way.

One thing I like about mine is that you aren't asked to supply a special
password.  You just type your regular password !

I'd be interested in knowing if someone finds a way to break into my procedure.

Here it is :

----------------------------------- cut here ---------------------------------
$! Command file which disallows use of the logged-in terminal until the
$! correct password is typed.
$!
$! This command files does NOT request a password.  It merely waits
$! for the current correct password for the user to be typed.
$!
$ define = "define"
$ delete = "delete"
$ directory = "directory"
$ set = "set"
$ close = "close"
$ write = "write"
$ on = "on"
$ inquire = "inquire"
$ write sys$output -
    "When you want to reclaim your terminal session, enter your password."
$ on control_y then goto try_again
$ try_again:
$ on warning then goto try_again
$ set terminal/noecho
$ inquire password "Password"
$ password = f$edit (password, "trim")
$ set terminal/echo
$ if password .eqs. "" then goto try_again
$ on warning then continue
$ login_info = "''f$edit (f$getjpi ("","username"), "trim") ''password'"
$ if f$length (login_info) .ge. 43 then goto try_again
$ filespec = f$parse(f$environment ("procedure")) - -
    f$parse (f$environment ("procedure"),,,"version")
$ write sys$output "Checking password . . ."
$ define/user sys$output nl:
$ define/user sys$error nl:
$ directory 0"''login_info'"::'filespec'
$ if "''f$integer ($status)'" .eqs. "1" then goto good
$ write sys$output "Wrong password."
$ goto try_again
$ good:
$ write sys$output "Thank you."
$ exit
110.10ORPHAN::BRETTTue Apr 23 1985 00:4410
Re .-1;
Extra trivial... sorry (heh heh...)


		'F$PID(GOTO)


breaks out straight away.

/Bevin
110.11BELKER::LUWISHTue Apr 23 1985 13:0212
Re 110.9:

Also, what happens if the network shuts down while you're out of your office?
Any attempt at FAL access (ala 0"username password"::) will cause a fatal
error no matter what password you type in, which will be trapped by your
ON WARNING statement - the legitimate user will be locked out forever!
Thank goodness for the "bug" reported in 110.10 (and the ability to log into
another terminal and stop your process - although what happens on something
like a MicroVAX which could have only one terminal, the console!)

Ed

110.12KOBAL::GILBERTTue Apr 23 1985 13:5811
I think the following *stilll* doesn't entirely fix things.
Please enjoy finding the hack to get through this one!

$ login_info = f$edit(f$getjpi("","username"),"trim") + " " + password
  ...
$ dir_command = "directory 0""" + login_info + """::" + filespec
$ dir_command
$ if $status .eq. 1 then goto good

For what it's worth, I wouldn't use this, because if the procedure
is compromised then so is my system password.
110.13SPRITE::OSMANTue Apr 23 1985 17:465
I'm starting another note for this "in_use" stuff, so as to leave this note
for more people's "favorite dcl bugs".

/Eric

110.14KATIE::LYNCHThu Apr 25 1985 17:5416
I know its a lot like:

	$ DEFINE SYS$OUTPUT ""

but try this one:

	$ SHOW LOG ""

considering the following works I'd class it as a bug:

	$ DEFINE "" ABC

These are all from a V4.1 machine, I don't know if they're present in any
previous versions.

-Eric.
110.15WSGATE::MPALMERThu Apr 25 1985 18:3428
defining the null logical is pretty illogical!

also, there are DCL commands which sound like nonsense (they actually
have possible uses, but...) :
$ DIR/SINCE=TOMORROW

and I have a list around of legal but mangled DCL command strings which
utilizes the fact that the command is unique in 4 letters...  as I remember,
most of them are pretty off-color but I'll try to find it and edit out the
really perverted ones.

$ Search for tomorrow
$ Anal humor
$ run amok
$ all gone
$ help me
$ debutante
$ link sausage
$ write a book
$ convert to judaism
$ princess Diana
$ Stark naked
$ all the time
$ read my lips
$ closet queen
$ attache case

and other strange things that DCL will listen to...