d34d10cc
commented
3 weeks ago By the way, for any users of SBRW who find their way to this issue, if you want to remove the CA certificate from your OS trust store you should (Windows 10, at least):
- Open "Manage computer certificates" from the start menu, or run (Win + R)
certlm.msc. - In the window that opens, expand "Trusted Root Certification Authorities" then click on "Certificates".
- In the list, find "Carbon Crew CA", right click on its entry and click "Delete" (and confirm).
I have done this, and I genuinely recommend everyone to do this out of an abundance of caution. Furthermore, it's important to note that when next starting the SBRW launcher it will just download and install the certificate again, so either do not use the SBRW launcher until this matter is resolved or, if you're fine with the risk, delete the certificate as soon as the launcher fully opens or after you are done playing SBRW.
Hello, I've noticed that the launcher installs a custom Root CA certificate onto my machine. After checking the code, it seems that this certificate is used for Authenticode verification of the validity of the signatures of automatically downloaded launcher executables.
I believe I do not need to expound the security implications of this too much to an audience of software developers, but for the sake of thoroughness, with the installation of the "Carbon Crew" CA certificate as a trusted Root CA, users of this launcher automatically become liable to having ALL their encrypted communications with any website or service eavesdropped on.
To clarify, this would require whomever possesses the private keys for the CA to sign fraudulent certificates for whatever service they want to intercept your communications with and then MITM your communications with the service. I have no evidence that either of these things have been happening or will happen and I genuinely do not want to accuse anyone of anything at this point.
However, even if this is in fact a well-intentioned bad execution of the code signature verification idea and not malicious in any way, it is still a pretty egregious security issue for the users of SBRW. For what it's worth, also consider the case wherein the private keys for the CA are stolen in some way from whomever currently has them.
I also want to note that the certificate has a highly inappropriate and unnecessarily broad list of key usage IDs included, of which I would assume that no more than two or three are necessary for the advertised function of this certificate. The complete list follows:
List
``` Server Authentication (1.3.6.1.5.5.7.3.1) Client Authentication (1.3.6.1.5.5.7.3.2) Code Signing (1.3.6.1.5.5.7.3.3) Secure Email (1.3.6.1.5.5.7.3.4) Time Stamping (1.3.6.1.5.5.7.3.8) Unknown Key Usage (1.3.6.1.4.1.311.2.1.21) Unknown Key Usage (1.3.6.1.4.1.311.2.1.22) Microsoft Trust List Signing (1.3.6.1.4.1.311.10.3.1) Unknown Key Usage (1.3.6.1.4.1.311.10.3.3) Encrypting File System (1.3.6.1.4.1.311.10.3.4) Unknown Key Usage (2.16.840.1.113730.4.1) File Recovery (1.3.6.1.4.1.311.10.3.4.1) IP security end system (1.3.6.1.5.5.7.3.5) IP security tunnel termination (1.3.6.1.5.5.7.3.6) IP security user (1.3.6.1.5.5.7.3.7) IP security IKE intermediate (1.3.6.1.5.5.8.2.2) Smart Card Logon (1.3.6.1.4.1.311.20.2.2) OCSP Signing (1.3.6.1.5.5.7.3.9) Unknown Key Usage (1.3.6.1.5.5.7.3.13) Unknown Key Usage (1.3.6.1.5.5.7.3.14) KDC Authentication (1.3.6.1.5.2.3.5) ```Furthermore, the existence of such a "feature" has not been communicated nearly as transparently as something like this would require IMO, and a short note in the README of this repository is really not enough.
As for remediation, I understand that this kind of scheme was most likely devised in order to avoid paying for a code signing certificate from an actual CA, but if one wants to provide this kind of functionality, it seems pretty hard to avoid or else you get issues like this. Practically, I see a couple of ways forward, with the goodwill of the maintainers of the project:
Obtain an actual code signing certificate, such as one from Certum (cheapest option AFAICS); this option does require yearly renewals and also a one-time expense for one of their smart cards and a smart card reader. It also requires someone in charge of the project to leave their personal details with Certum and make them public through the certificate. I recognize that both the cost of this solution and the necessity of exposing personal details may be undesirable to the project maintainers.
An alternative such as sigstore. I did not delve too deep into sigstore or how it would integrate with a project such as this one, so I cannot advise further.
Integrate something like μthenticode instead of the current verification flow (p/invoke with built-in Windows APIs). From what I can see, μthenticode can only verify that signatures exist in the PE assembly and that the hashes match, but not the actual chain of trust. This would have to be custom-built it seems, in this variant.
The rationale behind including this option (and, really, any option that involves bypassing the built-in Windows trust APIs) is that in that case, the CA certificate wouldn't need to be installed in the OS trust store, rather downloaded by the launcher at the time it needs to verify signatures and the verification code would use the downloaded certificate. I understand this may seem somewhat unintuitive at first glance, but the current code already downloads the certificate from a hardcoded URL every time it finds that it is missing from the OS trust store.
Completely remove the functionality of verifying code signatures for the launcher. This might not reduce the security of the update process a whole lot as the whole scheme is already full of holes from a cursory glance at the code. Namely, the signature of the launcher executable is verified, but the launcher updater executable is just downloaded if it is updated, without any kind of signature verification. Apparently in the case of the launcher GitHub releases are considered an insecure and manipulatable download destination to the point that it warrants code signature verification, but in the case of the launcher updater they are not.
Furthermore, the CA certificate itself is hosted at
http://crl.carboncrew.organd I cannot say I see much care taken there either to ensure that the actual certificate that is downloaded is the intended certificate. There is some infrastructure in place such as CRL distribution and similar, but I am not in a position to say whether that does more good than harm.As a last resort, I suppose it would be marginally better if the code installed then removed the CA certificate from the OS trust store immediately upon verifying the needed code signature, as this, paired with the open-source nature with the codebase, could at least alleviate some concerns. This would require the certificate to be redownloaded every time the signature verification is ran, but is better than nothing.
Lastly, if I have fundamentally misunderstood anything in the code or in the way things are handled in general, please do let me know. I tried to verify whether the certificate perhaps serves another purpose as well; given the unique nature of SBRW, I assumed that maybe it was necessary to somehow emulate what NFSW used to do, however, that does not seem to be the case.
Even if that is true, the practice of adding a trusted Root CA in such an untransparent manner, without consulting the user, or really just in general, is a real breach of security principles and needs to be effectively communicated at the very least, with all its implications, if not immediately remedied.