Dejan,
First things first, Hope you know that is is a losing battle and all you can
achieve is to delay/stall the attacker…
Having said this, what you are trying to achieve is ‘caller validation’, if
it is not, then I mis-interpret the thread, and you need not read any
further.
There are a few things you can try (and non of these would help if the
attacker has admin rights)
- Validate the hash of the function calling into your driver (HMAC) (make
sure there are no relocatable codes in the segment) - Works if there are no
other functions in between, since there are several layers of software
between your app and your driver, then finding the caller’s IP and return
address would only lead you to some kernel component. There are a few work
arounds:
1.a Walk the stack back: Difficult without symbols, and FPO might be a
problem too, but still a doable thing. The tough thing is to know, how far
back the stack you gotta walk, before you jay walk 
1.b Generate an interrupt and jump straight from ring 3 to 0. The interrupt
handler in the driver will get immediate control and the EIP will point to
the original caller. Ofcourse, the usual targets are the debug interrupts
The problem here is vista and above kind of dislikes this approach. But
again doable.
- To prevent debuggers from attaching to your process: There are several
known ways to detect debuggers, some of them are specific to certain
debuggers, and all of them have known work arounds by hackers.
- Move your protection code outside the purview of the OS: Like in a
headless hyper visor, to disarm debugger based attacks.
- Split up the data from the command. The IOCTL goes in with junk data, and
the actual command/data goes in through a different route, like 1.b
- Encrpytion: ARmadillo or similar techniques to protct the process in
memory.
- Instead of trusting a process, spawn the process from the Driver. The
process binary (or a stub) can be inside the driver as a resource, not an
easy thing to achieve.
- Use a trusted third party to validate the process, like a webserver with
a key generated and with a short-finite key validity life.
- The list goes on…
We did all of this, and were wondering where we draw the line, after all
many of these things are in antivirus domain, we were just a security
product. And after doing al of this, when we wanted the code pen-tested, t
took the hacker (one of the best in profession) all but 3 days to make the
code dance to his/her tunes.
Your best bet is 3 or 7…
Thanks
amit
On Thu, May 12, 2011 at 9:28 PM, Tim Roberts wrote:
> Dejan Maksimovic wrote:
> > Let me run this by you (all) then.
> >
> > There are two types of control codes for our driver - Send Entry and
> Delete/change Entry. Any application should be able to Send new entries, but
> only that application should be able to change/delete that specific entry.
> > If I get the process image file name during Send Entry call, compute
> the hash, save it and compare it against the process image’s hash during
> Change/Delete, what can a user mode application do to subvert that? Provided
> that the application cannot load any new drivers, in which case all bets are
> off obviously.
>
> Wouldn’t it be just as good – and much easier – for you to return a
> random key when you create the entry, then require that key to be
> specified when you do the Change/Delete?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0
