Real-time Archive Scanning Is Borked

[itman 1,659]

The below is a screen shot of eicar 2x .zipped files created from a Thunderbird e-mail attachment. Worse, I can open these files w/o a peep from Eset. At least, Eset still detects the inner archive file when manually extracted.

[NewbyUser 72]

Since the files are already downloaded onto your system it shouldn't be a factor, but can this be related to the certificates issue with FF? Mozilla seems to have trust issues with CA's lol. 

From their release history;

Thunderbird 68 distrusts most SSL/TLS certificates issued by the Certificate Authorities (CA) with the brand names Symantec, GeoTrust, RapidSSL and Thawte. Consequently, any SSL/TLS connections to servers using an affected certificate will fail. Affected servers must be updated to use a different certificate. If Thunderbird displays an error message which states that an additional policy constraint has failed, you should check if the server uses a certificate issued by one of the mentioned brands. Additional information on Mozilla's action is available at here.

[itman 1,659]

29 minutes ago, NewbyUser said:

Since the files are already downloaded onto your system it shouldn't be a factor, but can this be related to the certificates issue with FF? Mozilla seems to have trust issues with CA's lol. 

No.

To begin, Mozilla no longer actively supports Thunderbird. Been that way for some time.

Note that Thunderbird is an e-mail client; we're not talking about web mail here.

[NewbyUser 72]

13 minutes ago, itman said:

No.

To begin, Mozilla no longer actively supports Thunderbird. Been that way for some time.

Note that Thunderbird is an e-mail client; we're not talking about web mail here.

I'm aware it's an email client. And they do actively continue development. Their latest beta was released only 3 days ago. Although yes, the official "stable" release is only at 68.

 

These notes apply to Thunderbird version 76 beta 3 released April 29, 2020

 

https://www.thunderbird.net/en-US/thunderbird/76.0beta/releasenotes/

[itman 1,659]

21 minutes ago, NewbyUser said:

And they do actively continue development.

I didn't state that. I stated that Mozilla no longer supports Thunderbird: https://www.thunderbird.net/en-US/about/

[NewbyUser 72]

15 minutes ago, itman said:

I didn't state that. I stated that Mozilla no longer supports Thunderbird: https://www.thunderbird.net/en-US/about/

Agreed. But it's semantics. They're still advancing the product/project. Just taking the easy way out and keeping in a perpetual beta state. At any rate, none of this banter is addressing your issue. Sorry taking it off topic.

[Marcos 5,070]

Real-time protection has never scanned archives internally. Malicious files in archives are detected upon extraction.

[NewbyUser 72]

Then the certificate issue may be at play. Whichever protocol you're using, both IMAP and POP use SSL. Or at least should be if configured properly.

[itman 1,659]

6 hours ago, Marcos said:

Real-time protection has never scanned archives internally. Malicious files in archives are detected upon extraction.

Thanks. Didn't realize that one.

There still appears to be an issue with Eset SSL/TLS protocol scanning with attachments in T-Bird however. When I attach the eicar.com.txt file, Eset doesn't detect until I actually attempt to open the attachment. As I see it if Eset was indeed scanning incoming IMAPS e-mail, it should have detected the attachment as the e-mail was downloaded to T-Bird's local inbox file.

Eset's root certificate is in T-Bird's certificate store. In prior vers. of T-Bird as I recollect, it showed that Eset was the AV solution. In the most recent version, zip reference to Eset anywhere including about:config settings. Also when I examine T-bird run details in Process Explorer, I see no reference to Eset components such as an injected .dll or the like.

[itman 1,659]

1 hour ago, itman said:

7 hours ago, Marcos said:

Real-time protection has never scanned archives internally. Malicious files in archives are detected upon extraction.

Thanks. Didn't realize that one.

Not fully awake this morning when I made this reply.

@Marcos if Eset real-time scanning doesn't scan compresses archives, Eset really needs to update its GUI settings to reflect this. Those clearly indicate otherwise:

[Marcos 5,070]

This refers to self-extracting archives that can be enabled/disabled in the RTP setup. There is no setting for archives as you can see. Some SFX archives and installers can be scanned internally on create.

[itman 1,659]

10 minutes ago, Marcos said:

This refers to self-extracting archives that can be enabled/disabled in the RTP setup. Some SFX archives and installers can be scanned internally on create.

Then Eset needs to specify this in their online documentation:

Quote

Archive scan setup

Archive nesting level – Specifies the maximum depth of archive scanning. Default value: 10.

Maximum size of file in archive – This option allows you to specify the maximum file size for files contained in archives (when they are extracted) that are to be scanned. Default value: unlimited.

 

Also here:

Quote

Strict cleaning – The program will clean or delete all infected files. The only exceptions are the system files. If it is not possible to clean them, the user is prompted to select an action by a warning window.

Warning If an archive contains a file or files which are infected, there are two options for dealing with the archive. In standard mode (Normal cleaning), the whole archive would be deleted if all the files it contains are infected files. In Strict cleaning mode, the archive would be deleted if it contains at least one infected file, regardless of the status of the other files in the archive.

 

 

Edited May 3, 2020 by itman

[NewbyUser 72]

5 hours ago, Marcos said:

This refers to self-extracting archives that can be enabled/disabled in the RTP setup. There is no setting for archives as you can see. Some SFX archives and installers can be scanned internally on create.

So the setting in Additional Threatsense only comes into effect if runtime packers is turned on in the plain Threatsense settings?

[Marcos 5,070]

Additional TS parameters are independent of the "runtime packers" setting.

[NewbyUser 72]

26 minutes ago, Marcos said:

Additional TS parameters are independent of the "runtime packers" setting.

OK, so if threatsense parameters does NOT have runtime packers enabled, but additional threatsense parameters DOES, then newly created or modified packers WOULD be scanned? Whereas packers already on the system would NOT be? Do  I have that right?

[itman 1,659]

Proof that Eset not scanning Thunderbird e-mail received via IMAPS;

[Nightowl 202]

But I believe that ESET is supposed to scan attachments , no?

[Marcos 5,070]

In the screen shot above the eicar test string was in the email body. If you attach eicar.com, is it detected upon receipt?

[itman 1,659]

6 hours ago, Marcos said:

In the screen shot above the eicar test string was in the email body. If you attach eicar.com, is it detected upon receipt?

I can't test with the eicar.com file as an attachment because my IMAPS e-mail provider will auto delete any e-mail with an executable attachment including .com files.

As posted previously, I did test with an eicar.com.txt attachment downloaded previously from the eicar web site. Eset did not detect the attachment in Thunderbird until it attempted to open via notepad.exe. In other words, when it was copied to User\AppData\Local\Temp folder. Ditto for eicar .zip download, no Eset detection until attempted file saving.

Edited May 5, 2020 by itman

[itman 1,659]

@Marcos, additional proof Eset scanning Thunderbird IMAPS is not working is when Eset detects the local creation attempt of the e-mail attachment, the copy of the attachment in T-bird remains in place.

Another element here is my e-mail provider requires OAuth2 e-mail server verification and this is set accordingly in T-Bird. Since this is only used for logon/password verification as I understand it, can't see how this could affect Eset SSL/TLS protocol scanning.

Edited May 5, 2020 by itman

[itman 1,659]

@Marcos, looks like there is isn't a problem after all.

What I forgot is T-bird only has the cache download option for POPS traffic. Reviewing my Eset logs on IMAPS traffic, Eset is indeed detecting the various eicar files, excluding the 2x zipped one, upon creation of the .part file download in my User temp directory. The actually e-mail attachment is not being deleted since it never physically existed on my disk. 

Sorry for the confusion on this.