Flaw by design?

[ståhl]

Hi

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

Regards
Daniel Ståhl
Bredbandsbolaget/Fegis.nu KGA BF administrator