xfs security issues (fwd)

2000-04-19T00:00:00
ID SECURITYVULNS:DOC:86
Type securityvulns
Reporter Securityvulns
Modified 2000-04-19T00:00:00

Description

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@ferret.lmh.ox.ac.uk> 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