[25727] in bugtraq

home help back first fref pref prev next nref lref last post

Re: remote DoS in Mozilla 1.0

daemon@ATHENA.MIT.EDU (Andreas Beck)
Tue Jun 11 14:17:04 2002

Date: Tue, 11 Jun 2002 17:03:37 +0200
From: Andreas Beck <becka@uni-duesseldorf.de>
In-reply-to: <20020611153514.A20669@lemuria.org>
To: bugtraq@securityfocus.com
Mail-Followup-To: Andreas Beck <becka@uni-duesseldorf.de>,
	bugtraq@securityfocus.com
Message-id: <20020611150337.GA7879@uni-duesseldorf.de>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-disposition: inline
Content-transfer-encoding: 7BIT

Tom <tom@lemuria.org> wrote:
> > Is this really a mozilla bug? 
> It's a bug in X that becomes remote-exploitable through mozilla.

Ack. If X can be crashed by an application, X is at fault. We all know, that
there are "legal" ways to make X unuseable (xlock e.g.), but actually
crashing the X server should never happen, as a faulty application may cause
data loss in correct applications this way. Not what we expect in a Unix
environment.

> > 	(a) Fix every app to disallow font sizes bigger then <maxvalue>
> > 	(b) Fix XFS to return an error code to the calling application 
> > when requested font size is greater then configured <maxvalue>
> > Personally i would go for b.
> Personally, I would go for both, with a limitation on a, namely that
> apps that accept remote data (i.e. mozilla) should definitely do some
> checking on that data before handing it to the local system (i.e. X).

Right. Applications that accept untrusted data have a special responsibility
to canonicalize them in order to protect the underlying system from the
possible side effects. No matter if the underlying system _should_ be able
to cope with them.

However that does not mean, the bug in the lower layers may remain there.

Also note, that - as I already reported to Tom in PM - not all X servers
are affected. I tested the example sites using Mozilla 1.0RC2 on an XGGI
server which is based on rather old X-consortium code IIRC and the expected
effects did not show up.


CU, Andy

-- 
Andreas Beck             |  Email :  <becka@uni-duesseldorf.de>

home help back first fref pref prev next nref lref last post