🚀 go-pugleaf

In article <161@unisec.UUCP>, dpw@unisec.UUCP (Darryl Wagoner) writes:

> 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.))

dpw@unisec.UUCP (Darryl Wagoner) wrote in article <161@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?

>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

In article <694@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes:
>dpw@unisec.UUCP (Darryl Wagoner) wrote in article <161@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

>dpw@unisec.UUCP (Darryl Wagoner) wrote in article <161@unisec.UUCP>:
> ... 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

wcs@ho95e.UUCP (Bill Stewart) wrote in article <1056@ho95e.UUCP>:
> ... 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''?

..Bob
-- 
UUCP: wanginst!ulowell!page	Bob Page, U of Lowell CS Dept
VOX:  +1 617 452 5000 x2976	Lowell MA 01854 USA

In article <161@unisec.UUCP>, dpw@unisec.UUCP (Darryl Wagoner) writes:
> 
> 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?

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

/* Written 11:34 am  Nov  1, 1986 by page@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?

In article <3800016@snail> carroll@snail.CS.UIUC.EDU writes:

>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%maynard.uucp@harvisr.harvard.edu     (617) 367-6846

	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

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

In article <2481@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>	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.

In article <2481@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>
>	Maybe I'm missing something obvious, but why are block-mode
>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.  :-)
-- 
Larry Campbell       MCI: LCAMPBELL          The Boston Software Works, Inc.
UUCP: {alliant,wjh12}!maynard!campbell      120 Fulton Street, Boston MA 02109
ARPA: campbell%maynard.uucp@harvisr.harvard.edu     (617) 367-6846

> 	Maybe I'm missing something obvious, but why are block-mode
> 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