Feature Request: option to ignore path on rule definition

[mkauf8]

issue
there are apps which update quite frequently and while doing so, creating a new directory for the new version instead of using the old one. this leads to a slightly different path (mostly only version number changed) while using the same executable name. Since the path changed, the rule created within tinywall does not match anymore and the app is going to be blocked. This means after every app-update I have to adjust the rule again within tinywall which is tedious.

solution proposal
add checkbox with the option to "ignore path" in the rule dialog so one can decide (and therefore accept the risks involved) to apply the rule only on the executable alone and adjust the rule evaluator accordingly.

examples of popular apps affected

• google drive
• cura slicer

[ninmba]

It happens with WhatsApp desktop version too.

[pylorak]

If the affected app is a Windows Store app (like WhatsApp Desktop for example seems to be) and if it is also a UWP app, be sure to unblock it as a UWP app in TinyWall instead of unblocking its executable. Then TinyWall will automatically pick up new versions even if the directory changes.

For non-UWP apps things look different. The main reason a feature like this didn't get implemented in TinyWall for non-UWP apps is because it is a serious security risk. Such programs that change their directories upon each minor update are typically installed in non-protected user folders. All a malware would need to do, is to copy itself to a directory that looks like a new version of your application, and it would automatically get unblocked without requiring admin privileges or your consent.

[mkauf8]

I understand what you're saying. But everything a user is configuring within an exception rule is adding to overwall risk by nature (if it is disabling access to hosts file or allowing an app to have public access, or even enabling learning mode, etc.) The question is, will you allow the user to make the decision what risk he is willing to accept for himself or do you dictate it by enforcing it trough the firewall app. I'd personally prefer the first option, since I'd like to be in control.

When a user allows an app in a non-protected folder, it would not be so hard for malware to replace those executables in an existing path as well, would it not?

Maybe one could mitigate the risks by

• defaulting the switch "ignore path" to "disabled"
• showing a security hint when enabling this switch to ensure risk awareness
• even increasing security for dedicated apps by adding another checkbox "check/lock version of executable" to filter exe-version and only allow original allowed versions
• if none of the above seem feasible, at least detect same exe blockings and show a friendly user dialog asking if he is willing to allow the new executable too

I really like the app and it's small footprint with a no-nonsense ui. Thank you for this piece of very usable software.

[pylorak]

It is true that there is a similar risk in theory with the malware replacing/modifying the installed application itself. Still, there are a few key differences and important notes here:

• Preventing applications in non-secure folders to get unblocked is not acceptable in practice. If we were to only allow whitelisting apps in Program Files (for example), the firewall would be basically unusable. So there is nothing we can do about this, we have no choice but to allow unblocking these apps. In contrast, we do have a real choice about automatically and silently whitelisting new apps in non-secure folders.
• Just because there is an attack surface that we cannot avoid, it does not justify to open up new security holes where we do have a choice, even if they pose a similar risk.
• If the malware modifies or replaces an installed application, its digital signature will be invalidated. This could be picked up by other security software, or if the software requires admin rights, the user will at least see the corrupted certificate at the next UAC prompt.
• And lastly. many of the applications are long-running. Browsers, Google Drive, WhatsApp, etc. These are usually started shortly after the computer boots (either manually or even automatically) and run until the computer is shut down. The executables of running processes cannot be modified (though this is really not hard to circumvent).

Increasing the security of installed apps by locking down their version is, unfortunately, not possible in TinyWall. This would only work if the firewall could verify the hash and/or version and/or (best option) signature upon each communication attempt of unblocked apps. This is something that's only possible from a kernel driver, and TinyWall doesn't have any.

I can understand giving users more choice and leaving the responsibility to them. But that is the hardest part of UI design for me: Deciding what choices to give to the user. As an example, you have no idea how many users (even those with supposedly IT-affinity) misuse the Autolearning mode, practically invalidating any effect of a firewall. This happens despite the unavoidable lengthy explanation dialog you get each time you activate Autolearn mode. I've long regretted adding Autolearn to TinyWall. It could have been a useful feature, but in reality I see users shooting themselves in the foot way too often with it.

Anyway, these are just my personal views. If anybody wants to tackle the feature in this ticket, I won't stand in the way. The only requirements I'll pose are that of implementation quality:

• Provide a way to define which parts of the path may be ignored (for example, by using wildcard characters)
• The feature has to work reliably even for apps already unblocked
• It has to work while TinyWall is already running (not just at startup)
• It has to work efficiently, e.g. without periodic polling/scanning (for example, use directory watchers etc.)
• Provide security clues to the user. At a minimum, warn them when enabling this feature. At best, warn them in a popup whenever a new app version gets automatically whitelisted.

I'll happily accept pull requests if they fulfill these criteria.

[PKav89]

The most annoying app related to this issue is Chrome Remote Desktop. When it updates you suddenly loose ability to connect to your remote PC. Of course, updates can be blocked, but it does not seem to be a good idea.

But Chrome Remote Desktop uses symlink "CurrentVersion", which points to current directory with latest "remoting_host.exe". TinyWall does not support such link and resolves path to real directory when trying to add "remoting_host.exe" via "CurrentVersion" symlink. Is it possible to fix somehow?

[coopfidgets]

Any update on path ignore (I'd rather have .exe's in a path instead of path as a malicious app could move a malicious .exe in an existing path)
Also can we add hash verification? If a .exe hash is changed then it should warn the user and prompt acceptance or something along those Ines

[pylorak]

As stated, I will accept PRs with this feature as long as it fulfills quality and efficiency constraints (see my comment above). I personally will not develop this feature however, not only because I find it gravely insecure, but I also don't currently see a way to do this well enough without a kernel driver. If you're a developer and you have an idea how this could work technically, I'm all ears.