Filtering kernel calls on Windows

Do any HIPS or sandboxes offer a way to filter kernel calls? i.e. blocking specific kernel calls based on per-application rules?

Is it even possible to do so with a loadable driver?

More importantly, is it practical? I know that Windows does a lot of stuff in kernel space, so I could see where this might not be a reasonable approach. Also there are (I think?) kernel calls for e.g. memory allocation that should not be blocked.

Even so: could one block certain calls to the NT kernel on a per-application basis, as a stopgap measure for dealing with zero-day kernel holes (a la Seccomp)?

 

Okay, it looks like I was misunderstanding some things. Kernel calls == system calls, and HIPS work by filtering system calls. So a well-designed HIPS could perform a similar function to Seccomp filtering if configured correctly, no?

 

I don't know anything about seccomp, but HIPS do filter system calls. Though its PITA to configure interprocess communications(preventing virtual memory access of a process) and in preventing memory only attacks(meterpreter and memory only malware).

HIPS can be bypassed by many other ways, but can be designed if desired by serious developers to withstand even possibly kernel exploits, I think...
http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-tsyrklevich.pdf

MessageBoxA seemed to have developed an EMET alternative with added more anti-ROP techniques which I think can do what seccomp aimed to do, ie, prevent some process from doing some kernel or system calls that process is not supposed to do, right? If I understand what he said before correctly or I am way offtrack? He is trying to make everything worked through a device driver. Anyways, he's afraid of MS if he makes public or even share privately what he is currently using.

 

Our friend Hungry Man wrote about seccomp here and here. In the first article is a link to a paper by Google developers:

and:

 

Because I'm still kind of interested in this...

Would it be possible to do some kind of external sanity checking of system call parameters on Windows? Obviously it would be better not to have hundreds of weird undocumented system calls, but since that's not an option on Windows... Maybe it would help to have software that had a library of system calls and what arguments they should take, and could say:

"Hey, this system call is supposed to take a 32 character ASCII string as an argument, not 32 KB of line noise. This looks like an exploit attempt."

or

"This system call is undocumented and only supposed to be used by system software, but the application using it has no digital signature. This shouldn't happen."

and terminate the offending program? Or is that horribly impractical?

 

Yeah, you could.

Might have to register a service that interrupts calls, maybe overloads, or registers some kind of device driver to intercept specific calls using one of those mindrivers.

There is no native way to do this. You couldn't do it as 'elegant' as on linux.

 

Ah, I guess that's what Seccomp filters do then? Interesting. Wish I had the programming skills ATM to write something like that.

 

No, seccomp filters are built into the operating system. They are a native and exposed feature, making use of the berkley packet filter, and programs compile in support for it.

On Windows you'd have to use an interface to either:

1) Do function hooking/ overwriting

2) Load up your own device driver

3) One other method that I'm too lazy to post about, but if you'd like I'll PM it to you if/when I get the link

Don't get ahead of yourself though. It's fun to think about, but it's best to just study in order I've found. Once I started doing that I got way closer to writing things like the above than I ever had been when I tried to jump straight at it.

 

Ah, I see. I think I'll start another thread on seccomp.