This is a backport of a security relevant fix for RakNet, we discovered. The issue has already been fixed in SLikeNet 0.1.0 (see https://www.slikenet.com/).
We provide this backport for people who prefer to stick with the RakNet project and also in order to easier share this fix with other RakNet forks.
We could/did not calculate a CVSS score, since such score heavily depends on how exactly an application utilizes the Lobby2 Steam client. In usual cases (see details below), the issue should not raise an exploitable security vulnerability at all.
The security implications of the issue are very low in our opinion. An application is only susceptive to an exploit, if it uses the Lobby2 Steam client and detaches the client. Usually this should happen shortly before the application terminates and hence happens in a case where the application should no longer process any further input. Common practice would be to destroy the Steam client instance directly afterwards, which should usually result in a crash.
If an application detaches the Lobby2 Steam client while running and destroying the instance, it will however result in a dangling pointer being left behind with memory writes/reads occurring to the memory location (i.e. use after free). This in effect opens up different attack vectors.
This is a backport of a security relevant fix for RakNet, we discovered. The issue has already been fixed in SLikeNet 0.1.0 (see https://www.slikenet.com/). We provide this backport for people who prefer to stick with the RakNet project and also in order to easier share this fix with other RakNet forks.
We could/did not calculate a CVSS score, since such score heavily depends on how exactly an application utilizes the Lobby2 Steam client. In usual cases (see details below), the issue should not raise an exploitable security vulnerability at all.
The security implications of the issue are very low in our opinion. An application is only susceptive to an exploit, if it uses the Lobby2 Steam client and detaches the client. Usually this should happen shortly before the application terminates and hence happens in a case where the application should no longer process any further input. Common practice would be to destroy the Steam client instance directly afterwards, which should usually result in a crash. If an application detaches the Lobby2 Steam client while running and destroying the instance, it will however result in a dangling pointer being left behind with memory writes/reads occurring to the memory location (i.e. use after free). This in effect opens up different attack vectors.