The link
Came across my *nix listserve oddly, and this one actually seemed worth pointing out here. Particularly, the line "crucial Windows functionality has been misused by countless developers" caught my eye. I hope we are not in that group.
We are vulnerable to the exploit (at least a far as I can tell) because while we only load dlls by name (OpenAL32, and the TrackIR dll). We are still vulnerable becuase we normally suggest that FSO based games are placed in user writable locations because of the cache, log, and pilot files that get written to the game data directory. Not that using a non-user writable location would likely help as, the entire premise of the exploit is social engineering anyway. Nevertheless, this allows someone malicious to put trick a user into putting a malicious .dll into the game folder.
In reading the article, the only way that we can avoid this issue (as far as I can tell, becuase they don't really say what the issue is,) is to sign all of our executable code and the dlls that we load and to only allow content that has that signature.
But our vulnerability actually goes further, because we will execute arbitrary lua code (with an unrestricted environment (ie. lua can write anywhere the user running FSO can)) we would have to sign our data files as well. Which brings us back the the discussion that we had (started by
portej05) many months ago about changing how the mod data is loaded to be by inclusion rather than by exclusion, which combined with data signing would make FSO much less vulnerable to exploit, especially for end users (as the devs would have to turn off the signature enforcement so that they could actually develop content).
