Considering NOD but

Discussion in 'NOD32 version 2 Forum' started by Robyn, Mar 12, 2005.

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

    hollywoodpc Registered Member

    Joined:
    Feb 14, 2005
    Posts:
    1,325
    Mine too . Just if you wanted to know .
     
  2. alerter

    alerter Guest

    don't know why but my last two posts with questions seem to have disappeared without a trace...

    How does eset check for exploitable buffer overflows internal to nod32?

    Does eset rely on any third-party code reviews of nod32?

    This is of great interest, as three, major, more-media-celebrated commecrial a-V products (S*******, T****M****, M*A***) have had arbitrary code executing buffer overflows discovered by ISS X-Force in them. All of these BOs were found in decompression routines, used to unpack re-packed executables and/or decompress classic compressed file archives for a-V scanning... At least one of these Big Name a-V products (S) is a multiple and repeat offender, over the years, with regard to exploitable BOs internal to it's corporate and consumer a-V products.

    a-V needs to be much better built than compiled code of any other kind, because a-V, itself, is a focused target of malware and miscreants.

    This is why I'd like to know what eset is doing about this that is more proactive and demonstratively better than "The Other Guys"/Gals in a-V seem not to be doing well enough.
     
  3. alerter

    alerter Guest


    There are no "safe" public websites... never have been and never will be.

    DNS Cache poisioning has become all the rage... once again... it's always been around and never really went away, but it's back in the infosec headlines... and not just one vendor's product is a fault for this latest wave...

    With DNS cache poisioning, you may intend and think that you're going to Google or CNN, or where ever else, but the poisioned DNS cache is directing you to 7sir7(dot)com, 123xxl(dot)com, abx4(dot)com or worse, instead... (DO *NOT* GO TO ANY OF THOSE DOMAINS OUT OF IDLE CURIOSITY, THEY ARE LIVE AND REAL, DESPITE ONGOING WHITEHAT SHUTDOWN EFFORTS, DUE TO RAPIDLY CHANGING IPs.)

    a-V detection continues to be heavily signature-based and a-V signatures, by definition (pun intended), are always behind the curve of emerging malware. As such, multiple a-V scanning engines can be of some benefit, sometimes, but not always -- too many a-V products miss the same malware.

    Two or more *unmediated* "real-time, intercept a-V scanners" is generally a *bad* idea, due to deadly-embrace file contention problems that typically arise, sooner or later. (in the case where nod32 seems to not deadlock over an already locked file, the "other a-V" may lockup the system when it tries to intercept-scan something that nod32 is already chewing over.)

    Sybari has used *five*, concurrent a-V scanning engines for a while, in it's antigen product, in order to detect and protect malware before it enters a MS Exchange message store. Sybari came up with a way for all five engines to scan concurrently, without ever resulting in deadly-embrace file contention. The theory being that five, carefully chosen, generally reputable concurrent a-V engines, each receiving their own dedicated signature/definitions updates, stand a better chance of identifying emerging malware, closer to Day One, than one or two concurrent a-V engines guarding the same target.

    This idea has proven itself, in practice, and is probably why MS chose to buying up Sybari for itself.
     
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.