HIPS V1320-20180516 - all of a sudden content of field 'operation' always 'unknown operation'!

[mma64 7]

regarding all ESET versions (*), mine is ESS V10.1.235: HIPS V1320-20180516, which was installed on my PC on 29th May 2018, introduced yet another bug, as can be clearly seen in the attached screenshot. (Field 'operation' filled with 'unknown operation'  since then. Up to this version it contained the correct description, for example 'modify startup settings' / 'write to file' / 'delete file'...)

(*= ie. all versions that make use of HIPS V1320-20180516.)

(Besides: this is not the only HIPS bug, there exist two others which are far more worse than this one. One of which I already have reported, which is since HIPS V1317-20180417 even worser - more on that later. For this one I have a ridiculously easy triggering procedure now. With HIPS V1317 and HIPS V1320 it's consistently triggerable after each and every AV update!!! Before HIPS V1317 it was "limited" to an AV update with a HIPS module update...)

 

Edited May 30, 2018 by mma64

[itman 1,659]

I can confirm this behavior.

It started on my Eset installation, 11.1.54, on 5/29. In my case, I have a HIPS rule that allows svchost.exe to startup cmd.exe that I log. Prior to 5/29, the log always showed for operation - startup application. The log now shows unknown operation.

The main question is if existing user HIPS rules are functioning properly?

-EDIT- The only Eset module updated on 5/29 was the router vulnerability scanner.

Edited May 31, 2018 by itman

[persian-boy 22]

it's not new, i reported this issue 2 months ago.

Eset its time to fix bugs : D

[mma64 7]

2 hours ago, itman said:

The main question is if existing user HIPS rules are functioning properly?

yes, they do... (But read my private message please, the super bad bug I disclosed therein is now even worser - and ridiculously easy to reproduce since HIPS V1317-20180417. With your 'svchost.exe, start new app, cmd.exe' you're >50% or even >80% into my reproduction procedure, I could bet that it's triggerable even with your EIS V11.1.54!... Thank you very much.)

@persian-boy: (this) "unknown operation" is no severe bug. As the screenshot clearly shows introduced with HIPS V1320-20180516. And easy to fix.

 

Edited June 1, 2018 by mma64

[Marcos 5,070]

Those records are likely logged only if you have logging of all blocked operations enabled. It serves for troubleshooting HIPS-related issues and should remain otherwise disabled. Enabling it may cause performance issues and may unnecessarily waste disk space.

[mma64 7]

Thanks Marcos, but I'm sorry that you're wrong. Changing "logging all blocked operations" to disabled changes nothing - as I expected it in advance. Look more closely at the attached screenshot above: 21:58:49 (hh:mm:ss), the old HIPS V1317-20180417 is still active, and guess what, field operation filled with the correct action - "get access to file"! Now look at 21:59:21 plus the creation date of subdirectory '1529' (ask your developers what this means!), this is HIPS V1320-20180516, automatically downloaded and installed on 20180529 21:59:17! Since exactly this time field operation in HIPS log is always "unknown operation" (exporting the log - the very same thing, as expected) - hand this over to your developers please, they know 100% perfectly well why this happens, why it's a crystal clear new bug and what they should do now!...
 

[itman 1,659]

13 hours ago, persian-boy said:

it's not new, i reported this issue 2 months ago.

In your instance, you used the HIPS in Interactive mode I believe when the issue manifested.

I have always used Smart mode with a dozen or so user rules created. And, have never seen this HIPS behavior until recently.

[itman 1,659]

8 hours ago, Marcos said:

Those records are likely logged only if you have logging of all blocked operations enabled.

That HIPS setting is not enabled on my 11.1.54 installation.

Like I posted previously, I am seeing the same logged entries as previously created with the exception that log operation field now shows "unknown operation."

Edited June 1, 2018 by itman

[mma64 7]

@Marcos/ESET: as the screenshot of itman shows even EIS V11.1.54 fills the HIPS log since HIPS V1320-20180516 with the very same constant text "unknown operation" as it's the case with previous versions of your software. All HIPS logs using HIPS V1320 are filled over and over with "unknown operation" forever, ie. until ESET corrects this easy to fix bug.

Oh my, how much more proof does ESET need until they confirm this silly bug and fix it?!?

 

[itman 1,659]

Also as far as ver. 11.1.54 goes, the only modules that were updated on 5/29 when my HIPS logging issues started were:

• Router Vulnerability Scanner - ver. 1048
• Banking & Payment Protection - ver. 1132
• Script Scanner - ver. 1040

Up till 5/29, I was running with HIPS module 1320 w/o issues.

[itman 1,659]

FYI - there was just an update to em_018.dll about an hour and a half ago. Hopefully this is the fix.

[mma64 7]

42 minutes ago, itman said:

Also as far as ver. 11.1.54 goes, the only modules that were updated on 5/29 (...) Up till 5/29, I was running with HIPS module 1320 w/o issues.

How can you be so sure that only the modules you mentioned were updated on 05/29/2018?!? Are the updated modules logged since V11.x? If not one is forced to continually check this manually after each and every logged AV update...

Hardly I can believe that you're running with HIPS V1320-20180516 before 05/29/2018, which was installed on my PC on 05/29/2018 21:59:17 and definitely not a single second before that date (see my screenshot)!!! HIPS V1317-20180417 was installed on my PC on 05/08/2018 22:18:08 - and I'm starting my PC every day, thus you can see there is a significant amount of time passing by until a new HIPS module update reaches my PC...

46 minutes ago, itman said:

FYI - there was just an update to em_018.dll about an hour and a half ago. Hopefully this is the fix.

No update on my PC till now - but if em018_64.dll and/or em018k_64.dll (the HIPS module) were really modified on your PC then it's easy to look if this bug has been fixed: check your HIPS log after, for example, some 'cmd.exe' action...
 

[itman 1,659]

41 minutes ago, mma64 said:

No update on my PC till now - but if em018_64.dll and/or em018k_64.dll (the HIPS module) were really modified on your PC then it's easy to look if this bug has been fixed: check your HIPS log after, for example, some 'cmd.exe' action...

The HIPS rule is only triggered upon resume from sleep mode. I did that but still no change. However I suspect em018_64.dll is only loaded into ekrn.exe at boot time. So I will have to wait till tomorrow to verify. Also only em018_64.dll was updated; not em018k_64.dll. 

[Marcos 5,070]

I've filed a bug ticket for developers since the issue is easily reproducible.

[mma64 7]

2 hours ago, Marcos said:

I've filed a bug ticket for developers since the issue is easily reproducible.

Ahhh, finally the right decision.

This bug is of a low severity and easy to fix. But don't forget the other highly disastrous bug that I reported... Since HIPS V1317-20180417 (and HIPS V1320-20180516) consistently reproducible after each and every AV update! Now with a ridiculously easy procedure to trigger it. It will not get any easier than this - the gold chance for ESET to catch this super bad bug! A logging HIPS rule and a not at all "special" action is all that's needed to trigger it - precise details in the PM, please read and do it! This will take only 5 - 9 minutes (*) of your super precious time!!! (*=the actual test, reading the PM post may take an additional ~10 minutes...) 
 

[Peter Randziak 1,130]

Hello guys,

the issue is fixed in HIPS module 1321+, the module will be distributed automatically.

Thank you for reporting this to us.

Regards, P.R.

[mma64 7]

Well done, ESET. The "unknown operation" HIPS log bug has been fixed with HIPS V1322-20180613, rolled out ("to me") on 20180702, see the following screenshot: (1) PC is starting, wrong field content, (2) an AV update with (3) HIPS module update gets automatically installed at 22:36:27, (4) immediately (22:36:29) after that all HIPS log entries with correct field content (5) (6).

(Remains the question why the rollout to the ESET users takes a whopping ~19 days: V1322-20180613 <-> 20180702...)

 

[Marcos 5,070]

17 minutes ago, mma64 said:

Well done, ESET. The "unknown operation" HIPS log bug has been fixed with HIPS V1322-20180613, rolled out ("to me") on 20180702, see the following screenshot: (1) PC is starting, wrong field content, (2) an AV update with (3) HIPS module update gets automatically installed at 22:36:27, (4) immediately (22:36:29) after that all HIPS log entries with correct field content (5) (6).

(Remains the question why the rollout to the ESET users takes a whopping ~19 days: V1322-20180613 <-> 20180702...)

Since HIPS is a very sensitive module that may cause sever system issues if released with a serious bug, its releases are staggered and it may take up to one month until all users will receive the updated module.