Sc4pac hangs after installing an .exe with included dll's

[sebamarynissen]

I've noticed a rather weird issue when trying to add mgb204's Rail Depot Pack to sc4pac. After I installed it, I could no longer run sc4pac update, neither sc4pac list. The only way to resolve the issue was to empty my plugins folder, including the lockfile, and then install everything again with sc4pac update.

After looking into the rail depot pack, I noticed that it was an .exe installer that contained two dll's when unpacked: System.dll and nsDialogs.dll. I'm not sure what they are doing in the package, but I assume these are resources needed for the installer itself. After I added an exclude rule for the dll's in the package metadata, everything worked as normal again.

Not sure what the behavior of sc4pac here should be, as in a way it's the responsibility of the metadata author to ensure that only the required files end up in the user's Plugins folder. Nevertheless, I think that sc4pac might want to filter out these specific dll's System.dll and nsDialogs.dll, as those are names that probably won't ever be used for SC4 dll mods anyway.

[memo33]

For quite a while now, I've been considering to put more restrictions on the extraction of DLL files. It's inevitable in light of recent events. At a minimum, I'm going to require SHA256 hashes in the metadata for DLL files. I'm not sure about the syntax yet or whether it should be the hash of the zip archive or the DLL itself or both.

After I installed it, I could no longer run sc4pac update, neither sc4pac list. The only way to resolve the issue was to empty my plugins folder, including the lockfile, and then install everything again with sc4pac update.

Do you have more details about what exactly went wrong here? At no point should sc4pac execute code from a downloaded file, even if a DLL is installed into your plugins folder. As such, its functionality should not have been impacted.

[sebamarynissen]

With recent events you mean the vulnerability in Cities Skylines 2, right? I was thinking about this as well recently. The DLL mods are great and exciting of course, but there will come a point where someones puts malicious code in a DLL and tries to get users to download it. Obviously this is not just a problem for sc4pac, as you can download a dll from anywhere and put it in your plugins, but if sc4pac becomes the default way of installing mods then obviously anything helps here.

Just brainstorming here, but perhaps sc4pac could refuse to install dll's by default, unless specifically specified in the metadata inclusion patterns, and then when it detects dll's being installed, it can show a warning that this should only be done if you trust the creator.

Anyway, about this issue, I don't really have more details. The only thing I can think of is that I ran the sc4pac command from Windows cmd.exe inside the plugins folder. Perhaps that this causes Windows to load any dlls it finds here, but that would surprise me actually. I can see what it gives when running sc4pac outside the plugins folder. I'll report back here.

[memo33]

With recent events you mean the vulnerability in Cities Skylines 2, right?

Yes, CS2, as well as the NAM 48.1 debacle that unfolded overnight. So, it's already happened. Not as part of a game DLL, but as part of an installer, which has always been a potential threat really.

As sc4pac doesn't execute any installers, it eliminates a large part of the attack surface. Moreover, verifying file integrity is something where package managers generally shine, as opposed to manual installation methods. It just needs to be implemented.

Just brainstorming here, but perhaps sc4pac could refuse to install dll's by default, unless specifically specified in the metadata inclusion patterns,

Yes, as a first step I think this is a good idea. It would address the original issue reported here (although just superficially – not sure yet if there's a deeper problem). As for showing warnings, that sounds like a good idea, too, but the warnings have the potential of sounding rather scary, while end users can't really do anything to verify whether they can trust the DLL.

As I see it, there are three main attack vectors:

1. An asset uploaded to one of the exchanges is tampered with by someone other than the original author. Here, verifying hashes (or signatures) would help, as long as the hashes come from a trusted source like the main sc4pac channel. This would ensure that only the DLL files are installed that were available to the author of the package metadata.

2. A malicious file is uploaded to the exchanges by the original plugin author. This is much harder to avoid. Strategies like reproducible builds or compiling every DLL from source code myself could provide evidence that a DLL corresponds to a set of plain text source files. That's a lot of work though and would require support/cooperation from DLL authors.

3. Malicious metadata files. I'm not completely sure how this would be addressed. Reviewing changes carefully. Perhaps restricting where assets can be downloaded from. Or, like you suggested, it would probably be a good idea to show a note when a DLL was installed, including the following information: which package, where was the asset downloaded from and where is the metadata from.

[sebamarynissen]

Oof, I wasn't aware of that NAM 48.1 issue yet, and hurray, looks like I'm affected too. Haven't played SimCity 4 in a few years, picked it up again beginning of this month and download the NAM 48.1 -_-

Anyway, I didn't really think of it before, but you're right: those installers have always been a risk indeed, an using sc4pac here is indeed safer as it never runs the installers itself.

I agree with the warnings having the possibility to sound scary. It's going to require a careful balance I guess between reducing the attack surface and ux.