NOD32 Antivirus causes interruption in TCP 80 traffic and TCP 443

[kelly.ross 0]

I have a reproducible environment that we can see the issue in, here are the steps to reproduce the issue:

 

System: Windows 10 64-bit or 32-bit. Jukebox Player 8.8.8.69451.

 

Steps To Reproduce:
1. Install Jukebox Player from Numecent.
2. Install NOD32 Antivirus 9.0.318.0 
3. Navigate to: hxxp://numecentcloud.com/service
4. Login with credentials: <can be provided in private to ESET R&D if needed, please contact me.>
5. Cloudpage Adobe Photoshop CS5 32-bit.
6. Run ESET NOD32 Scan (or any other virtualized application).

 

Results:
You will be unable to get to any web site on TCP 80 or 443 when ESET is enabled. Turning off the Antivirus will correct the issue. I have reported this 2 times to your support team and both times my tickets have been closed without any warning or resolution. This issue impacts many universities in the US and Europe using our combined software for BYOD implementations. I would like to stress that we have a very large number of users getting a very bad experience as a direct result of this issue and we currently have no option but to inform them that this is an outstanding issue with the ESET product and the only way to resolve the problem is to choose another anti-virus solution.

 

 

 

[mma64 7]

I will follow this topic carefully and if ESET doesn't seem to react, I have an idea that could get the blocked / stopped / whatever happened (")firewall(") back to work - a workaround, yes, but better than nothing. (In the meantime - I only have ESET Smart Security V9 (ESS V9) - are there any settings / rules you can change in the (")firewall(") section of ESET NOD32? Whereas rules would be better than settings probably - for the workaround test.)

 

Sorry for asking, but what do you mean with "run ESET NOD32 Scan (or any other virtualized application)"?

 

[background: in ESS V9 there's something similar going on, but in the HIPS (")module("). An incident that happened already 5 times on my PC, only with ESS V9, and I think it's very consistent and highly reproducible. Similar to what you described, ie. one has to make something "special" within ESS V9 during ESS V9 is doing another thing... This triggers a very serious bug of which you will notice nothing if you don't check the HIPS log as regularly as I do! And, yes, I still have to report that bug, but only after I have retested and verified this behaviour. If interested you can read on here, https://forum.eset.com/topic/7186-the-mysterious-hips-duplicates-bug/#entry40525, ie. the sentence in bold letters in front of the following image. (Describing another bug, but far more difficult to reproduce as snappy as ESET seems to want it.)]

 

You're reproduction procedure is quite snappy. And therefore I have no doubt that ESET will be able to fix it.