Split reassembly is easily broken by an attacker. This is a critical problem for 0.13 (currently master), where Throwable
errors are no longer caught by the server.
Core vulnerability
It's assumed here that if we have & need X
split parts, we have all split parts in the range 0 ... X - 1
.
If this assumption is violated, RakLib will throw an unexpected exception and crash here.
All vulnerabilities listed below allow exploiting this vulnerability.
Exploitation methods
splitCount
reported by current packet != splitCount
reported by other packets
RakLib relies on the splitCount
reported by the current inbound split packet part to determine how many parts are required. If this count is smaller than what was reported by previous packets, the above problem comes into play and crashes the RakLib instance.
splitIndex
>= splitCount
Even assuming that the split count is always valid, a second vulnerability is exposed due to a missing check for splitIndex
being less than splitCount
.
An attacker could send split packet parts whose splitIndex
are larger than splitCount
, causing this condition to be met when not all indices between 0
and splitCount - 1
are present.
Impact
All servers are currently impacted by this bug, but it does not come into play unless exploited.
Split reassembly is easily broken by an attacker. This is a critical problem for 0.13 (currently master), where
Throwable
errors are no longer caught by the server.Core vulnerability
It's assumed here that if we have & need
X
split parts, we have all split parts in the range0 ... X - 1
.If this assumption is violated, RakLib will throw an unexpected exception and crash here.
All vulnerabilities listed below allow exploiting this vulnerability.
Exploitation methods
splitCount
reported by current packet !=splitCount
reported by other packetsRakLib relies on the
splitCount
reported by the current inbound split packet part to determine how many parts are required. If this count is smaller than what was reported by previous packets, the above problem comes into play and crashes the RakLib instance.splitIndex
>=splitCount
Even assuming that the split count is always valid, a second vulnerability is exposed due to a missing check for
splitIndex
being less thansplitCount
.An attacker could send split packet parts whose
splitIndex
are larger thansplitCount
, causing this condition to be met when not all indices between0
andsplitCount - 1
are present.Impact
All servers are currently impacted by this bug, but it does not come into play unless exploited.