Can Avast Update be infected with virus?

Avast Free Antivirus / Premium Security
1

In my periodic scan, console inform me this: file avast.int was infected with Win32:Harnig-OG [Trj] Trojan virus!!!
I can’t move or delete this file becouse Avast is using this file.

My questions is:
How can be Avast file be infected?
Is this file is included in daily update?
How can I clean or replace this infected file?
How dangerous is this virus?

Thanks in advance!

2

The file is not included in daily updates, it’s related to VRDB database.
Rarely, it can happen that information from an infected file is extracted in such a way that it’s later detected by avast! itself (in this database).
I’d suggest to let avast! delete it (use the option “Delete locked files after restart” in Delete dialog). The database will be regenerated next time VRDB is refreshed.

3

Thanks,

only one question still remain:

How dangerous is this virus?

4

There is no virus in this file - only a very small piece of it, certainly no dangerous.

Regarding the real Harnig-OG trojan… sorry, have no idea what does it do.

5

Hi Mladen :wink: Just in case you need a description of Win32:Harnig, you can get it here: http://www.viruslist.com/en/viruses/encyclopedia?virusid=39422.
BTW, maybe Polonus could give some additional help with it ???

6

Thanks, it’s help me a lot! :wink:

7

Igor, why isn’t the VRDB encrypted?

8

You’re wellcome :smiley:

9

Just my thoughts:

  • does it need to be encrypted (I don’t think so);
  • if it were encrypted I guess it would take longer (probably not much) to generate the VRDB and work with the avast.int file (it can be a very large file) checking for any potential repair;
  • encrypting it won’t stop it containing elements of an undetected infected file as outlined by Igor;
  • encrypting it would mean that it couldn’t be scanned and the user wouldn’t know about this possible problem (allowing fro the deletion of the suspect avast.int and start from scratch) where repair of a file might infect a file (though I would assume avast would check that).

So I personally don’t see any benefit in having it encrypted. What is it that you were hoping it would achieve by encrypting it (or was it just a general question) ?

10

Will avoid false positives and the user thinking avast installation is compromised…

Depends on how encryption is carried on. If a driver is loaded into memory, the encryption and decryption is on-the-fly. Try TrueCrypt for instance. You won’t see any delay in saving/opening any file. Of course, the drivers could be loaded only when VRDB is being processed (recovering or creating the VRDB).

Sure. It’s not the point. But it will avoid false positive detection of avast itself.

When the file is restored, avast Standard Shield should scan the file (on High sensitivity) or, at least, when executed (on Normal sensitivity and open/created/modified files checked). But I think avast routine of recovering - like when creating the VRDB - will scan the restored file.

I see lots…
Well, my question was short but I have thought much about that before asking Igor…

My first purpose: avoid false positives or even that file is detected by other antispyware and being removed, that will let the user without the possibility of using VRDB anyway.

11

I don’t believe it was a false positive in the true sense (very unusual yes, where we are talking of elements of an infected file in the avast.int file and not the actual infected file), as Igor mentions, otherwise why delete a false positive detection.

Your comment about another AV detecting this element in the avast.int is valid, but should it happen it is no worse than deletion and regeneration of the VRDB as suggested by Igor.

The same was true of say ashDisp.exe being deleted many times in the past by spysweeper, adwatch, teatimer, etc. we have to recover from these problems. If it is as you say it is a false positive, why worry about another AV detecting and avast false positive, un less of course it isn’t a false positive, but the correct detection of a virus signature contained in the avast.int.

I’m just playing devils advocate here, as I really don’t believe it is that much of a problem.

12

Igor, uh uh…

13

Bump ::slight_smile:

14

Well, it’s not, because nobody implemented it that way :wink:
The possibility of extracting a snippet that would subsequently be detected probably wasn’t considered… and I’m not sure if it’s worth changing it now (there would have to be some conversion process for existing VRDB files that would launch during the update), given the chance this problem occurs…
Might be easier to include this file into avast! exclusions by default, but… it would have to be on-demand scanner exclusions, which don’t have any default items right now… maybe it wouldn’t be that easy either.

15

Don’t you like challenges? ???