[crossfire] large numbers of parties causes weirdness

Mark Wedel mwedel at sonic.net
Thu Apr 28 01:32:23 CDT 2005


Brendan Lally wrote:
>
     
      Well, there was a mention of a security audit a while back, here's a result 
     
     >
     
      from it, and even a sample exploit code :)
     
     >
     
     
     >
     
      The party that a person is a member of is stored in a 'partyid' in the player 
     
     >
     
      struct. This is an sint16. each party gets an sint16 as the party number, and 
     
     >
     
      The following code, run as a script by a player is enough to cause breakages 
     
     >
     
      in the party system that crossfire uses.
     
     >
     
     
     >
     
      #!/bin/bash
     
     >
     
      for i in $(seq 1 1 65536); 
     
     >
     
      do
     
     >
     
      echo "issue 1 1 party form $i"
     
     >
     
      sleep 0.05
     
     >
     
      done
     
     >
     
     
     >
     
      there are three issues.
     
     >
     
      1) when it gets above about 1800 it causes clients to crash when doing party 
     
     >
     
      list. 
     
     
  IMO, that is the only one that really needs to be fixed - unless old parties 
are deleted, there will be problems, because the party list won't fit in the 
output buffer, and the server will close the connection to the client.

  If old parties are cleaned up, then wrapping could be pretty easily handled 
(add a little check that does handle the wrapping properly, and another little 
check to make sure the party number is unique).  If those two are done, then 
having party be in a 16 bit value (or probably even 8 bit) wouldn't be a problem.

  The right approach is to probably delete parties that don't have any members 
in them.  If everyone logs off, tough luck.  If I create a party and log off, 
that party shouldn't stick around for 2 weeks anyways.

  If a player saves and joins again, they have to rejoin the party - I don't 
consider that a big deal.  If the server crashes right now, all the party info 
is lost anyways.

  Adding a periodic call to do_specials to handle party cleanup is probably the 
easiest way to go.

  Also, if the player is a member of a party and tries to start a new one, 
should see if they are the sole member of the party they are currently in - if 
so, then delete it (thus to try and pollute the party listing, it would require 
a bunch of players all on at the same time).


    
    


More information about the crossfire mailing list