Flaw by design?
newiq at spray.se
Tue Feb 17 04:56:53 EST 2004
We seem to be having a problem with people who exploit our server farm.
What happens looks like a flaw by design. This has forced us to disable
mapvoting since it is not feasable to have it running. The reason I'm
posting here is because I know that Dice-employees read this list and
it's also meant to be a heads up to the other administrators out there.
This scenario has been tested by our head administrator with success:
Join a server first after a mapchange, do a mapvote before anyone joins
and voila, the server changes the map. This might seem harmless at
first, but if there is a malicious player out there with a fast computer
and a need for trouble he will render the server useless or in a state
so that it repeats the map of his preference all the time. This can also
be done by packetforging and faking a player on the server, but I don't
know how to reverse engineer the protocol so I won't try it myself. The
battlefield server doesn't seem to check if there are any other players
connected to enable mapvoting. The malicious player is in fact 100% if
he gets in first. So my suggestion is that Andreas talks with the
dev-team how to implement a check so that single players cannot vote
until a second player is connected. Then he will only have 50% and then
the problem can be easily fixed by setting the majority to 51%. Then
they would have to pair up to do the same thing. The alternative
solution is to redo the netcode in such a way that it does not reset the
connection at mapchange from a client to the server as this is how
battlefield seem to work at the moment ( This is only what I've heard
from another admin that did netstat -a on a gnu/linux-server while
changing maps ). Although this alternative is not as likely to happen.
I hope I get a quick reply. And any Dice-crew that wants to contact me
more discretely, feel free to do so. I won't bite o_O
Bredbandsbolaget/Fegis.nu KGA BF administrator
More information about the Bf1942