Nov 28, 2018, 01:36 PM
/drop exploit, a post-mortem.
How we were alerted.
I was bored and checking various automated systems, and comparing them against stored logs. The system had flagged up some suspect accounts, where there was a difference between the items spawned with / picked up / bought, and the items that they had in their inventory on the next spawn. Looking into this further, I saw masses of weapon drops, a single weapon being used, followed by an inventory manager transaction, a weapon /drop, and the weapons being picked back up. So myself and Nightmare hopped on staging, started testing, and I started looking through the inventory manager, item drop and weapon drop codes.
How did the exploit work?
The exploit worked by using the interaction between two unrelated systems, the inventory manager and the /drop command. When dropping weapons from the inventory, if you drop all the weapons in your inventory, you automatically de-equip the weapon you're holding too. The inventory manager doesn't do that, however. This meant you could have no weapons in your inventory, but still have one equipped in your hand. /drop didn't care about that, it would always create a weapon item anyway. So, as long as an exploiter had a friend they could get their other weapon back from, they could repeatdly do this (albiet only with single weapons, and each round could take up to 60 seconds).
However, the inventory manager was only a single method of being able to exploit this. Administrators could have used it by spawning weapons from the Q menu (though I found no evidence of this), or if players have had items removed with the item take command, this condition could also have been present.
Has it been fixed?
No, I'm telling everyone how to do it because I specifically didn't patch it. /s
Yeah, it's been pached. And the fix was Q/A'd. I'm shocked.
How was this fixed?
/drop was patched. If the player doesn't have any of the selected weapons in their inventory, /drop acts as /holster.
What have we learnt?
Well,
1. Old code doesn't always do what you expect it to do when you integrate it with new systems.
2. We should always check for edge cases, even when other systems should prevent those edge cases.
|
