FYI: see bug #152840, where the RH security team seems to believe that there is
(at least) a similar vulnerability in the FC2 version (1.18.1).

See bug 136313 and bug 136314.

need confirmation that < 1.18.1.1 is not affected...

*** Bug 136314 has been marked as a duplicate of this bug. ***

Okay.  Did some work researching this bug on groffer script, part of the groff
package since groff-1.18.1.

BOTTOM LINE:  I truly believe none of {rh73, rh90, 1} in the Status White-
board are vulnerable to this groffer script vulnerability in typical circum-
stances.  And it's likely Fedora Core 2 is also not vulnerable.

  Reason:  Groffer is either not there or is broken.

  rh73:  Installs groff-1.17.2-12.i386.rpm.  Version 1.17.2 of groff
         does not include groffer.  No groffer = no vulnerability.

  rh90,  |  groffer comes from groff-1.18.1-20.src.rpm (no updates)
  fc1,   |  groffer comes from groff-1.18.1-29.src.rpm (no updates)
  fc2 :  |  groffer comes from groff-1.18.1-34.src.rpm (no updates)
         |
         |  It appears groffer was broken in version 1.18.1 of groff.  It
         |  certainly is broken on my FC1 machine.
         |
         |  The NEWS file in the sources of groff-1.18.1.1 (new upstream
         |  release of February, 2004) indicates this:
         |
         |     "VERSION 1.18.1.1
         |     ================
         |
         |     "This is the same as 1.18.1 but with an updated version of
         |     the `groffer' script (which was broken in 1.18.1)."
         |
         | --(<http://ftp.gnu.org/gnu/groff/groff-1.18.1-1.18.1.1.diff.gz>)

   My Fedora Core 1 version of groffer comes out of the box (.i386.rpm) broken
   in at least two ways, assuming the 'ash' shell is installed, that prevent
   it from running at all.  (The ash shell is installed by default when FC1
   is initially installed, but it is not a mandatory package.)

      1)  Line 49 of /usr/bin/groffer:

                _this='groffer.sh';

          For some reason (I don't know why), groffer wants to re-run itself
          under the "ash" shell rather than "bash".  When groffer attempts
          to re-run itself, it tries to re-run itself using this (line 110):

                exec ${_shell} "${_this}" "$@";

          Where ${_shell} = 'ash'.

          Well, there is no "groffer.sh" available for it to re-run, so it
          fails.

      2)  Even if you comment out line 49 and go in and manually (as root)
          change line 48 from:
                #_this="@BINDIR@/${_PROGRAM_NAME}";
          to:
                _this="/usr/bin/${_PROGRAM_NAME}";

          the script will run, but at line 3282, the script silently exits
          before it gets to any potentially vulnerable code (running in
          the ash shell), because ash evidently doesn't know how to handle
          this statement:
                  trap clean_up  2>/dev/null || true;
          
   Note that if you *don't* have ash shell installed, the script will *not*
   fail in either (1) or (2):  It will merely continue on running in the
   default shell in (1), and (2) doesn't burp.  So when ash is *not* in-
   stalled, there is a possible vulnerability, during the creation of a
   predictably named temporary file, that could be abused.

But it looks like Red Hat 9 installs the 'ash' shell by default, FC1 does, 
and RH7.3 is not vulnerable.  Can someone check & see if Fedora Core 2 also
installs ash by default?  If so, its groffer script is also most likely to
be broken and should present no threat.

That all said, it turns out there ARE some vulnerabilities in the groff
packages of concern, at least in the RH9, FC1, and FC2 distributions.
CAN-2004-1296 -- temporary file handling vulnerabilities in pic2graph and
eqn2graph.

Am thinking about opening a new bug report for this, but it is not clear to
me if any other distros out there felt this was urgent enough to issue a
Security Alert with new packages.

I already have the needed patches in hand, obtained from Debian's patches of
groff-1.18.1.1.  (Since the only thing that changed from 1.18.1 to 1.18.1.1
is the groffer-script-related files, Debian's patches of pic2graph and 
eqn2graph apply without any back-porting needed.)

Anyone have any opinions?

(ps:  Could someone who has privileges change the Component name on this bug
from "Package Request" to "groff"?  Thanks!)

Changed..  I guess pushing out the updates if the patches are trivial won't hurt..

Moving to NEW. UNCONFIRMED has been obsoleted.

This will not be pushed out.  Only actual critical security fixes will be
released for these older releases.