Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-42r6-p4px-qvv6
No affected components available
Please note this advisory is for a historical preexisting issue in the legacy server from 2018. It has long since been triaged. It is being moved here for visibility. The text below is copied from the original issue #690
You can login to the server with any username/password combination if someone else is logged in
An explanation of the bug: Back in 3.2.1.0, in order to accommodate running the Control Panel using Mono some hooks were added to the WCF communication layer. Detailed in this commit: https://github.com/tgstation/tgstation-server/commit/2894ea03d708c7f16bab47ba5020c2ad4c3d5554#diff-0ba090ea7073a3a304dfdbdfc512f733
The bug was in this line: https://github.com/tgstation/tgstation-server/commit/2894ea03d708c7f16bab47ba5020c2ad4c3d5554#diff-0ba090ea7073a3a304dfdbdfc512f733R48 authPolicy is passed in by the framework but the documentation for what the parameter is is virtually non-existent: https://docs.microsoft.com/en-us/dotnet/api/system.servicemodel.serviceauthenticationmanager.authenticate?view=netframework-4.7.2#System_ServiceModel_ServiceAuthenticationManager_Authenticate_System_Collections_ObjectModel_ReadOnlyCollection_System_IdentityModel_Policy_IAuthorizationPolicy__System_Uri_System_ServiceModel_Channels_Message__
Turns out it is a cache of what the previously returned policy was, as Floyd thankfully found out for us. The security patch fixes the issue by creating a new empty list as the return value when password authentication fails as opposed to using the authPolicy parameter.
If you're wondering why this line: https://github.com/tgstation/tgstation-server/commit/2894ea03d708c7f16bab47ba5020c2ad4c3d5554#diff-0ba090ea7073a3a304dfdbdfc512f733R42 didn't prevent the issue. It only invalidated the actual Windows login session, but in the eyes of the server the user was still valid since we just passed that closed handle as a return result. Had access to static files been attempted with a bad login, the request would end up erroring due to trying to impersonate using a closed user token handle.
This has been fixed in 1812a9c6793c8516c138a105ccfb2108164f0eff and versions 3.2.5.0+
The vulnerability can be exploited over the network without needing physical access. It is difficult for an attacker to exploit this vulnerability and may require special conditions. An attacker does not need any special privileges or access rights. The attacker needs the user to perform some action, like clicking a link. The vulnerability can affect other systems as well, not just the initial system. There is a high impact on the confidentiality of the information. There is a high impact on the integrity of the data. There is a high impact on the availability of the system.
Exploitation activity has been observed. Apply available patches or mitigations urgently.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard