Advice Request COMODO blocks Windows Updates with error 0x80070005

[bazang]

I'm fairly sure that soon a Thread will arise showing that Helen used Comodo...

Probably will. Helen, after all, proved that she was stupid. Paris abducted her (a lie, she left with him because she was a cheater and betrayer), but she stayed. Then got Paris slain by Philoctetes. Then married Deiphobus, Paris' brother. And finally betrayed Deiphobus by going back to Menelaus.

Sure. That fits the profile of someone that uses Comodo.

 

[Andy Ful]

Regarding solutions 1 and 2 do they both work with CIS installed and not removing the "%windir%\*|" entry?

Yes, but this was tested only for Windows 25H2. With the default MD settings, some Windows updates were blocked even after disabling all Comodo shields.
I posted details in this thread.
The relationship with MD was also evident when updating Comodo Internet Security (MD is disabled due to the active Comodo antivirus module). In this case, the same updates were successful, except when disabling Comodo's antivirus module (MD was automatically enabled).

 

[Divine_Barakah]

The bot is actually right, that error is a permission issue, so either it's due to the fact I am using a local account in combination with COMODO blocking something.

However I tried to increase to admin the local account (keeping comodo installed) but updates fail anyway

But you said that removing Comodo allowed the updates to install so?

 

[rashmi]

But you said that removing Comodo allowed the updates to install so?

Only a handful have troubles with Comodo—guess that's what happens when you don't salute Melih's brilliance, cherish Comodo's charm, and adore the sweetest 242 million Comodo users—the firewall of fandom and HIPS of fate block your path and even Windows updates!

 

[Andy Ful]

Only a handful have troubles with Comodo—guess that's what happens when you don't salute Melih's brilliance, cherish Comodo's charm, and adore the sweetest 242 million Comodo users—the firewall of fandom and HIPS of fate block your path and even Windows updates!

Yes, the problems with Windows Updates can also happen without Comodo. It would be hard to confirm that Comodo is often the main issue. The problem is that Windows Updates have some bugs that are mainly invisible on standard machines, but can impact non-standard (hardware or software) configurations.
However, it is interesting that Windows Updates seem to work differently when some Comodo HIPS settings are changed, despite the fact that HIPS was already disabled. It can be a bug or intended behavior - this should be clarified by the Comodo staff.

Edit.
Anyway, removing the HIPS rule %windir%\*| should solve many possible issues with Windows Updates.

 

[Pico]

Anyway, removing the HIPS rule %windir%\*| should solve many possible issues with Windows Updates.

Don't remove that rule permanently, it makes the system vulnerable.

 

[Andy Ful]

Don't remove that rule permanently, it makes the system vulnerable.

Why? Do Comodo staff say so? (did anyone ask?)
This rule provides only very limited protection of the Windows folder. The privileged process can bypass this rule in many ways.

 

[Pico]

Why? Do Comodo staff say so? (did anyone ask?)
This rule provides only very limited protection of the Windows folder. The privileged process can bypass this rule in many ways.

Which process do you mean with "The privileged process can bypass this rule in many ways."?

 

[Andy Ful]

Which process do you mean with "The privileged process can bypass this rule in many ways."?

Administrator rights and higher.
Although changing something in the "Windows\system32" folder requires higher than Administrator rights, the process that already has Administrator rights can easily get higher privileges, because UAC does not protect such elevations.

 

[Pico]

Administrator rights and higher.
Although changing something in the "Windows\system32" folder requires higher than Administrator rights, the process that already has Administrator rights can easily get higher privileges, because UAC does not protect such elevations.

Do you know that the rule also applies to apps running in containment for certain restriction levels?
Therefore removing that rule is not a wise thing to do.

 

[Andy Ful]

Do you know that the rule also applies to apps running in containment for certain restriction levels?
Therefore removing that rule is not a wise thing to do.

If the process is contained, it cannot change the content of %windir%.

Edit.
I skipped the rare possibility of sandbox escape.

 

[Pico]

If the process is contained, it cannot change the content of %windir%.

The special character | at the end of the rule makes this rule a containment rule needed when certain restriction levels are being set.
This rule is not a standard HIPS rule for normal untrusted apps but also applies to apps running in containment using certain restriction levels.

 

[Andy Ful]

The special character | at the end of the rule makes this rule a containment rule needed when certain restriction levels are being set.
This rule is not a standard HIPS rule for normal untrusted apps but also applies to apps running in containment using certain restriction levels.

It does not matter (for changes in %windir%), unless the process can escape from the sandbox.
It would be good if someone asked the Comodo staff.

 

[Pico]

It does not matter (for changes in %windir%), unless the process can escape from the sandbox.
It would be good if someone asked the Comodo staff.

Maybe not for changes in %windir% on the real system (did not test that, someone should check that!) but removing that rule will certainly allow restricted apps running in containment to have write access to (containted or not?) %windir% and running / doing stuff from there.

Almost anyone who uses CIS with CF settings have containment set to a certain restriction level, removing the rule will most likely have a bad impact on CF setting.

 

[Andy Ful]

Maybe not for changes in %windir% on the real system (did not test that, someone should check that!) but removing that rule will certainly allow restricted apps running in containment to have write access to (containted or not?) %windir% and running / doing stuff from there.

The contained process does not have write/modify access to the %windir% in the real system. It has access to virtualized %windir%.
No harm can be done, except when the process escapes from the sandbox.
So there is a main question for the Comodo staff: How can removing the HIPS rule %windir%\*| affect the possibility of sandbox escape?

Edit.
If I recall correctly, using the Restricted or Untrusted Restriction Level of containment can minimize this possibility.
I am not sure about the lower levels.

 

[Pico]

If I recall correctly, using the Restricted or Untrusted Restriction Level of containment can minimize this possibility.

Removing the rule increases the escape possibility for those restriction levels.

 

[rashmi]

Yes, the problems with Windows Updates can also happen without Comodo. It would be hard to confirm that Comodo is often the main issue. The problem is that Windows Updates have some bugs that are mainly invisible on standard machines, but can impact non-standard (hardware or software) configurations.
However, it is interesting that Windows Updates seem to work differently when some Comodo HIPS settings are changed, despite the fact that HIPS was already disabled. It can be a bug or intended behavior - this should be clarified by the Comodo staff.

Edit.
Anyway, removing the HIPS rule %windir%\*| should solve many possible issues with Windows Updates.

If I recall correctly, HIPS disabled still functions (in passive mode) for other modules as well, but I'm uncertain about the extent of its effectiveness. Could this be the reason for the difference...?

 

[Andy Ful]

If I recall correctly, HIPS disabled still functions (in passive mode) for other modules as well, but I'm uncertain about the extent of its effectiveness.

So do I.

Could this be the reason for the difference...?

Probably yes, but only Comodo staff can (or cannot) confirm how big the difference can be.
It is possible to test it, but it would require extensive testing. Maybe @cruelsister will test this someday.

 

[Pico]

If I recall correctly, HIPS disabled still functions (in passive mode) for other modules as well

Correct, rules ending with the special character | apply to containment module.

 

[Andy Ful]

I made a simple test.

1. Created a custom executable: test.exe (when run, it moves the file winhlp32.exe in %windir% to wiiinhlp32.exe). It used Trusted Installer privileges.
2. Firewall Security config (HIPS ON) ---> a few HIPS alerts, and when actions were allowed, the file was successfully moved.
3. Firewall Security config (HIPS OFF) ---> no HIPS alerts, and the file was successfully moved.

Next, I removed from the Firewall Security config the HIPS rule %windir%\*| and repeated the test:

1. HIPS ON ---> the last HIPS alert about modifying the file (winhlp32.exe) was missing (as compared to the previous test).
2. HIPS OFF ---> no HIPS alerts, and the file was successfully moved.

Conclusions.
When HIPS is OFF, the rule %windir%\*| does not protect against file modifications. It can probably be deleted as well.
When HIPS is ON, the rule %windir%\*| works as intended.
Despite the test above, the existence of the rule %windir%\*| can somewhat affect Windows Updates even when HIPS is OFF.