Eset HTTP scanner intercepts Adware, kills browser

Discussion in 'ESET NOD32 Antivirus v4 Beta Forum' started by vijayind, Nov 24, 2008.

Thread Status:
Not open for further replies.
  1. vijayind

    vijayind Registered Member

    Joined:
    Aug 9, 2008
    Posts:
    1,413
    I was testing the HTTP scanner component of ESS 4.0 beta 1. I went to a known Adware site and tried to download it via FireFox 3.:p

    Eset-1.jpg

    ESS immediately intercepts and shows that it found the Adware. It proceeds to delete/quarantine it.:thumb:

    Eset-2.jpg


    In the process, causing the browser (FireFox 3) to crash.:blink:

    Eset-3.jpg

    Suggest Eset write a more friendly incept mechanism.
     
  2. wiak

    wiak Registered Member

    Joined:
    Sep 10, 2006
    Posts:
    107
    i think its a firefox problem, why? eset just deletes the file and firefox cant find it or that eset deletes the file in temp folder before firefox can complete?

    did you try Google Chrome or IE7?
     
  3. vijayind

    vijayind Registered Member

    Joined:
    Aug 9, 2008
    Posts:
    1,413
    I don't have G-Chrome. But I am have IE7 :D

    I goto Adware site and start download.

    ESET-IE-1.jpg

    When download has finished and IE7 is about to save the file to disk. Eset intercepts:
    ESET-IE-2.jpg

    Because, the file has been snatched before even creation/confirmation of file. IE7 download gets stuck at 99%. But fortunately, IE7 doesn't crash.

    ESET-IE-3.jpg


    So it looks like Eset is a bit to eager. And so, I would suggest allowing application to save and receive confirmation of the same from OS before snatching it up. This will ensure compatibility with all apps.

    PS: Have tried the same test before on other apps also. First time seeing such behavior.
     
  4. ASpace

    ASpace Guest

    @vijayind

    I can confirm . It happens here , too . It seems to be ESS issue . For some reason it doesn't happen with EAV
     
  5. nodyforever

    nodyforever Registered Member

    Joined:
    Oct 30, 2007
    Posts:
    549
    Location:
    PT / Lisbon
    Hello,


    Interesting:

    FF3:


    cleaned by deleted - quarantine



    IE7:

    connection terminated - quarantine



    Most Regards,
    NF
     
  6. JuliusB

    JuliusB Registered Member

    Joined:
    Aug 12, 2008
    Posts:
    82
    hello,

    I'm using NOD32 3.0 and firefox crashed too when trying to download mirar toolbar.
    but it's the first time I've seen FF3 crash because if this.
    it does not crash when let's say I download EICAR test file also there were some exploit code detected and quarantined in the past and some adware too(in frostwire), but it didn't crash either.
     
  7. vijayind

    vijayind Registered Member

    Joined:
    Aug 9, 2008
    Posts:
    1,413
    That is surprising :doubt:
    Guess, the firewall/IDS is also playing a part here then ...
     
  8. vijayind

    vijayind Registered Member

    Joined:
    Aug 9, 2008
    Posts:
    1,413
    Sorry somehow I missed that :D
    You have a great, eye for detail ;)
     
  9. vijayind

    vijayind Registered Member

    Joined:
    Aug 9, 2008
    Posts:
    1,413
    That is interesting. Guess, its best for someone for Eset to have the last word on this.
     
  10. MasterTB

    MasterTB Registered Member

    Joined:
    Jun 19, 2007
    Posts:
    547
    Location:
    Paran?, Argentina
    I tried this with Opera, and not to my surprise the file is intercepted by Eset on the download folder and deleted BUT Opera does not crash.
    hahaha, Opera rules:thumb: , still I think ESS should have prevented the file from being downloaded with the web filter, instead, it allowed the file to be downloaded (maximum compatibility I think - and the fact that my browsers are not in active mode) and the file was inmediately deleted without issues.

    Could it be that you have set your browsers to active mode in ESS's config??
     
  11. doktornotor

    doktornotor Registered Member

    Joined:
    Jul 19, 2008
    Posts:
    2,047
    Well, you can't prevent something from being downloaded until you have sufficient part of the data available to be able to actually detect that there's malware/PUA being downloaded... otherwise, you'd break any legitimate downloads for users, making them really unhappy. :D
     
  12. qwn047

    qwn047 Registered Member

    Joined:
    Nov 25, 2008
    Posts:
    1
    Yes, eset can... it's called a web filter... the same way when Google detects hazardous sites, it flags them for 30 days and the next time it's accessed it sends the warnings based on the filter, e.g. URL.


    But yeah... ESS should watch for file unlocking and act when the time is right.
     
  13. elapsed

    elapsed Registered Member

    Joined:
    Apr 5, 2004
    Posts:
    7,076
    You can't filter what you don't have, you need a sufficient amount of data for the filter to pick somehting up and cancel the connection, thus meaning downloading a sufficient amount of the file to prove it's malware.

    Google detects bad sites mainly for dangerous scripts loaded on the site that try to take advantage of loopholes in your browser BEFORE anything is even downloaded.

    As you can see, both subjects are different and have been caught up in the mix here. As far as I know, ESET doesn't filter websites based on dangerous scripts, but the file it tries to drive-by install into your pc.
     
  14. nodyforever

    nodyforever Registered Member

    Joined:
    Oct 30, 2007
    Posts:
    549
    Location:
    PT / Lisbon

    Hello,


    Curiosity:


    OPera 9.62

    Popup appear cleaned by deleted - quarantine or connection terminated - quarantine?



    Thanks you advance
     
  15. ASpace

    ASpace Guest

    Hi !

    Althought I don't get the point of this post of your , cleaned by deleting - quarantined is triggered by the real-time file system protection on a file that is/was located on the hard disk . The second alert , connection terminated is from the web protection , stopping the download of a dangerous file
     
  16. MasterTB

    MasterTB Registered Member

    Joined:
    Jun 19, 2007
    Posts:
    547
    Location:
    Paran?, Argentina
    Yes, Opera 9.62, build 10467 and it was "cleaned by deleting - quarantined" and the file is in the Quarantine Folder.

    As I said the file was catched by File system protection and not by web filter (wich is what I would have expected of Eset -but I accept some conclusions said here in this thread that you need a certain amount of data before flagging a file as suspicious and since my browser is not set to active mode I accepted it- as long as the threat is dealt with, of course), hence, the popup cleaned by deleting - quarantined.

    I also should say that I always set my nod to strict cleaning.
     
  17. nodyforever

    nodyforever Registered Member

    Joined:
    Oct 30, 2007
    Posts:
    549
    Location:
    PT / Lisbon


    Hello,



    I asked simply because it can be the way ESS / EAV may be interacting with Firefox ..... but as I have already mentioned in another topic that is very strange how the NOD32 v3 and 4 is behaving with the Firefox.



    Most Regards,
    NF
     
  18. MasterTB

    MasterTB Registered Member

    Joined:
    Jun 19, 2007
    Posts:
    547
    Location:
    Paran?, Argentina
    Hi nodyforever:

    I was thinking that perhaps the problem is that ESS blocks the file right after the download is completed to do the antivirus check (therefore not releasing it to be used by the system until the check is done) and Firefox's download manager gets picky about that because it want's to notify the success of the download and can't because ESS detected a threat and deleted the file.

    Regards.-
     
  19. doktornotor

    doktornotor Registered Member

    Joined:
    Jul 19, 2008
    Posts:
    2,047
    Well, out of curiosity - can you reproduce the issue if you disable the automatic antivirus scanning in FF3? I find this feature a horribly annoying gimmick that doesn't do anything useful, any AV will pick up new files in real time as they've been downloaded, so WTH is this good for?
     
  20. nodyforever

    nodyforever Registered Member

    Joined:
    Oct 30, 2007
    Posts:
    549
    Location:
    PT / Lisbon


    Hello,


    Other post view: https://www.wilderssecurity.com/showthread.php?t=201157&page=2



    Despite the different perspective of the post ends up being almost the same thing in relation to Firefox.



    Most Regards,
    FF
     
  21. MasterTB

    MasterTB Registered Member

    Joined:
    Jun 19, 2007
    Posts:
    547
    Location:
    Paran?, Argentina
    Hi nodyforever:

    Nice catch, I had completely forgotten about that thread...
    See my answer at the end of the post: (https://www.wilderssecurity.com/showpost.php?p=1211639&postcount=47)
    "An important Update: setting the Dessinfection parameters to the max, passes all the tests (using Eicar) and leaves no traces of anything on the machine, even with forced downloads..."

    Like I said, I'm guessing ESS only deletes all trash attempted to download when set to maximum efficiency, ergo strict cleaning, meaning that when set to default it will attempt to actually "clean" the downoad file from any garbage leaving out the rest of the code if proven to be harmless.

    Evidently the way in which v2 dealt with threats is still considered by most of us as the most effective of all... hope they will consider going back on some concepts.

    As to Firefox I have to say that I never really liked it, there is no way I will ever use it seen how many people reports problems with it, I'm staying with Opera (I know this coment is off topic, just an opinion)

    @doktornotor: you said to me that "Well, you can't prevent something from being downloaded until you have sufficient part of the data available to be able to actually detect that there's malware/PUA being downloaded... otherwise, you'd break any legitimate downloads for users, making them really unhappy"
    And I somehow accepted that answer since it is kinda right, but now that nodyforever brought that other post to my attention I cannot help but remember that with nod v2, when a browser attempted to download a file that download would be intercepted by the web filter and the connection terminated if the code would prove to be malicious (see this pic: https://www.wilderssecurity.com/attachment.php?attachmentid=198786&stc=1&d=1206406760) so why is it that v4 can't??++

    Update: Just for the fun of it I did a new batch of trys with Beta 4 set to strict cleaning on the web filter... I tried to downoad the eicar test file and on all attempts I got a "Conection terminated" alert, so I tried with the mirar toolbar, then ESS let's the file to be download just to be catched by the realtime filter. I guess it is a matter of how complex the threat is that causes it to be detected by the web filter or the real time file system filter... who knows, maybe some Eset mod can explain better how this is supposed to work...
     
    Last edited: Nov 26, 2008
  22. doktornotor

    doktornotor Registered Member

    Joined:
    Jul 19, 2008
    Posts:
    2,047
    And you actually think the file has not been downloaded? Of course it was, it just wasn't released back to the application. Once again, you can't scan what you don't have, doesn't matter whether it's in RAM or on disk. What kind of "behaviour" will appear in the browser depends on the size of that particular download, if it's small enough the browser will never notice anything's been downloaded because the entire file can be scanned at once. You cannot do this with big downloads because you'd get "timeout" issues, the browser would think the download has stalled, so you release the download contents back to the browser in parts to get around this.

    P.S. Still interested to hear whether this makes the issue any different w/ FF3.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.