COMMAND

    xfs

SYSTEMS AFFECTED

    Linux (others?)

PROBLEM

    Chris Evans found following.   This advisory illustrates that  the
    xfs problem recently mentioned by Michal at:

        http://oliver.efri.hr/~crv/security/bugs/Linux/xfs2.html

    is but one of  many minor carelessnesses in  the xfs source.   xfs
    probably  cannot   be  considered   secure  until   a  full    and
    time-consuming audit  is performed.   In particular  run xfs  as a
    listening TCP network service at your own extreme risk.

    xfs's prime problem, like quite a few X protocols, is that a large
    amount of code paths are available for exploration by remote users,
    _before_ any sort of authentication is attempted.

    Essentially, xfs is very easy for a remote user to segfault.  This
    is obviously  bad because  all dependent  X servers  will go down-
    very nasty DoS.  The problem attracted my attention because RedHat
    now use "xfs" to serve fonts to the local X server.  The  problems
    could well  be worse  than DoS  - if  you can  get the  process to
    trample on  random memory,  this can  often be  leveraged in  some
    way...

    Generally,  most  of  xfs's  problems  are  blind trust of lengths
    supplied in  data arriving  over the  network.   This means  it is
    always jumping off  the end of  buffers and crashing.   Here is  a
    practical example of the above:

        telnet localhost 7100
        Connected etc.
        BBBBBB<press return>

    xfs has crashed at this point.

    Unfortunately, this  flaw occurs  in multiple  places rather  than
    just  once.   The  font  protocol  looks  into network packets for
    lengths, multiple times.  As another practical example, dispatch.c
    (from xfs), function ProcEstablishConnection(). There is the  line
    of code

        ad += client_auth[i].datalen;

    Which again picks an unsigned short out of the network packet, and
    trusts  it  not  to  take  us  over  the  end of the input buffer.
    Related to the above, there is  a very very subtle bug related  to
    signed/unsigned conversions.   We get an  unsigned short from  the
    network, and then store it in the following structure

        typedef struct _auth {
            short       namelen;
            short       datalen;
            char       *name;
            char       *data;
        }           AuthRec;

    i.e. we stuff  an unsigned short  into a signed  short, so we  can
    get a -ve value.   This -ve value then  gets passed to a  memcpy()
    and becomes  positive and  very large,  smashing various  internal
    buffers.

    There  is  one  other  crash  issue  noticed  by  inspection.   In
    dispatch.c from xfs,  ~line 932, there  is an assert()  statement.
    This  assert  is  fired  in  response  to network data the program
    doesn't understand!  This is clearly  a bug - assert() is for  use
    when  a  program  bug  has  been  hit,  rather  than  corrupt data
    arriving over the network.

SOLUTION

    Nothing yet.