Impact
Specially crafted InventoryTransactionPackets sent by malicious clients were able to exploit the behaviour of InventoryTransaction->findResultItem() and cause it to take an abnormally long time to execute (causing an apparent server freeze).
The affected code is intended to compact conflicting InventoryActions which are in the same InventoryTransaction by flattening them into a single action. When multiple pathways to a result existed, the complexity of this flattening became exponential.
The problem was fixed by bailing when ambiguities are detected.
At the time of writing, this exploit is being used in the wild by attackers to deny service to servers.
Patches
Upgrade to 3.15.4 or newer.
Workarounds
No practical workarounds are possible, short of backporting the fix or implementing checks in a plugin listening to DataPacketReceiveEvent.
References
c368ebb
For more information
If you have any questions or comments about this advisory:
Impact
Specially crafted
InventoryTransactionPackets sent by malicious clients were able to exploit the behaviour ofInventoryTransaction->findResultItem()and cause it to take an abnormally long time to execute (causing an apparent server freeze).The affected code is intended to compact conflicting
InventoryActionswhich are in the sameInventoryTransactionby flattening them into a single action. When multiple pathways to a result existed, the complexity of this flattening became exponential.The problem was fixed by bailing when ambiguities are detected.
At the time of writing, this exploit is being used in the wild by attackers to deny service to servers.
Patches
Upgrade to 3.15.4 or newer.
Workarounds
No practical workarounds are possible, short of backporting the fix or implementing checks in a plugin listening to
DataPacketReceiveEvent.References
c368ebb
For more information
If you have any questions or comments about this advisory: