avast! Home Edition refuses to let me delete exclusions

You and Igor appear to be in much closer time zones than I am to you (it is 1.20 am here in California). I will leave you to chat with Igor and review the thread when I am around again and see what has transpired in the discussion.

Maybe it is time I got a USB drive.

Thanks for the tip, I’ll try it out. Still, I think this is an issue that warrants attention; I’d never have realized avast! re-added the exclusions by itself if I hadn’t renamed a few malware file extensions purely on a whim.

It depends on what you’re after. They’re just fairly standard Hupigon samples, with (I’d imagine) some tweaks to the code here and there, maybe an extra packer or two, and, of course, dropping fake .ini files (which were actually simply renamed executables) instead of .exe files as they used to do.

That wasn’t what I asked. You were the one who claimed never, and then threw out a challenge to me to prove you wrong. So go ahead. Try it. Walk the talk, like you claim you do. I’m waiting for your results.

A final couple of thoughts before I sleep.

This is a two way street, neither of us jumps to the others commands. I have made several offers to assist you to try to show me how the infection would get onto my system with avast up and running and where avast has the opportunity to scan the data being added to my system. You seem to have ignored my questions about whether you are relying solely on the ‘on access’ scanner as the only protection in avast and my comment about P2P scans.

Your point still appears to be that the infection must be deliberately introduced onto the system before avast can scan it.

It may well be that, in scanning the conversation, Igor may tell you that you have found a way round the defenses of avast. If he does then I need to perform no test. On the other hand, if later today the issue is still under discussion I will go ahead and test with your deliberate infection suggestion.

All I can say is, the one who’s trying to weasel around now looks very suspiciously to be you. :wink:

You claimed to be a man of action, yet for one who accused people of trying to weasel around you seem to be quite wordy and articulate now, and with precious little to be seen in terms of real action; none at all, in fact. So go ahead. Pretend that you believe the USB drive is malware-free, and stick it into your autorun-enabled computer, leaving avast! on all the time. Still waiting for your results here.

Result is : let’s take a walk Solcroft. You outsit too long in front of monitor and radiation etched your nerve cells maybe a second head starting grow up. (it could be serious u should do something with it) :-[

Hi solcroft,

thanks for reporting this - it’s indeed an interesting issue. Well in fact two issues. The first being the inability to prune the default exception list (of which we were sort of aware) and the second, more serious, the one with the “start” command being able to launch a file with arbitrary extension. This is indeed an oversight on our part, and should be fixed.

We’ll try to think of a viable solution for the next update.

Cheers
Vlk

Even though Vlk has noted the potential of this threat and the need for improved detection of it I thought I would still perform the test.

While I was drifting off to sleep it occurred to me that this threat must have existed since the year dot.

Before I proceed let me advise others reading through this … don’t do this at home.

Anyway …

  1. I turned off all avast protection.
  2. I recovered from my store a piece of malware.
  3. I renamed the malware to 1.ini (as requested by solcroft)
  4. created the bat file to start 1.ini
  5. placed the files on a USB drive
  6. I turned back on avast protection

I could have gone to the trouble to make it autorun - I did not - I will return to it in a moment.

  1. I started the bat file from the USB drive.

The result was the malware file (1.ini) was opened (without any warning from avast) and - on my system - was instantly displayed as a screenful of hex characters in my favorite text editor.

After that I then made a “right click” on the USB drive and selected the avast scan from the context menu. avast immediately produced its warning popup window and alarm reporting the infected 1.ini file.

Why did it not perform as solcroft expected? I had to go lookup the start command to find out why.

To be fair to solcroft in most systems it probably would. In my system I have associated .ini files with my favorite text editor since it recognizes the format of .ini files and gives me a nice color coded display of them. However, anyone could avoid the specific .ini file issue by simply associating the .ini file with Notepad.exe. The start command simply opens up the program specified for the filetype … so as it says in the help file …

start WORD.DOC

would open up the program associated with .DOC files. In my case, for 1.ini, it opened my text editor.

The autorun issue.

As I noted earlier in the thread this test required me to turn off avast protection in order to introduce the malware into my system. As reported above, avast’s quickscan picked up the infected 1.ini file. solcroft did specify that the USB device should be autorun. With this there would be no chance for the user to scan the device before it started executing whatever was on it. I believe that the malware filetype would have to be one that was considered innocuous by avast and not have a managing program associated with the filetype - solcroft may have done more research on other filetype exposure.

This exposure has existed since autorun came along - it could even have been done with a diskette (if the user did not bother to scan the diskette). I am a little surprised that it has not been closed yet.

This is not the first concern that has been raised with autorun and USB devices. Were I running a home system where my children were inviting friends over and sharing information on USB devices I suspect I would not permit autorun on the system.

I am glad to see the response from avast that they will be seeking a solution and I look forwarding to seeing it in the next release.

In the meantime - the other avast shields, the Webshield, the P2P scanner and the Internet Mail scanner can all help prevent the malware getting into our systems in the first place - along with using quickscan.exe on all files downloaded. Still best to be very wary about whose USB keychain devices you allow on your system.

Interesting… but not very honest of you. The “start” command checks the content type of the file being launched, instead of its extension type. If you rename a real .exe file with a PE file header to .ini, .tmp or any other extension you care to think of, the “start” command will STILL launch it as an .exe file, instead of checking its associations as you claim it does.

Eagerly awaiting the next version of avast!.

Sir,

at best you are unforgiving to question my honesty. I will refrain from further description of your honor, though I will question your capacity in software testing.

I have just, from the start, repeated my tests that followed your requests to the letter. The results are identical.

I see nothing in the documentation that says the start command checks the content type as priority. I have reported precisely as my Windows XP fully up to date SP2 system has responded.

So will I, mine good sir, so will I. :wink:

Would you mind sending the afore-mentioned file to me, by any chance?

I believe that my participation in this forum speaks more for my willingness to test many conditions with avast (and thereby to risk my system) and to report the results with veracity than anything this individual can question with any degree of belief.

Rather than indulge in any further barbs with this person and to try to retain this forum as a place of friendly debate I will leave the field open to the original poster - come what may.

Further to the last post of solcroft I will provide to the avast team - should they request it - every scrap of my system details, settings, logs etc and every piece of testing I have done in connection with this thread.

I’m afraid I have to agree with solcroft on this one. The way start seems to behave is that:

  1. normally, it uses the program associated with the file extension (and if there’s none associated, it asks the user what program should it open it in)
  2. however, if the file is a valid DOS/Win16/Win32 application (i.e. has a MZ header), it really executes it regardless of the extension, and its association settings.

This doesn’t seem to be documented anywhere (in official MS documentation - or did I miss something?), but I was able to verify this behavior by analysing the implementation of the start command; it first uses the CreateProcess API function, used to execute applications; only if this call fails, it tries to use the ShellExecute function which uses the extension association settings.

BTW alan, one explanation of the fact that it didn’t work on your machine would be that (maybe) you used a COM file virus (and not EXE) [e.g. eicar.com] - as COM files don’t have any recognizable headers, it would behave exactly as you described.

Thanks
Vlk

Vlk,

you have hit on it in one … the virus I used was a com file … sorry that I didn’t comply with the unspecified parameters of the original poster … I must try harder.

Thanks for confirmation - I’m glad it’s at least consistent.

BTW solcroft, how’d you find out about this behavior? I have to confess I was not aware of this, and it IS an important detail… :-[

Cheers
Vlk

No particularly clever methods involved, to be honest. It was just by chance.

BTW the way we plan to fix this is that each entry in the exception list would also have a bit mask RWX (read, write, execute) and this way it would be possible to choose on which of these actions will the exclusion take place.

The default extensions would be RW only.

Good move!

Next point release or next big release?

Thanks for the update. If only the virus analysts at Alwil respond this fast to malware submissions… :-[

Just out of curiosity, why not do it the way many other vendors do, and include an option to scan files based on content-type rather than extension? Is there any particular reason why the “regular” solution isn’t adopted in this case?

The scan itself is somehow content based - but the exclusion list is meant for excluding; if you want to exclude a known “grey-area” program, or even a false alarm - you want to exclude it even when it’s an executable file.