You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cyberboss opened this issue
Sep 20, 2018
· 0 comments
Labels
SecurityIssue pertaining to Authentication/Authorization or NTC (Never Trust the Client)V3Things labelled with this probably won't be fixed ever in suite version 3
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: 2894ea0#diff-0ba090ea7073a3a304dfdbdfc512f733
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: 2894ea0#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 1812a9c and versions 3.2.5.0+
The text was updated successfully, but these errors were encountered:
Cyberboss
added
Security
Issue pertaining to Authentication/Authorization or NTC (Never Trust the Client)
V3
Things labelled with this probably won't be fixed ever in suite version 3
labels
Sep 20, 2018
SecurityIssue pertaining to Authentication/Authorization or NTC (Never Trust the Client)V3Things labelled with this probably won't be fixed ever in suite version 3
Please refer to the GHSA here: GHSA-42r6-p4px-qvv6
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: 2894ea0#diff-0ba090ea7073a3a304dfdbdfc512f733
The bug was in this line: 2894ea0#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: 2894ea0#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.
CVE-2018-17107
This has been fixed in 1812a9c and versions 3.2.5.0+
The text was updated successfully, but these errors were encountered: