DevHC's "fs_overpath" Feature Discussion


#1

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
#2

fs_overpath did not solve this problem, but thanks.


#3

WRONG.


#4

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


#5

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.


#6

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.


#7

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

		if(overpath[0])
		{
			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);
		}
		else
			dllhandle = NULL;

		if(!dllhandle)
			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.


#8

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.


#9

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.

^fixed.