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...

<closed>

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:
http://svn.gna.org/viewcvs/wesnoth?rev=33069&view=rev

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):
   
   
Comment:
   

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.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    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
      PrivacyPrivate=>Public
    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