bugBattle for Wesnoth - Bugs: bug #13037, Malicious compressed data from...

Show feedback again

bug #13037: Malicious compressed data from client can exhaust memory on MP server

Submitted by:  Daniel Franke <dfranke>
Submitted on:  Sat 21 Feb 2009 10:39:35 AM UTC  
Category: BugSeverity: 6 - Security
Priority: 5 - NormalItem Group:  None of the others
Status: FixedPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: 1.5.10+svnOperating System: Linux

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Mon 16 Mar 2009 09:34:22 AM UTC, comment #6:

DFranke commented that this one "seems to be fixed" and the fix is definitely included in 1.5.14 (might have been in already before). That is I do not know about the "malicious server can kill clients that try to connect", but since the report is marked as fixed...


Nils Kneuper <ivanovic>
Project Administrator
Wed 25 Feb 2009 08:19:02 AM UTC, comment #5:

rhonda: yup, that needs to be fixed as well, but it's not nearly as much of a concern. If users are connecting to malicious servers that keep crashing their client, I think that can be filed under "Doctor, it hurts when I do this" :-)

Daniel Franke <dfranke>
Project Member
Tue 24 Feb 2009 04:17:01 PM UTC, comment #4:

The commit in 33069 was only to the server but if I'm not misunderstood the attack pattern could also be used from a malicious server to exhaust memory in a client.

Gerfried Fuchs <rhonda>
Project Member
Tue 24 Feb 2009 10:33:08 AM UTC, comment #3:

In revision 33069 Dave / Sirp commited a fix for this.

Commit message:
fixed DoS attack using z compressed WML on server

Commit diff:

So the bug should be fixed in 1.5.12, the fix was too late for 1.5.11. Anyway, someone please check if it is really fixed and the fix is working...

Nils Kneuper <ivanovic>
Project Administrator
Mon 23 Feb 2009 02:16:57 PM UTC, comment #2:

Some stuff from yesterdays IRC discussion about this issue, since the report it private anyway...
Short version: looks like Sirp is working on it...

[So Feb 22 2009] [22:40:01] <boucman> Ivanovic: is someone working on the non-python CVE ?
[So Feb 22 2009] [22:48:46] <Sirp_> boucman: did you get to test my fix, btw?
[So Feb 22 2009] [22:49:23] <boucman> yes, no problem
[So Feb 22 2009] [22:49:30] <boucman> I thought I had left a line in the log
[So Feb 22 2009] [22:51:06] <Sirp_> boucman: probably. I missed it
[So Feb 22 2009] [22:51:11] <Sirp_> and good that it works with no problem.
[So Feb 22 2009] [22:51:22] <boucman> did you close the bug ?
[So Feb 22 2009] [22:51:35] <Sirp_> no I marked it as ready for test
[So Feb 22 2009] [22:51:49] <Sirp_> I'm wondering if I should try to implement the same thing for sending data, or whether that's not as big a deal
[So Feb 22 2009] [22:51:55] <boucman> ok, with a comment for original reporter to test, it should be fine
[So Feb 22 2009] [22:52:00] <Sirp_> I removed this forced closing of sockets thing, so there's no chance of a crash anymore.
[So Feb 22 2009] [22:52:17] <boucman> Sirp_: depends how complicated it is...
[So Feb 22 2009] [22:52:59] <Sirp_> boucman: our networking code is now "terrible". We really need to get out of this nightmare of #ifdef USE_POLL ... #ifdef USE_SELECT ... #else ...
[So Feb 22 2009] [22:53:15] <Sirp_> so I'm going to wait for 1.7 I think and then try to get one good networking interface going
[So Feb 22 2009] [22:53:30] <Sirp_> and I closed the bug.
[So Feb 22 2009] [22:53:35] <boucman> Sirp_: your preaching to a converted here...
[So Feb 22 2009] [22:53:55] <boucman> did you have a look at https://gna.org/bugs/index.php?13037
[So Feb 22 2009] [22:54:40] <Sirp_> no....let me see....
[So Feb 22 2009] [22:57:27] <Sirp_> hmmmm I thought I had handled that by having a max input size, but it looks like I didn't....
[So Feb 22 2009] [22:57:46] <Sirp_> what should be the maximum WML document size we accept on the server? 20MB?
[So Feb 22 2009] [22:58:38] <dfranke> I think that's a little small.
[So Feb 22 2009] [22:58:47] <dfranke> You could easily get over that if you had custom music and such.
[So Feb 22 2009] [22:59:03] <Ivanovic> boucman: i asked silene to have a look
[So Feb 22 2009] [22:59:10] <Ivanovic> that is: he won't have time before tomorrow
[So Feb 22 2009] [22:59:22] <Sirp_> hmmmm 50MB?
[So Feb 22 2009] [22:59:36] <boucman> dfranke: you can't send music or images through wml afaik
[So Feb 22 2009] [22:59:39] <Sirp_> ideally we should probably have more protection not to allow a single IP to send us multiple huge documents
[So Feb 22 2009] [22:59:45] <boucman> except if that includes campaignd
[So Feb 22 2009] [22:59:58] <Sirp_> and yeah this is only for wesnothd
[So Feb 22 2009] [23:00:09] <dfranke> oh
[So Feb 22 2009] [23:00:13] <dfranke> in that case 20MB is ample.
[So Feb 22 2009] [23:00:43] <Ivanovic> boucman: and i think silene won't complain if it is already fixed when he finds the time to look at it
[So Feb 22 2009] [23:00:44] <Ivanovic> ;)
[So Feb 22 2009] [23:00:57] <boucman> hehe
[So Feb 22 2009] [23:01:40] <silene> that's for sure
[So Feb 22 2009] [23:09:28] <Soliton> Sirp_: 20MB compressed or uncompressed?
[So Feb 22 2009] [23:10:00] <Ivanovic> 20MB compressed is much...
[So Feb 22 2009] [23:10:07] <Soliton> yes.
[So Feb 22 2009] [23:10:15] <Soliton> but uncompressed i'm not sure.
[So Feb 22 2009] [23:10:30] <boucman> does that bug affect 1.4, btw ?
[So Feb 22 2009] [23:10:30] <Sirp_> Soliton: uncompressed.
[So Feb 22 2009] [23:10:32] <Ivanovic> uncompressed larger savegames can probably easily reach this
[So Feb 22 2009] [23:10:36] <Ivanovic> boucman: of course it does
[So Feb 22 2009] [23:10:41] <Soliton> BoL saves can get pretty big, i think.
[So Feb 22 2009] [23:10:42] <boucman> :(
[So Feb 22 2009] [23:10:48] <Sirp_> should I increase it to 50MB?
[So Feb 22 2009] [23:10:59] <Ivanovic> boucman: but i don't think the fix is easy enough to be applyable there
[So Feb 22 2009] [23:11:22] <boucman> Sirp_: if the error messge is clear, set it to 30mb and see if people complain
[So Feb 22 2009] [23:11:26] <Sirp_> remember when in memory, a 20MB saved game could take 80MB of RAM
[So Feb 22 2009] [23:11:47] <Sirp_> boucman: I'll increase it to 40MB
[So Feb 22 2009] [23:12:07] <Sirp_> someone really wanting to do a DoS could of course just start 10 such games....
[So Feb 22 2009] [23:12:42] <Sirp_> hmmm I wonder if we should consider a mechanism where if the server starts to run out of memory it begins killing off the largest games
[So Feb 22 2009] [23:13:06] <boucman> Sirp_: not for 1.6, that's for sure :P
[So Feb 22 2009] [23:13:21] <Sirp_> boucman: well we change the server 'on the fly'
[So Feb 22 2009] [23:13:26] <Soliton> server improvements aren't really bound to release schedules.
[So Feb 22 2009] [23:13:43] <Soliton> Sirp_: just tested and a big save i have uncompresses to ~30MB.
[So Feb 22 2009] [23:13:57] <Soliton> so 40MB sounds good.
[So Feb 22 2009] [23:13:59] <Sirp_> Soliton: okay, well I'm setting it to a 40MB limit.
[So Feb 22 2009] [23:14:42] <Soliton> Sirp_: give an error to the uploader if possible. :-)
[So Feb 22 2009] [23:15:41] <Mordante> we should look at the uncompressed size, in dfranke's original report he manged a factor 1024 compression factor
[So Feb 22 2009] [23:15:53] <Mordante> using /dev/zero as input
[So Feb 22 2009] [23:16:09] <Soliton> yeah, that's the plan it seems.
[So Feb 22 2009] [23:16:15] <Sirp_> Soliton: yeah they'll get an error message.
[So Feb 22 2009] [23:16:39] <Sirp_> Invalid WML received: WML document exceeds 40MB limit
[So Feb 22 2009] [23:16:43] <Soliton> Sirp_: great. then we'll easily hear if anyone ever reaches that limit.
[So Feb 22 2009] [23:18:00] <Sirp_> of course, if someone was sufficiently malicious, they could make a text WML document of 40MB takes up perhaps close to a gigabyte of memory
[So Feb 22 2009] [23:19:08] <Sirp_> indeed, I hate to think how much this 30MB save takes up in memory
[So Feb 22 2009] [23:19:14] <Sirp_> how much memory does Wesnoth take if it loads this 30MB save??
[So Feb 22 2009] [23:19:36] <Soliton> let me test it is quite much indeed.
[So Feb 22 2009] [23:20:20] <Soliton> i think it was more than 500MB.
[So Feb 22 2009] [23:20:55] * Soliton watches the memory display flash a warning. :-)
[So Feb 22 2009] [23:21:56] <Soliton> memory consumption went from ~10% to 67% of my 1GB.
[So Feb 22 2009] [23:22:22] <dfranke> note also https://gna.org/bugs/index.php?13044
[So Feb 22 2009] [23:22:34] <dfranke> this problem probably isn't limited to building the cache.
[So Feb 22 2009] [23:22:41] <dfranke> probably applies to WML parsing in general.

Nils Kneuper <ivanovic>
Project Administrator
Sun 22 Feb 2009 01:09:11 PM UTC, comment #1:

CVE-2009-0366 got assigned to this issue and should be mentioned when sending out notices as reference

Gerfried Fuchs <rhonda>
Project Member
Sat 21 Feb 2009 10:39:35 AM UTC, original submission:

The MP server (and probably the client and the campaign server as well, but I haven't checked) uncompresses incoming messages from clients in their entirety immediately upon receiving them. Gzip's compression format permits compressed data to expand to up to about 1000 times its original size. Therefore, a client can send a few megabytes of compressed data to the server, and the server will uncompress it into gigabytes, thus exhausting system memory and crashing the server.

I have a working exploit for this, which simply reads the contents of a compressed file and sends it to the server using network::send_raw_data(). The file was generated using

dd if=/dev/zero bs=1M count=20480 | gzip > evil.gz

, thus it is about 20MB in size and uncompresses to 20GB.

The exploit code is too crude to bother posting, but I'll clean it up upon request.

Daniel Franke <dfranke>
Project Member


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by ivanovic (Posted a comment)
  • -unavailable- added by rhonda (Posted a comment)
  • -unavailable- added by dfranke (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 16 Mar 2009 09:34:22 AM UTCivanovicOpen/ClosedOpen=>Closed
    Mon 16 Mar 2009 07:26:36 AM UTCdfrankeStatusReady For Test=>Fixed
    Tue 24 Feb 2009 10:33:08 AM UTCivanovicStatusNone=>Ready For Test
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup