A 'desktop.ini' file can be used to track when a user visits a directory, similar to how 'web bugs' can track when a user opens an email. In the worst case, it can cause a leak of the username and HTLM hash of password of the account in use.
I tested that this can really be done with a zip generated by this page:
One of the pages above talks about using LNK and SCF to target Chrome. I did not test if these files can also cause leaks under Explorer or Opus, but it is worthy investigating later.
Similar to how email clients block requests to remote resources to prevent tracking, given the reports that Microsoft seems not interested in doing much about this, maybe Opus could do something about it?
Initially I considered that not extracting the bugs from compressed files would be enough, but 'desktop.ini' files do not always come from zips, so the safest way to handle them seems to be to not load them.
Could Opus be made to ignore 'desktop.ini' below certain user-specified locations (e.g. download folders)? (As in, is it technically feasible?)
If yes, could this be added to the feature request list?
I think in most cases it will not be Opus itself that parses desktop.ini,
e.g. if it's a folder icon, we just ask Windows for that folder's icon, and Windows is what looks in desktop.ini for other details. You could turn on generic icons to prevent that, but then things look very plain, with important visual cues lost, and most people would not want that.
It seems something that can only realistically be addressed by Windows/Microsoft, or by antivirus tools which check the desktop.ini contents and block access to them if they look wrong. (How to detect what is and isn't wrong would be quite complicated, I imagine, but that's another issue on top of this. It'd still have to be done by the thing that is actually parsing the files.)
It might make sense for Opus to warn you if you extract an archive with a desktop.ini in it, but that could also become annoying for people who do that a lot, which isn't that unlikely if they frequently zip up certain folders. And that would obviously not help when using archives extracted by anything else. Something more central like the OS itself or antivirus again makes more sense here, but I don't know if this is something antivirus already covers or not.
Now I wonder if using a script for the OnBeforeFolderChange event could be an alternative way to disable the 'desktop.ini' files. As long as manipulating the file system with scripting do not trigger the icon request, then it should work. I will investigate this further later.
Interesting read. It does seem like something the OS should do with virus protection. Just because you block it with Dopus won't stop explorer or dialogs. The odds are if its on your system it would still get triggered. Also be good to block SMB requests on your router.
This could be made less anoying by checking the IconFile path. The article talks about icon paths of IconFile=\\170.170.170.170\icon. Dopus could warn only when the IP is outside of the standard private networks.
That would be too late, if you extracted a zip into a folder and there was a desktop.ini directly below it. The desktop.ini would already have been read to get the folder's icon.
Most people have no need to do SMB over the internet, so blocking it at the router level is sensible and seems to solve the problem, unless you're also worried about it over a LAN.
Done already. That covers the security front, as the password hash won't leak. There is still the privacy issue, as DNS requests still leak and this seems harder to prevent.
Yep. Compressed files would have to be handled in another way.
The zip generated by the CanaryTokens passed VirusTotal tests without being detected by 59 engines. The antivirus companies seem to not care as much as Microsoft.