Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: chief1983 on August 24, 2010, 10:12:15 am
-
The link (http://www.computerworld.com/s/article/9181479/Microsoft_won_t_patch_critical_DLL_loading_bugs?source=CTWNLE_nlt_pm_2010-08-23)
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.
-
The link (http://www.computerworld.com/s/article/9181479/Microsoft_won_t_patch_critical_DLL_loading_bugs?source=CTWNLE_nlt_pm_2010-08-23)
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).
-
And we would still be vulnerable, because we can't sign every dll loaded by FSO. The GPU driver and OpenAL, not to mention the system libraries, are beyond our control.
As I understand it, this exploit can be activated by malware in the user's $PATH, and I'd have to agree with Iss that any attack that has that as a precondition is very much a social engineering problem.