COMMAND

    faxcron, xferstats and recvstats

SYSTEMS AFFECTED

    Hylafax software (faxcron, xferstats and recvstats)

PROBLEM

    Tobias  Richter  found  following.   This  is  about  the  HylaFAX
    Facsimile  Software  copyrighted  by   Sam  Leffler  and   Silicon
    Graphics,  Inc  but  available  for  free.  faxcron, xferstats and
    recvstats as they are  installed with hylafax-v4.0pl2 can  be used
    to execute arbitary awk programs as the invoking user.  All  three
    programs are usually run  by cron on behalf  of the fax user  (aka
    uucp).

    faxcron,  xferstats  and  recvstats  which  are  all  Bourne Shell
    scripts create temporary files in /tmp which are later executed by
    awk.  The names  of these temp files  can easily be guessed.   Any
    awk code that  is found in  a correctly guessed  file will be  run
    verbatim (if the  attacker was clever  enough to protect  his file
    from being overwritten).   There are several  other files  created
    but not executed in /tmp with such a weak naming sheme and without
    and checks for tampering.

    Thomas  Biege  added  following.   While  setting  up  the HylaFAX
    package of S.u.S.E.  Linux 5.1 he  found some nice  security holes
    in the fax-filter.

    1.  The spool-file (fax_$USER.ps)  is created w/ mode 666  and has
        U/GID 'lp' -  this bug allows  modification of the  spool-file
        which doesn't seem very dangerous, but think about a fax which
        contains the  company's logo,  the name  of a  top-manager and
        some malicious information

    2.  Another  scary fact is,  that the filter-script  doesn't check
        for an already existing "spool"-file or link now, an  attacker
        is able to overwrite files w/ the perm. of 'lp' and to  modify
        the file (mode:  666).  The  attacker is also  able to exploit
        possible holes in 'lpd' by creating malicious spool-files  and
        s/he could execute commands w/ the UID of 'lp' by creating and
        rewriting filter-scripts, that are in /etc/printcap but aren't
        created.  If the attacker could access the faxspool direc. and
        user  'lp'  owns  the  filter-script,  s/he has the ability to
        overwrite the script, which leads  to an DoS attack (hm,  what
        would happen if the attacker links the spool-file to /dev/null
        or /dev/zero?) solution: use the builtin-shell-command  'test'
        or better  recodeing of  the filter-  script in  C/++ or  Perl
        using  open(O_EXCL|O_CREAT)  and  using  another  spool-direc,
        otherwise an local (maybe remote) DoS attack still exists.

    3.  If the attacker is able to remotely set a username of  his/her
        own choice,  i.e. `echo  "+ +"  > ~lp/.rhosts,  by faking  the
        network-protocol of the HylaFAX system s/he could gain  remote
        access to the HylaFAX server...  ... it's a bad idea to set  a
        shell in /etc/passwd for the user 'lp'.

SOLUTION

    Disableing  those  scripts  completely  should  not  break hylafax
    serivces.  You'll  only miss those  nice reports.   Those problems
    with S.u.S.E.  seem to  be fixed  now so  check their update sites
    (e.g.  ftp.suse.com).  Fixes for the hylafax maintainer should  be
    on    their    way.       Debian    2.0r5    has    this     fixed
    (hylafax-client_4.0.2-7.deb/hylafax-server_4.0.2-7.deb).