Memory Usage

[itman 1,659]

29 minutes ago, MMx said:

We've had a discussion with Microsoft regarding this. They believe that the memory and CPU usage reported here is adequate to the size of the revocation list that is being processed.

Is this still an issue? The large CRL cert. causing Eset memory spiking expired on Mar. 1. Was it renewed?

[MMx 28]

There's a CRL on the same URL with about the same size and a newer expiration date. Do you still experience the same issue?

[itman 1,659]

29 minutes ago, MMx said:

There's a CRL on the same URL with about the same size and a newer expiration date. Do you still experience the same issue?

OK. This means the issue will remain; at least for a while.

As far as I am concerned, it's N/A since I have disabled SSL/TLS protocol scanning for Firefox, the browser I use, and it will remain so. I will also note that since doing this, the large CRL download via Win crypto service no longer occurs at system startup time. Appears that Eset was triggering this if the CRL was previously used and it was refreshing the existing list.

[Purpleroses 21]

4 hours ago, MMx said:

I've identified some circumstances that were contributed to this problem. This will be solved in protoscan 1439. Unfortunately the problem might come back anyway since it's considered a normal behavior of Windows, although now it will be less likely.

 

What is protoscan 1439 and when will be resolved?

[New_Style_xd 69]

35 minutes ago, Purpleroses said:

O que é o protoscan 1439 e quando será resolvido?

I would do the same thing, because I looked here in the ESET modules it doesn't have that name.

[itman 1,659]

44 minutes ago, Purpleroses said:

What is protoscan 1439 and when will be resolved?

I believe this is the Cryptographic protocol support module or a component within that module.

[Peter Randziak 1,130]

Hello guys,

47 minutes ago, Purpleroses said:

What is protoscan 1439 and when will be resolved?

Protoscan is code name for Internet protection module.

The version 1439 carrying the workaround will be distributed via standard module updates, but it will take some time until it will be released for the general public...

Peter

[itman 1,659]

1 minute ago, Peter Randziak said:

Protoscan is code name for Internet protection module.

That makes sense since the current version is 1437.

[itman 1,659]

On 3/3/2022 at 8:27 AM, MMx said:

It's possible to apply this workaround manually. To do that create a DWORD registry value called CryptnetCachedOcspSwitchToCrlCount under HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ChainEngine\Config (you may need to create several missing path components) and set it to 1047 (the special meaning of this value is that it will be reverted to default when the product is uninstalled).

I have verified that the above works for any problematic link posted in this thread; no more ekrn.exe memory spiking. At least as far as Firefox goes.  In regards to Win 10 21H2, I had to add the ChainEngine key under HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ and the Config key under HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ChainEngine\ key.

I have also for the time being re-enabled SSL/TLS protocol scanning for Firefox. Why? Mozilla just pushed ver. 97.0.2 to patch two vulnerabilities that were being exploited. The problem is it appears they busted part of Google Safe Browsing protection. It is no longer detecting on any tests from https://www.wicar.org/test-malware.html .

Edited March 7, 2022 by itman

[New_Style_xd 69]

46 minutes ago, itman said:

I have verified that the above works for any problematic link posted in this thread; no more ekrn.exe memory spiking. At least as far as Firefox goes.  In regards to Win 10 21H2, I had to add the ChainEngine key under HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ and the Config key under HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\ChainEngine\ key.

I have also for the time being re-enabled SSL/TLS protocol scanning for Firefox. Why? Mozilla just pushed ver. 97.0.2 to patch two vulnerabilities that were being exploited. The problem is it appears they busted part of Google Safe Browsing protection. It is no longer detecting on any tests from https://www.wicar.org/test-malware.html .

Based on what you've commented, firefox is not that secure.
Google chrome shows to have better support in security.

[itman 1,659]

For those interested on what this reg.setting, CryptnetCachedOcspSwitchToCrlCount, does, here's an article on it: https://www.pkisolutions.com/ocsp-magic-number/ .

Edited March 7, 2022 by itman

[Maaza1 0]

Mine goes very high as well and I don't even have ekrn.exe. I'm at the point where I want to just uninstall eset forever. Why does it go so high when I'm idle as well. 

[Marcos 5,074]

4 hours ago, Maaza1 said:

Mine goes very high as well and I don't even have ekrn.exe. I'm at the point where I want to just uninstall eset forever. Why does it go so high when I'm idle as well. 

Are you able to reproduce it without launching a browser?

Please carry on as follows:
- enable memory tracing under Tools -> Diagnostics in the advanced setup and click OK
- enable advanced operating system logging under Tools -> Diagnostics in the advanced setup and click OK
- reproduce the higher memory consumption by ESET Service (ekrn.exe)
- disable logging
- after a while (e.g. 1 min) collect logs with ESET Log Collector and provide me with the generated archive for perusal

[itman 1,659]

7 hours ago, Marcos said:

Mine goes very high as well and I don't even have ekrn.exe.

Win Task Manager shows ekrn.exe as Eset Service.

I believe your current Eset Service memory consumption is not related to this issue. Mine previously never exceeded 250 MB. Do as @Marcos instructed previously as to collecting Eset logs.

[Maaza1 0]

19 hours ago, Marcos said:

Are you able to reproduce it without launching a browser?

Please carry on as follows:
- enable memory tracing under Tools -> Diagnostics in the advanced setup and click OK
- enable advanced operating system logging under Tools -> Diagnostics in the advanced setup and click OK
- reproduce the higher memory consumption by ESET Service (ekrn.exe)
- disable logging
- after a while (e.g. 1 min) collect logs with ESET Log Collector and provide me with the generated archive for perusal

tried to doing this. After clicking ok after turning those 2 on, the whole program just exited. Its not in the icon tray. and the it wont open up when I click the exe. Maybe it will reappear after I restart

[Maaza1 0]

20 hours ago, Marcos said:

Are you able to reproduce it without launching a browser?

Please carry on as follows:
- enable memory tracing under Tools -> Diagnostics in the advanced setup and click OK
- enable advanced operating system logging under Tools -> Diagnostics in the advanced setup and click OK
- reproduce the higher memory consumption by ESET Service (ekrn.exe)
- disable logging
- after a while (e.g. 1 min) collect logs with ESET Log Collector and provide me with the generated archive for perusal

 

50 minutes ago, Maaza1 said:

tried to doing this. After clicking ok after turning those 2 on, the whole program just exited. Its not in the icon tray. and the it wont open up when I click the exe. Maybe it will reappear after I restart

Ok so after restarting, eset came back. However, the memory went from 350mb to 30mb after restart, so Im unable to reproduce the problem right now

[itman 1,659]

11 hours ago, Maaza1 said:

so Im unable to reproduce the problem right now

Open a browser, Firefox preferred, and go to this web site: https://imgur.com/ . After accessing the web site, check if Eset Service memory increased.  The increase should be around 200 MB.

[Maaza1 0]

On 3/9/2022 at 7:51 AM, itman said:

Open a browser, Firefox preferred, and go to this web site: https://imgur.com/ . After accessing the web site, check if Eset Service memory increased.  The increase should be around 200 MB.

 

Oh wow after doing the test on firefox, it went from 67.9mb to 515.2mb.

[itman 1,659]

@MMx , you previously posted that the main reason for Eset SSL/TLS protocol scanning was to detect browser exploits. Appears there is an issue in that regard.

First, note I am using the latest ver. of Firefox running on Win 10 21H2. Eset SSL/TLS protocol scanning for Firefox is enabled. I have also deployed your recommended reg. patch although I don't believe it's related to this issue.

For verification of Eset's ability to detect browser exploits, I used CVE-2020-0601; the infamous "Curveball" ECC certificate issue noted here: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-0601 .

It so happens there is a test web site that will deploy this exploit: https://www.ssllabs.com:10446/ which I used for testing. Upon attempted access to this web site, Firefox blocked the access noting there was a certificate issue. If I overrode that warning, the web site displayed a page noting I had been exploited. Further confirmation is shown via Win Audit-CVE log entry:

Not a beep from Eset exploit protection in any form.

Edited March 10, 2022 by itman

[itman 1,659]

I performed the same above CVE-2020-0601 test using Eset's Banking & Payment Protection mode. Again, note that this vulnerability will allow an attacker to perform browser network traffic man-in-the-middle interception activities.

Unfortunately, the result was the same:

[itman 1,659]

My last test in regards to the CVE-2020-0601 vulnerability is something I have not so far disclosed. That is Firefox was never affected by this vulnerability as highlighted in the below screen shot:

With Eset SSL/TLS protocol scanning disabled, this was verified per below screen shot:

So there you have it. A POC showing that Eset SSL/TLS protocol scanning actually makes you vulnerable to browser exploits!

[Peter Randziak 1,130]

On 3/11/2022 at 8:37 PM, itman said:

So there you have it. A POC showing that Eset SSL/TLS protocol scanning actually makes you vulnerable to browser exploits!

Hello @itman with which version of Internet protection module were you performing the tests?

Can you please try it with Internet protection module1439, which is currently available for pre-release users?

Peter

M_PROTOSCN-203

[Peter Randziak 1,130]

Hello @itman,

it seems that the issue in your test is caused by the fact, that your Firefox has stored the exception for the testing website.

On the  screenshot provided, you can see the exclamation mark notifying of an issue.

I have SSL/TLS scanning enable and I got the access blocked to the testing site in Firefox.

Can you try to delete the exception for it, repeat the test and let us know how it went?

Peter

 

 

[itman 1,659]

1 hour ago, Peter Randziak said:

it seems that the issue in your test is caused by the fact, that your Firefox has stored the exception for the testing website.

Hum.... Here we go again.

I have created no exception for ssllabs.com web site.

1 hour ago, Peter Randziak said:

On the  screenshot provided, you can see the exclamation mark notifying of an issue.

I have SSL/TLS scanning enable and I got the access blocked to the testing site in Firefox.

As I originally posted, upon initial access to https://www.ssllabs.com:10446/ with Eset SSL/TLS protocol scanning enabled, the following will be displayed:

At this point, you have already been exploited. Immediately open Win Event logs and open the Warning log section. You will observe that an Audit_CVE log entry created relating to this activity noting an exploit attempt was made.

Next, note that the error code on the above screen shot shows "SEC_ERROR_UNKNOWN_ISSUER." This is a result of Eset's root CA certificate being used to decrypt and re-encrypt the network connection and doing so erroneously. Eset never detected the exploit attempt and the connection to the exploit web site only failed due to a glitch in Eset HTTPS scanning activities.

Again, refer to my previously posted screen shot posted here: https://forum.eset.com/topic/31282-memory-usage/?do=findComment&comment=148006  with Eset SSL/TLS protocol scanning disabled. As noted there, Firefox shows that a secure connection attempted failed completely. Again, open Win Event logs and open the Warning log section. You will observe that no Audit_CVE log entry related to this activity was created. This verifies no exploit attempt was made because Firefox was never vulnerable to this exploit.

Edited March 14, 2022 by itman

[Posolsvetla 15]

Hi

1 hour ago, itman said:

I have created no exception for ssllabs.com web site.

Well, you did, as you mentioned at Thursday at 10:17 PM (edited): "If I overrode that warning, the web site displayed a page noting I had been exploited."
Firefox remembers that exception and when further attempt to access the site in question is made, no warning is issued by Firefox.

1 hour ago, itman said:

At this point, you have already been exploited. Immediately open Win Event logs and open the Warning log section. You will observe that an Audit_CVE log entry created relating to this activity noting an exploit attempt was made.

No, you haven't. As stated in the Event log, "an attempt to exploit" has been made, but that does not mean it was successful. We perform the check for this vulnerability only after we call the Windows API function which causes the log to be created. That's the reason the log is present. AFAIK Chrome does this in the same order, so the log would be present as well. Unfortunately I cannot verify this myself atm. Firefox don't call that particular Windows API function, therefore the log is not present.

1 hour ago, itman said:

Next, note that the error code on the above screen shot shows "SEC_ERROR_UNKNOWN_ISSUER." This is a result of Eset's root CA certificate being used to decrypt and re-encrypt the network connection and doing so erroneously. Eset never detected the exploit attempt and the connection to the exploit web site only failed due to a glitch in Eset HTTPS scanning activities.

The shown error code is not the result of a glitch. It's the result of the exploit detected by us. In this particular case we use the same technique as for some other cases, e.g. when we detect the server certificate is selfsigned.

1 hour ago, itman said:

Firefox shows that a secure connection attempted failed completely.

I would agree here, that we should probably block the connection altogether, the same way as we do when a server certificate is revoked, so an user won't be able to create an exception in a browser (as you did) and proceed. We might do that in the future.