Vulnerable AVs in general

According to the article below, Comodo is one of the vulnerable products:




Thanks for the nice share.

I’ve attached the report to my post since it takes forever to load. :wink:

[attachment deleted by admin]

Any reply from Comodo team !
Melih maybe !

you are focusing on the heap overflow,
consider also the other problems mentioned on page 10 and page 20 of the pdf.

Could you quote those here?

Mentioned vulnerabilities :

  • 2 heap overflows, while one being related to handling CHM files
  • Bugs in the parser of BZ2 files
  • Updates are done via HTTP only protocols / Updates are not digitally signed
  • Windows only AV engine can be run in Linux environment

Note : It does not necessarily mean that those are the only problems. Those are probably one of the (important) ones to be mentioned.

Actually, the recommendations should be followed :

- Audit your products: source code reviews & fuzzing.
  • No, AV comparatives and the like are not even remotely close to this.

  • Running a Bug Bounty, like Avast, is a very good idea too.

  • Do not use the highest privileges possible for scanning network packets, files, etc…

  • You only need root/system to get the contents of that packet or file.

  • You don’t need to be root/system to scan a network packet or a file.

  • Send the network packet or file contents to another, low privileged or sandboxed, process.

  • Run dangerous code under an emulator, vm or, at the very least, in a sandbox. I only know 1 AV using this approach.

  • The file parsers written in C/C++ code are very dangerous.

  • If one finds a vulnerability and it’s running inside an emulator/sandbox one needs also an escape vulnerability to completely own the AV engine.
    [list]- Why is it harder to exploit browsers than security products?

  • Or use a “safer” language. Some AV products, actually, are doing this: Using Lua, for example.

  • Do not trust your own processes. They can be owned.

  • I’m not talking about signing the files.

  • I’m talking about your AV’s running processes.

  • Do not use plain HTTP for updating your product.

  • Use SSL/TLS.

  • Also, digitally sign all files.
    [list]- No, CRC is not a signature. Really.

  • …and verify there is nothing else after the signature.

  • Also, verify the whole certification chain…

  • Drop old code that is of no use today or make this code not available by default.

  • Code for MS-DOS era viruses, packers, protectors, etc…

  • Parsers for file format vulnerabilities in completely unsupported products nowadays.

  • Such old code not touched in years is likely to have vulnerabilities.

  • Ignore any antivirus comparative company asking you to detect malwares from the Jurassic era. Avoid them.

First sorry for the delay i was away.

Page 10 of the pdf quote:
point A:
-Most (if not all…) antivirus engines run with the highest
privileges: root or local system.
-If one can find a bug and write an exploit for the AV engine,
(s)he just won root or system privileges.
point B:
-Most antivirus engines updates via HTTP only protocols:
-If one can MITM the connection (for example, in a LAN) one
can install new files and/or replace existing installation files.
-It often translates in completely owning the machine with the
AV engine installed as updates are not commonly signed.
Yes. They aren’t.

Page 20 of the pdf quote:
-In general, AV engines are all compiled with ASLR enabled.
-But it’s common that only the core modules are compiled with ASLR.
-Not the GUI related programs and libraries, for example.

So the 2 other problems i meant is:

  1. point B in page 10 quote
  2. pages 20 quote.

*Point A in page 10 quote is ok, because kernel root access is must to spot any malware.