I think there might be a misunderstanding here of how the sim installation system and sandbox works.
The sim does not install any DLLs or background executables onto your system when a Marketplace package is installed, and in fact it doesn’t run a Windows Installer (MSI, WIZ, CAB, EXE, etc) at all. For all Marketplace packages, there is not any code (nor can there be any code, definitively) that is executed by the system. Instead, there are two possible sandbox technology stacks.
One is a runtime interpreted code system (JavaScript), and as in all other browser based JavaScript environments, it has no access to your system. The reason it does not and it is impossible for it to be hacked or modified in such a way to be made able to, is because JavaScript does not even have any system level APIs. The language itself has no way to call into the system: it cannot directly access memory, it cannot read or write files, it cannot access system resources or drivers. On top of these language constraints, the code is not executed by the system itself (it is not its own process), it is instead executed by MSFS at run time, inside the sandbox.
Similarly, the second available technology stack is WebAssembly by way of the C++ language. WebAssembly similarly is without system level interfaces, and there is no way to directly access system resources, like file I/O, process memory, GPU, etc. No matter how ingenious an attacker, because these interfaces simply do not exist, there are no possible attack vectors here. Additionally, just like the previous tech stack described, this WebAssembly code is not a separate process executed by the system: it is code called only by MSFS at run time, in the sandbox.
In your opinion, how should this duality be handled from a code perspective? What prevents someone from taking the contents of a payware package, then repackaging it self signed as freeware? How would MSFS know which packages are allowed to be self-signed, and which ones are not?
From a purely technical perspective, this is actually an extremely dangerous use of a certificate chain, and the certificate chain will not validate and produce the mandatory public keys being requested with an expired certificate in the signing chain. Of course, you can override this, but this allows attackers to use expired certificates for valid certificate authorities they may have obtained illegally, and leaves it impossible to detect if a certificate chain is “validly expired” (the time stamp idea proposed) or “invalidly expired” (an attack).
Given the already secure environment in which a Marketplace package exists and are executed, I think this is the root of @EPellissier’s question. What security benefits can be derived from the proposed signing scheme and what attack vectors are being prevented?
-Matt
