User-mode hooks or kernel-mode hooks-what's the best for an firewall????

I’m a new user of Comodo Firewall Pro as well as the new member.
What I’m interested is Matousec’s FPR(Fake Protection Revealer) tests-there are 38 of these tests,now Comodo passed all of these tests.

However my questions arise when Matousec accused Agnitum’s Outpost Firewall Pro for cheating on tests because they use user mode hooks???

Matousec says this:
"What is the trick of bypassing any user mode hook? Hooks change the code flow after the target process calls the hooked function. However, the process is never forced to use any of ring3 functions that might be hooked. It can always implement its own code to achive the goal, for which the function was written. To prove this statement, we have implemented FPR 2, which we use instead of the the original version for leak-testing now. FPR 2 does the same job as FPR, it unhooks user mode hooks of selected process and execute its code. However, if the call of VirtualProtect, which is needed for the implemented method of unhooking, fails, FPR 2 uses its own code to call the lower system service directly, not using the hooked VirtualProtect function at all. This method of bypassing user mode hooks can be implemented for every hooked function and can not be prevented unless the system performance is extremely lowered. "

The entire thread is here:

However my questions are:
Agnitum on their own blog said that one technique is not enough,and they use the combination of both user mode hooks and kernel-mode hooks should make robust protection-Agnitum says that only one technique is not enough to protect the firewall?
So,enough advanced hacker can easily bypass this protection?

And what about kernel-mode hooks?
Agnitum says that kernel-mode hooks can also be bypassed,and they could make the same tests for
kernel-mode hooks.
However,what Mr. Matousec says is that kernel-mode hooks can be protected,while there is no way that user mode hooks can be protected-except,unless the system performance is extremely lowered.

Basically,Agnitum creators were angered because they had to pay 1500$ or 2000$ for the report that Matousec wanted to show where their firewall(Outpost Firewall Pro) is leaking.

Can anyone help me with this:
Does it really matter do you use only user mode hooks or kernel-mode hooks(or combination of both techniques)-and why does Mr. Matousec accuses Agnitum for cheating if there are many other firewalls in leak-testing results do not pass FPR tests???

And as far as I know there is NO known malware that uses these kind of techniques to bypass the firewall protection???

Can anyone help me with this anyone who has more expertise on this???
Who is right ,and who is wrong:Mr. Matousec or Agnitum creators???

Hi Ultra-Bot, welcome to the forum :slight_smile:

What you have to remember, is that, both user mode and kernel mode hooking can be subverted. You may not have seen any malware that can do this, but It’s only a matter of time. This is really where CFP’s Application behaviour Analysis kicks in, as it monitors interprocess communication.

Also, Kernel mode hooks, as far as I know, will not work on Vista, as MS have decided not to allow this by design…

I’m not a security expert. So I would like Agnitum release that
kernel hook unhooking proof of concept and let non-Agnitum
users test their products against it.

It could be an useful utility to disable kernel rootkits too. :slight_smile:

As a rule of thumb Security is a tradeoff
between user-friendliness, speed and research.

There is no everlasting unchanging bulletproof security.

Security enforcing layers need to satisfy only one requisite:
They have to make difficut to compromise a system.

The difficulty could be research-wise or cpu-wise (i.e. resouce-wise)
So security layers are usually tailored on the target audience
common threats (i.e. threats pertaining a resouce-level range)

Chipering key lenght is choosen for example in a similiar fashion:
if it is needed to secure an x$ worth info, usually a k*x$ worth
resourcelevel keylenght is chosen.

There would be no need of such things like explicit backdoors
whereas faulty code or alike would have the same effects.

It would not be impossible for an average user to get infected
by a kernel rootkit so this would be something to be protected

Kernel hooks have far more control of the system than usermode
hooks so I would share matousec view about avoiding usermode
hooks in non vista environments.

EDIT: I finally found out Agnitum paper about kernel vs user hooks.

Their statement about usermode hooks granting realtime
interprocess communication monitoring is an interesting one.
This would be a good addition to kernel hooks
(in non vista x32 environments)

Agnitum has no vista-ready solution ATM.

Regarding Matousec disclousure policy I was not able to find a full
disclosure statement on their site to comment on but I think
we should consider three points:

  1. Matousec didn’t disclose all security vulnerabilities affecting Outpost.

  2. Matousec didn’t wait Agnitum to fix the vulnerability they inteded to freely disclose.

  3. Matousec charges money to disclose most of the vulnerabilities they found.

  4. It is a good policy, users are warned about potential vulnerabilities,
    no details were given overall but Agnitum was warned they had to
    check their code.

  5. This is questionable. They grant 30 days to fix the vulnerabilities only
    if the vendor buys matousec analisys.
    Public disclosure of a vulnerability details regarding Outpost Kernel hooks,
    whitout letting unpaying vendors one month to fix it, is harsh.
    If they wanted to make details publicly available the had to give
    the details to Agnitum and wait a reasonable amount of time.

  6. Nothing against charging money for a private disclosure of a security analisys.
    Vendors take precedence and that is good. But not all parties should be able
    to have such analisys paying or not, there should be a selection to prevent
    malicious use of these vulnerabilities.
    A public disclosure should grant full details to vendors and a resonable amount
    of time to fix it. In these cases a compensation could be requested too but
    should not be mandatory. If the vendor refuses It can make no excuse about
    a blackmail attempt but Matousec has the right to make clear they received
    no compensation for it.

A vulnerability exist with or without Matousec but making such information public
without some limitation is not a responsible action because it expose those
vulnerabilities to a wider number of malicious parties.

But we cannot assume that matousec was the only party able to find such
vulnerabilities… :o

Well, let me try to simply the problem…

If your enemy has a really strong weapon… then you better have a stronger one! ( I refer to malware’s ability to take over the kernel hence getting the upperhand against a security software running at the user mode)

Kernel is all about controlling the Operating system…
User side is where all the higher level applications run like Word, Excel etc…

Unless you control the kernel to a level, then as a security application running at the user level, you will have a difficult time to figure out if the kernel has been taken over by a malware or not. Look at rootkits… they take over your machine at the kernel level.

With v3 of our firewall (Beta out on 7th June :slight_smile: ) you will have even stronger protection against rootkits. We run our code at kernel level, yes it requires much higher skillset and amazing amount of care when coding and good amount of testing (and we are lucky to have all 3 (:NRD) ).

Of course that does not mean that User mode hooks are useless. of course they are not! We use some of that too. However, using them as the only defense is, IMO, not the right way forward.


Melih, does this mean that CFP will be less strong running under Vista, if Microsoft continues to prevent kernel hooks in that OS?

If so, I would rate that as another strike against Vista. I just ran across this article, rating its native security as hardly better than under XP:

I think vista would need a different approach.

MS is building up some api to give more control upon the system to security software vendors, but I guess those will be usermode api. Look at Microsoft Releases Draft API for PatchGuard

We have to wait and see.

This approach is like their tcp stack update that modified max concurent conections number to 10 in order to limit worms like Sasser :-X

well, you know us…
we will never comprimise our user’s security!

Will Comodo attempt to get the certified for Vista certificate? A very bad move for any protection soft.