According to the article below, Comodo is one of the vulnerable products:
Site:
Link:
/news/Antivirus-Is-As-Vulnerable-as-Any-Other-Product-452339.shtml
According to the article below, Comodo is one of the vulnerable products:
Site:
Link:
/news/Antivirus-Is-As-Vulnerable-as-Any-Other-Product-452339.shtml
Hey,
Thanks for the nice share.
I’ve attached the report to my post since it takes forever to load.
[attachment deleted by admin]
Any reply from Comodo team !
Melih maybe !
https://safegroup.pl/inne/silniki-av-sa-tak-samo-podatne-jak-kazda-alikacja-t11361.html#p229254
http://www.syscan360.org/slides/2014_EN_BreakingAVSoftware_JoxeanKoret.pdf
[at]zbc
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 :
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.
[/list]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…
[/list]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:
*Point A in page 10 quote is ok, because kernel root access is must to spot any malware.