MD5 checking / matching

[wraithdu]

In light of the recent discussions regarding keyloggers and such, and Sandboxie's ability to reliably apply Closed*Path and Open*Path settings, I'd like to request again some kind of MD5 checking within Sandboxie.

I was trying to think about the smartest and easiest way to implement this. It should only need to be applied when Closed* or Open* statements are used in conjunction with specific processes or process groups. So I was thinking since the INI currently only uses process names, not full paths, it would be up to the user to optionally insert the correct MD5 (or the Sandboxie GUI when creating rules) into the INI. Format ideas -


ClosedFilePath=firefox.exe:MD5:xxxxxxxxxxxxxxxxxxxxxxxxxx,resource

ClosedFilePath=MD5:xxxxxxxxxxxxxxxxxxxxxxxx,resource

ProcessGroup=<restricted>,firefox.exe:MD5:xxxxxxxxxxxxxxxxxxx,Start.exe:MD5:xxxxxxxxxxxxxxxx,....

ProcessGroup=<restricted>,MD5:xxxxxxxxxxxxxxxxxxxxxxxx,MD5:xxxxxxxxxxxxxxxxxxxxxx,.....


I might lean towards the filename.exe:MD5:hash format though, since then Sandboxie could only conditionally check the MD5 if the file requesting access matches the filename (instead of checking every file regardless of filename). This should cut down on the number of hashes being checked and increase performance. Plus users would easily be able to identify what file a hash is referring to.

I'd really like to see this feature, cause then you'd stop hearing about how "well what if a malware is named firefox.exe or something". Plus it only hardens an already great security product. It makes ideas like blocking internet access (which is now more than just a tweak since it's been added to the GUI ==> feature), or blocking execution, foolproof. No more filename spoofing.

I'd like to add that I know you've stated you're only interested in Sandboxie doing what it was meant for, and that is keeping things in the sandbox. I'd argue that closing some security holes in this manner is related to that goal.

Thanks for considering.

[SnDPhoenix]

I don't really have much to add, just wanted to say, I second this idea!
It's been mentioned alot and I think it'd make Sandboxie that much more hardened against malware.

[tzuk]

wraithdu, your idea cannot stop a key-logger from injecting code into an already-running instance of the Web browser. It will also cause more problems than it's worth, as some people will use this feature to checksum Firefox, then upgrade Firefox, and then complain that suddenly the Web browser can't connect to the Web anymore.

If you think your idea is great then why don't you create a software that is focused on just that. Associate executable names with checksums, and block any executables that match the filename but not the checksum.

[wraithdu]

I wish I were that talented

The idea with regard to keyloggers is that you can create a box with a restricted process group associated with ClosedIpcPath=!<restricted>,* which would effectively prevent anything except what you allow from running (including any keyloggers). The MD5 checks make sure that a downloaded program can't impersonate a piece of the Sandboxie program or an allowed process by simply changing its name.

After thinking about it again, the MD5 for a process would only have to be calculated once when the program is started, then associated with the process's PID or open handle, or whatever. Then checks could be against that stored value.

As for program updates, I agree someone will do that. I don't think that's a reason to dismiss it as a bad idea though, people will be people.

And there are plenty of programs that can do this, but none that can work with sandboxie in the context of the sandbox, only system wide.

I can hope for someday

[tzuk]

The idea with regard to keyloggers is that you can create a box with a restricted process group associated with ClosedIpcPath=!<restricted>,* which would effectively prevent anything except what you allow from running (including any keyloggers). The MD5 checks make sure that a downloaded program can't impersonate a piece of the Sandboxie program or an allowed process by simply changing its name.

Then maybe this will help.

1. For any negated ClosedXxxPath settings, if the executable file for the program resides within the sandbox folder, Sandboxie ignores everything until the first comma.

2. You may also remember that Sandboxie ignores OpenFilePath settings when the executable file for the program resides within the sandbox folder. (But note that OpenPipePath is not treated in this way.)

These two checks combined will prevent a sandboxed malware from taking advantage of your settings, and there is no need for MD5 checks.

After thinking about it again, the MD5 for a process would only have to be calculated once when the program is started, then associated with the process's PID or open handle, or whatever. Then checks could be against that stored value.

You're right but it doesn't even matter. The malware can still inject its own code into a running instance of a program file that was checksummed when it started. Checksumming can't do anything about it.

[wraithdu]

1. For any negated ClosedXxxPath settings, if the executable file for the program resides within the sandbox folder, Sandboxie ignores everything until the first comma.

Ah, now that's interesting. So if I've got ClosedIpcPath=!<restricted>,* then anything downloaded into the sandbox will be prevented from running. Nice.

The malware can still inject its own code into a running instance of a program file that was checksummed when it started. Checksumming can't do anything about it.

I agree. The checksumming though was aimed more at execution prevention via the ClosedIpc/FilePath=!<>,*. However I can see how this is not necessarily needed with regard to the previously mentioned rule.