Re: rlogin revealed

Article: 8404 of alt.hackers
Newsgroups: alt.hackers
From: A.Main@dcs.warwick.ac.uk (Zefram)
Subject: Re: rlogin revealed
X-Nntp-Posting-Host: stone
Message-ID: 1995Aug7.134512.25441@dcs.warwick.ac.uk
Sender: news@dcs.warwick.ac.uk (Network News)
Organization: Department of Computer Science, Warwick University, England
Date: Mon, 7 Aug 1995 13:45:12 GMT
Approved: unlink(2)
Lines: 94
Status: RO

Peter Seebach <seebs@solutions.solon.com> wrote:
>Uhm.  The first and 2nd args [of this program] are both ignored.
And as given,
>this will fail; it will discover there is no file called
>'rlogin jamminbox.site.dom' in /bin.
>
>The following was developed at Xerox, but is not to the best of my
>knowledge proprieteary.
>
>This should do "the right thing" on any remotely POSIX system.
[program elided]
>Known bugs:
>It will be immediately obvious to a trained user that the argv[] is fake -
>commands which only show argv[0] will show 'vi thesis' in the example,
instead
>of 'vi'.  This is a dead giveaway.

Commands that show all arguments will also show the real arguments.  In
the case of an rlogin, that means the site will be revealed.  "vi
jamminbox.site.dom" looks like a valid command, but is damn
suspicious.  Unfortunately, it's not possible to patch rlogin to stomp
over its arguments or take the arguments from a file, because it needs
to be setuid root.

Plus, your program is far longer than necessary.  This suffices:

main(c,v)int*v;{execvp(v[1],v+2);}

assuming int is the same size as char*.  For greater portability, it
gets two characters longer.  Error checking would add a few more
characters.  I call this program "argv".  Usage is

$ argv xpilot vi

or, if you want to see how robust things are,

$ argv gcc
zsh: segmentation fault  argv gcc

That was gcc falling over.  Yes, gcc can segfault even when properly
installed.  So does emacs.  And rlogin, which (being setuid root)
really *needs* to be 100% robust.  zsh also falls over, unfortunately.
A lot of programs that look at their arguments don't actually check to
see if argc is 0.  A few do.

Speaking of setuid root programs, I happened to look through the source
for chfn and a couple of related programs on my Linux box this week.
If anyone wants to look for it, there's a very obvious, and very
pointless, race condition, which I'd rather not elaborate on.  (It's
difficult to exploit, but could make a system quite unusable if
caught.)  Removing the race actually simplifies the programs... I'll be
sending patches to the maintainer of the util-linux package shortly.

ObHack (in case the above one-liner doesn't count):

Back when I was using VMS, I maintained (briefly) a BBS-type program.
It had been written by someone else, in Pascal, and the first thing I
did was translate it into C, fixing all the bugs.  Just thought I'd
mention that.  This program was very nice to use; it made use of VT220
graphics, giving a nicely boxed list of the messages that had been
left.  It set scrolling to smooth, and when scrolling this list it only
scrolled that part of the screen, giving the appearance of the list
being on a long roll of screen of which you could only see part.  When
one looked at a message, a hand would move smoothly up from the bottom
of the screen (smooth scrolling again), and pull a board down from the
top of the screen, displaying the message.  All very nicely designed.

When one finished using the program, the author's usercode was
displayed, in rather nice large letters, again using VT220 graphics.
Taking over the running of this program, I wanted to add my own
usercode to this display.  But I didn't know the escape codes for the
graphics.

Examination of the program revealed some of the codes it output.  I
experimented, by leaving out groups of escape sequences, to find out
which did what.  When I had identified the code that set up the
characters' bitmaps, I fiddled with the parameters (all terribly
obfuscated), to find out what they meant.  It turned out that the
half-dozen or so numbers following the initial escape sequence
controlled the range of characters being set up, and a couple of other
parameters that I forget now.

More experimentation (read: leaving out bits of the code) revealed how
much of the following data was used for each character.  Further
fiddling indicated that two characters were output for each column of
each character, one contributing four bits and the other five (if I
remember right).  It was easy enough then to see which bit of which
character controlled each bit of the bitmap.  I designed a small bitmap
to represent my usercode, split it into character-sized chunks, and
translated these, by hand, into VT220 escape codes.  I got the thing
working, but my design looked crap next to the work of the program's
original aythor.

Lame?  It was an achievment at the time.

-zefram

Back to index