[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntbugtraq
Subject:    Re: Process listening and all that Jazz
From:       Greg Hoglund <hoglund () IEWAY ! COM>
Date:       2000-08-21 18:10:06
[Download RAW message or body]

This is an interesting thread.

> (note that x86 does not have "execute enabled" PTE bit - on x86 flat mode,
> any readable memory can also be executed, so, the virus can even skip
> setting "execute" permission on this VM area).

True - the x86 doesn't have an execute bit on a page.  It makes a
'non-executable' stack very hard to solve on an x86 NT box.

> But if you mean - creating a _full blown process_ without the hackery
> described above and with a separate kernel process object for it - the
> answer is "no".
> The kernel does not provide a functionality of hiding some process objects
> from taskman, tlist or similar tools.

That is incorrect.

The kernel does _not_ provide a 'NtHideProcess()' call, yes, that is
correct.  However, it is completely incorrect to assume that a driver or
other kernel-mode component cannot hide ANY process or driver or thread from
the user-mode view.  Do not make this assumption.

> This was discussed on the NT kmode development newsgroup about half a year
> ago - and _nobody_ there argued this. I think that the opinion of that
> community is respectable.

Anyone who codes very low level should understand that it is 100% possible,
and sometimes even trivial, to patch existing code.  A patch to the running
kernel can do anything - and enabling stealth for a running process is one
of them.  So, although I'm covinced that the kmode newsgroup is populated
with very skilled and intelligent people - I'm also certain that they did
__not__ discuss the possibility of patching existing code paths
specifically - because altering or patching code is very powerful and can
acheive almost any ends. This is elementary.

> Looks like that this code injection trojans (they are based on
> WriteProcessMemory in another process and CreateRemoteThread) - CANNOT be
> guarded against in NT. Switching "Debug Programs" right off the current
user
> will not do this. This right is only checked in 2 branches of
> debugger-related paths in NtQuery/SetSystemInformation, in NtOpenProcess
and
> in undocumented (no Win32 analogue, at least in NT4) NtOpenThread.
> The logic in NtOpenxxx is:
> - if the caller has SeDebugPrivilege - then grant him all access he wanted
> to the process/thread, regardless of the object's ACL.
> (SeDebugPrivilege overrides the process ACLs).
> - if the caller has no this privilege - then do the checks against the
ACL.
>
> Now on ACLs:
> - all apps launched interactively including explorer.exe have
> "ThisUser:AllAccess + System:AllAccess" ACL.
> - so, the trojan runned by the interactive user is free to inject any code
> in explorer.exe it wants regardless of the "Debug Programs" user right.

I don't fully understand what is being stated here.  Do you mean to say that
shutting off debug priv is useless?  I certainly would like to see a normal
user logged in interactively run OpenProcess() on CSRSS __w/o__ having the
debug priv.  ;-)

If you mean to say that I can inject threads into or attach to any process
that I own - I don't think that's an issue.  Who cares if I can alter the
process that I started? If I wanted the process to do something different
than it was intended to do, I could just start a different process!

The concept is trickle-down - Sure, I can inject threads in explorer.exe -
but I could also rename an alternative shell to explorer.exe and launch it -
what's the point?  They are all processes under my control.

This would only be an issue if a user were able to attach to a process that
she didn't have access to (via ACL) - or that the debug priv. didn't operate
properly.

It could also be possible that I completely misunderstood what you meant -
it wouldn't be the first time ;-)


-Greg Hoglund
http://www.clicktosecure.com

----------------------------------------------------------------------------
Delivery co-sponsored by eEye Digital Security
============================================================================
Vulnerability Is Over ... eEye Digital Security Announces Retina(tm)

Retina, the unparalleled network security product that scans, monitors,
alerts, and automatically fixes network security vulnerabilities. Retina
includes an auto-update feature providing continuous update of its modules,
allowing users to keep pace with the latest security vulnerabilities.
Retina, the first network security software that works like an
around-the-clock human network security analyst.  Available for download;
<http://www.eeye.com/click.asp?referrer=ntbugtraq1&P;=retina>
----------------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]