Comodo DLL injection via weak hash function exploitation Vulnerability

                           This originally appeared in the wilders security forums by a person called grey87y.

"Comodo Firewall Pro (former Comodo Personal Firewall) implements a component control, which is based on a checksum comparison of process modules. Probably to achieve a better performance, cyclic redundancy check (CRC32) is used as a checksum function in its implementation. However, CRC32 was developed for error detection purposes and can not be used as a reliable cryptographic hashing function because it is possible to generate collisions in real time. The character of CRC32 allows attacker to construct a malicious module with the same CRC32 checksum as a chosen trusted module in the target system and thus bypass the protection of the component control.
Vulnerable software:

  • Comodo Firewall Pro
  • Comodo Firewall Pro
  • Comodo Personal Firewall
  • probably all older versions of Comodo Personal Firewall 2
  • possibly older versions of Comodo Personal Firewall"
    I don’t know the truth behind it but just wanted to bring it your notice. I love and greatly admire comodo firewall and looking forward to the stable version ofCAVS. Many members at wilders security are not very grateful though. (B)

That originated from Matousec’s advisory and it shows Comodo was notified on 2007-02-01.

IMHO use of CRC32 was performance/easy coding trick …

now when CPF matured it’s time to offer users minimum of MD5 or some SHA hashing
(or ideally both, switchable in options (who want perf use MD5 who want safe use SHA-256) …

Thanks for clarification.

I gotta say that using a Cyclic redundancy check for a cryptographic check is against cryptography 101 and should really not have happened.

That being said, i am sure they will fix it.

If it is that bad, why did they use it in the first place? ???
This calls for an offical Comodo reply\clarification

I can’t support the original decision as i know too much (:TNG) . That being said, allot of vendors seem to make poor programming decisions and quick-fixes and in the end, development time and the security added may not have made business sense…

Anything i say is my opinion and not the opinion of Comodo, or any organization or person i may have contact with, but let me re-state for this thread that anything said by myself is MY opinion ONLY.

An official comment would be a good idea…

Will be fixed or not???

Comodo please reply.


The silence from Comodo in regard to this problem is deafening.
Wonder why Melih and/or others are not responding!

this is already fixed for v3…


I’m glad to hear that, and hope it will be released soon. ;D

Thanks for the update, Melih.
This new version 3 should be worth the wait.

Any fixes for the current 2.x in sight?

the 3 is only weeks away…
this attack is in the wild and we don’t expect to see it within next few weeks.
Hence we decided to concentrate all the developers on v3 rather than take their focus off it.