Re: tlug: X-Mailer: USANET web-mailer (34FM1.4.02C)

["Scott M. Stone" <sstone@example.com>]

On Fri, 12 May 2000, Chris Sekiya wrote:

> On a bit of a tangent ...
> 
> ... I have to take issue with distributions that rig X to use xfs by default.

Doesn't Sun do this?  Seems that i"m always disabling it in Solaris's
inetd.conf after installing a new box.  Or is Sun's better from a security
perspective?

> 
> xfs is a very bad idea from a security perspective.
> 
> I attach a message from the xfree86 developers list.  The response was along
> the lines of "yeah, well, we know that an audit would be a good idea but
> we don't really have the resources right now".
> 
> -- Chris
> 
> 
> To: devel@example.com
> Subject: xfs security issues (fwd)
> Date: Wed, 19 Apr 2000 15:29:53 +0800
> 
> Hi,
> 
> I notice xfs (the X font server) recently hit the news. It seems I never
> sent the below message on to Bugtraq (at least a search doesn't show up
> much). I'm guessing it's still relevant.
> 
> This message illustrates that the xfs problem recently mentioned by Michal
> 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.
> 
> Note that the message I'm forwarding is almost a year old. Since no-one's
> seen fit to do something about it, I guess it's time to raise the profile
> again.
> 
> Cheers
> Chris
> 
> 
> ---------- Forwarded message ----------
> Date: Mon, 31 May 1999 18:09:47 +0100 (GMT)
> From: Chris Evans <chris@example.com>
> To: <removed>
> Subject: xfs security issues
> 
> 
> Hi,
> 
> I can't remember if I ever sent you these. Fixing "xfs" security has been
> on my TODO list for a while but I just haven't had the time :-( Hopefully
> if I give you an overview of the issues, you can get someone to sort it
> out. I regard the issues as serious.
> 
> 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. Fortunately, I persuaded them to
> disable xfs listening via TCP!
> 
> 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 I 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.
> 
> 
> Let me know what you think about the above. In particular, let me know if
> it is going to take a while to fix. I might be able to persuade someone on
> the security-audit list to look into it if you and your developers are too
> busy.
> 
> Cheers
> Chris
> 
> --------------------------------------------------------------------
> Next Technical Meeting: May 13 (Sat) 13:30 Temple University Japan
> * Topic: Crypto and Security	Speaker: Chris Sekiya
> Next Nomikai Meeting: June 16 (Fri), Tengu TokyoEkiMae.
> --------------------------------------------------------------------
> more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan
> 
> 

--------------------------
Scott M. Stone, CCNA <sstone@example.com>
UNIX Systems and Network Engineer
Taos - The SysAdmin Company 

--------------------------------------------------------------------
Next Technical Meeting: May 13 (Sat) 13:30 Temple University Japan
* Topic: Crypto and Security	Speaker: Chris Sekiya
Next Nomikai Meeting: June 16 (Fri), Tengu TokyoEkiMae.
--------------------------------------------------------------------
more info: http://www.tlug.gr.jp        Sponsor: Global Online Japan