Slaying Gould dragon with a wooden horse
Darryl Wagoner
Like many others, I attended the Unix Expo in New York City this week.
At the Gould booth there was a large sign challenging Unix wizards
to break into their "Secure Unix" system. The also gave out a flyer that
stated the following:
|---------------------------------------------------------------
| GOULD
|
| *** HACKER CHALLENGE ***
|
| UNIX EXPO 1986
|
| OCTOBER 20,21,22
|
|There is a text file on our 6040-I, UTX/32S - SECURE UNIX*
|system. We challenge anyone to find out its contents. The file
|pathname is:
|
| /usr/unixexpo/securefile
|
|RULES:
|
|1. You must access the system from one of two user
| terminals. Login as "guest1" or "guest2".
|
|2. All winners who successfully break into the system will
| be placed in a drawing for a grand prize winner
| of a 19" color tv.
|
|3. In the event of any conflicts, the decision of the GOULD
| show director will be final.
|
|*Unix is a trademark of AT&T
|
|----------------------------------------------------------------
The contents of the file was:
"gould makes firebreathing,very high performance super mini machines."
I will present the case history of how I broke it using the most classic
of all hacker tricks. In addition I located other weaknesses in their system
that would allow even the most novice hacker to break into UTX/32S.
Having only limited time and a public account to do my hacking, I choose to
use the Trojan horse attack. They willing revealed the environment that
a user is put in is a restricted environment either much like or exactly
like the chroot(2) system call of Unix. Which, to the best of my knowledge
hasn't been defeated. Therefore, it would have been a waste of time
to try to defeat the chroot. The Gould salesmen readily offered to show me
their environment which reveled that PATH was set to ".:/bin:/usr/bin:..."
The key being the current directory is at the beginning of the search
path. I quickly created a 'ls' trojan horse and put it in the guest
home directory. Then I asked if root could get to the guest directory and
asked him to do so. He did a cd to the guest directory and did a 'ls'
which fired off my trojan horse. I could have waited for him to fall into
the trap. I was afraid that some one else would find my trojan horse
and use my work. Before I got everything right, I had to enlist the unknowing
support of root twice more, due to differences in Secure Unix.
At this point, let me point out that in order for Gould to archive this
level of security they had to strip out a lot of the things that
makes Unix powerful (ex: suid bits) and isolated users into a chroot
environment. UTX/32S also seems to have many cross checks with the
different /etc/passwd and /etc/group files. The first attempt was
to add my own "admin" account to the top level passwd file. This failed
because the user id I chose wasn't in the group file. Another trojan
later, I had my own group in the group file. Still the system complained about
my group not being valid, but it did let me log in as an administrator.
Then a very strange thing happened. I couldn't execute "cshsu(8)"
(Gould's answer to su, but less secure). The real admin couldn't execute
cshsu either. I returned the next day and asked if they had found out
how I had broke in. With their audit file, I expected that they had.
The answer was that I had broke something and they had to reboot; that
caused the audit file to be removed. (note: if you ever want to cover
your tracks on UTX/32S just crash the system.) Well, this gave me new
hope that I could break it with another, better horse. With the next
horse I copied the file in question to an area that I could read.
(Besides making a copy of the file I could have also planted a
worm or virus. Of course no one would do such a thing :-) )
Then I showed them the content of the file in question. Well
they lost their cool to say the least. I was happy to explain how I did
it. They informed me that I had not really broke the system but just
tricked the system admin and that the method that I used was immoral.
I tried to argue with him about fifteen minutes without success. In hope
of reasoning with him I enlisted the help of a impartial third party.
(Who I haven't ask if I could quote so I will withhold this persons' name).
This person listened to both sides and concluded that I had broken the
system with a classic hacker technique.
The question I have for the net is: Is using a trojan horse a legit way
to break into a system? What is your opinion?
SUMMARY of Gould UTX/32S System
I am not even sure that it can still be called Unix since SUID bits have
been removed. After all that is what Dennis M. Ritchie patented as the
Unix protection scheme. But as far as being secure, I will say that
it is or could be as secure as any other unix system. It takes more
forethought to break standard unix. It takes away one of the most
powerful features of unix. The cshsu should have stripped out the
current directory from the path like su(1) does. For that matter, the shells
should have removed the current directory or at least put it at the end
just for good system hygiene. The tty driver should have a kill character
to allow login to be killed to prevent trojan horses. There is also
another hole I will not going into at this point.
--
Darryl Wagoner
UniSecure Systems, Inc.; Newport, RI; (401)-849-0857
{allegra|gatech|linus|raybed2|ihnp4|cci632} !rayssd!unisec!dpw
Frederick M. Avolio
> The question I have for the net is: Is using a trojan horse a legit way
> to break into a system? What is your opinion?
This is silly. (I am *NOT* calling Darryl silly!) Asking if there is
a legitimate way to break in to a system. Anything that works is
"legitimate" if you can call something `devious' legitimate. Having
the current directory in your superuser search path is always
dangerous and kind of an obvious thing to avoid. In fact, you might
argue that root should have a NULL path and have to expressly give
full paths for every command to be sure. (I wouldn't argue this...
but I have fat fingers.)
I assume you didn't win the color TV. I hope you were included in the
drawing. Saying "No fair!" when someone does something unanticipated
is foul play. (Let us remember Kirk's solution to the Kobiashi Maru
challenge. (And please no spelling corrections please. I couldn't
care less.))
Bob Page
> ... Is using a trojan horse a legit way to break into a system?
Any method that does the job can be considered effective. Who cares
about being legitimate? Would you pooh-pooh a system cracker that
just destroyed your passwd file because she didn't use a 'legitimate'
method?
>Darryl Wagoner
>UniSecure Systems, Inc.; Newport, RI; (401)-849-0857
Interesting.
..Bob
--
UUCP: wanginst!ulowell!page Bob Page, U of Lowell CS Dept
VOX: +1 617 452 5000 x2976 Lowell MA 01854 USA
#Bill.Stewart
>d...@unisec.UUCP (Darryl Wagoner) wrote in article <1...@unisec.UUCP>:
>> ... Is using a trojan horse a legit way to break into a system?
>
>Any method that does the job can be considered effective. Who cares
>about being legitimate? Would you pooh-pooh a system cracker that
>just destroyed your passwd file because she didn't use a 'legitimate'
>method?
What Darryl did was perfectly legit. An alternative way to do it would be to
send mail to root saying "My %s doesn't work when I'm in my home directory; can
you take a look at it, and see if I goofed on something?" Obviously this has
some limitations in a "break my trade-show system" environment, but it's the
equivalent you'd use in real life.
Some alternatives are "I got a new version of rogue! want to try it?" if you
have a dumb system administrator. An equally legitimate approach, useful at
tradeshows, is to see what kind of terminal the administrator has. Most CRTs
have a block=transfer mode that can be exploited by a letter-bomb. Even if
they get rid of setuid and give root a useful path, they probably didn't
bomb-proof mail.
--
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
ricker
> ... Is using a trojan horse a legit way to break into a system?
I think that Darryl's security-cracking technique just emphasized what any
competent system administrator knows--that hardware and software technology
alone are not the only components of a security and cannot be relied upon
exclusively.
He was smart enough to spot the weakest link in Gould's security--the people.
They should have given him the prize!!!
Ricker
Bob Page
> ... Most CRTs have a block=transfer mode that can be exploited
> by a letter-bomb.
Anybody who reads mail as root deserves to get a letter bomb!
You should forward root's mail to non-priv'd accounts, and keep
`mesg n' and `biff n' (a Berkeleyism) so people/daemons can't write
to root's terminal. You can hack su(1) to do this for you, including
catching the suspend/wakeup signals to restore biff/mesg as you
bounce in and out of `su' state.
Harder to deal with: If you log in as root on the console and somebody
sends a message via syslog(3). Anybody found a resonable defense against
this, other than ``don't use block-mode terminals for consoles'' (an
academic question, we don't anyway) or ``don't log in to the console''?
Steve Summit
>
> to break into a system? What is your opinion?
You know those stupid logic problems where you're on an island,
and some of the natives always tell the truth, while some of them
always lie, but you can't tell them apart, and you're supposed to
ask an unknown native one question which will let you determine
which of two paths leads to some village? Calling a trojan horse
an "illegitimate" way of breaking into a system is like getting
mad at a crafty native for giving you some kind of distruthfully
honest answer which causes you to walk down the wrong path.
What would Gould have considered a "legitimate" way of breaking
in? What does a "legitimate way of breaking in" even mean?
Steve Summit
tektronix!copper!stevesu
car...@snail.cs.uiuc.edu
/* Written 11:34 am Nov 1, 1986 by pa...@ulowell.UUCP in snail:net.unix */
Harder to deal with: If you log in as root on the console and somebody
sends a message via syslog(3). Anybody found a resonable defense against
this, other than ``don't use block-mode terminals for consoles'' (an
academic question, we don't anyway) or ``don't log in to the console''?
(...)
/* end of text */
What about 3b2's, where you HAVE to be at console to login as root?
Larry Campbell
>What about 3b2's, where you HAVE to be at console to login as root?
I suspect this is true of any System V system; I know it is true
of Microport UNIX (a sanctioned System V port for the PC/AT). I complained
to Microport about it and they said "That's the way it came from AT&T".
You can still log in as yourself and then su.
--
Larry Campbell MCI: LCAMPBELL The Boston Software Works, Inc.
UUCP: {alliant,wjh12}!maynard!campbell 120 Fulton Street, Boston MA 02109
ARPA: campbell%maynar...@harvisr.harvard.edu (617) 367-6846
Roy Smith
Maybe I'm missing something obvious, but why are block-mode
terminals a security problem?
--
Roy Smith, {allegra,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
Lance E. Shepard
The SV I've used allowed you to recompile login to allow root to login
to terminals other than the console. I believe there was also a #define
you could set to prevent other users from logging into the console.
Lance Shepard
Doug Gwyn
> Maybe I'm missing something obvious, but why are block-mode
>terminals a security problem?
Actually, this applies to any terminal that can be told by the host
to store characters and then be told by the host to transmit stored
characters. Programmable function keys sometimes have this property.
The problem is that these features allow anyone who can transmit
more-or-less unmolested information to the terminal to force-feed
input from that terminal, which so far as UNIX knows was typed by
the logged-in user. This can be protected against to some degree
by changing the "write" utility, mail-reading interface, etc. to
not send ESC and other possibly harmful characters unmapped to the
terminal. However, "cat file" can still trip a mine like this.
Larry Campbell
>
>terminals a security problem?
They're not all security holes, but the ones that have the following
pair of escape-sequence driven commands are:
1. "Put the following string in your buffer." (say, "rm -rf *")
2. "Send the buffer to the host."
On such a terminal, one cute mail message can ruin your whole day. :-)
Henry Spencer
> terminals a security problem?
Any terminal which can be caused, remotely, to send part of what's on its
screen is a security problem on a normal Unix. Just write something out
to the screen and then send the send-screen sequence, and the characters
come in just as if the user had typed them. Do it when somebody is
signed in as root on such a terminal, and you've got superuser powers.
The only fixes are to either (a) avoid such terminals, or (b) carefully
control what other people can write to your terminal. The latter is
harder than it looks, because the bad guy can always put the interesting
sequences in mail messages ("letterbombs") or in files rather than sending
them directly.
Remotely-programmable function keys can also cause trouble this way. If
their contents can be read back remotely, the same technique works. If
there is no read-back, you have to choose a key that the user will hit
in the course of normal use.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry