There is a known trick to bypass DropMyRights - using a network share on loop-back interface, e.g:
ren \\localhost\c$\windows\system32\malware.exe cmd.exe
That is limitation of remote impersonation. DropMyRights creates a restricted token which cannot be impersonated on remote server. Process tokens content is irrelevant and a user logon session is used to create impersonated token on remote machine. Normally a process with restricted token cannot access network shares, but it is still possible for some types of restricted tokens as shown by DropMyRights example. Additionally, there are other weaknesses of Windows Access Control and impersonation model, which we noted in the article and advisory.
GeSWall is not vulnerable to the trick, as an isolated application cannot access network shares by default. GeSWall denies it by restricting access to corresponding named pipes:
iexplore.exe READONLY access to \\127.0.0.1\IPC$\srvsvc (File)
iexplore.exe READONLY access to \Device\NamedPipe\wkssvc (File)
An access can be granted by additional application rules for these resources:
\Device\NamedPipe\wkssvc
\\ServerName\
Note Windows Vista has the same limitation for restricted tokens as well. However DropMyRights is superseded there by integrity levels. Integrity levels had similar loop-back interface vulnerability in the betas of Windows Vista. The vulnerability allowed privilege elevation from low integrity level (protected mode). Actually this particular issue with integrity levels is fixed but still there are weak points which could lead to privilege elevation, e.g: protected mode’s MIC brokers, virtualized files shared among all processes, etc. We’ll post more info on this.