DevHC's "fs_overpath" Feature Discussion


that is exactly why i implemented the fs_overpath feature. it defends against the above and similar attacks. BUTT @blowFish took a shit on the feature, and removed it — 1.3 is AWESOME(TM)(R)(C).1 now, u'd think @blowFish'd learn, but i guess not, and the feature won't be re-added.

in the update, a concrete attack path has been fixed. yet i still conceptualize a similar, concrete attack being possible.

1 NOT2
2 actually, there's no 1.3 to speak about yet.

Tremulous v1.3.0-alpha.0.4 Includes an Important Vulnerability Fix

fs_overpath did not solve this problem, but thanks.




fs_overpath did nothing to prevent how dll's opened. Feel free to elaborate on why I'm wrong however.


WRONG. by definition,

thus, when fs_overpath is set to a location not matching fs_homepath, then the engine won't try to load downloaded pk3 files as libraries, because they're not downloaded into the fs_overpath location.


Clearly this discussion is going to be about another fix (and similar vulnerabilities?), rather than the one implemented into 1.3. Therefore it was moved accordingly, kthx.


void *Sys_LoadDll(const char *name, qboolean useSystemLib)
	void *dllhandle;
		Com_Printf("Trying to load \"%s\"...\n", name);
	if(!useSystemLib || !(dllhandle = Sys_LoadLibrary(name)))
		const char *overpath = Cvar_VariableString("fs_overpath");

			char libPath[MAX_OSPATH];
			Com_Printf("Trying to load \"%s\" from \"%s\"...\n", name, overpath);
			Com_sprintf(libPath, sizeof(libPath), "%s%c%s", overpath, PATH_SEP, name);
			dllhandle = Sys_LoadLibrary(libPath);
			dllhandle = NULL;

			Com_Printf("Loading \"%s\" failed\n", name);
	return dllhandle;

Here's your code, tell me how it's any more secure in any way.

Note here, all you've got here is an additional directory traversal added to the original bug.


oh shit, now that i actually looked into the exploit, i just realized that fs_overpath actually didn't help, and neither did the fix, ie., ioQuake 3 is still fucking broken, and notably in a way distinct from what i conceptualized before, so it's doubly broken.


it's more secure because it's more restrictive about where libraries r loaded from.

the more important part of the fs_overpath functionality is elsewhere, and actually defends against the conceptualized attack.