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

List:       ntbugtraq
Subject:    Re: Process listening on TCP port 4198?
From:       "Maxim S. Shatskih" <maxim () STORAGECRAFT ! COM>
Date:       2000-08-19 14:51:11
[Download RAW message or body]

> Absolutely -wrong-. Under NT, a process can attach itself to a
> already running process (eg. explorer.exe). If a process does so,
> taskmgr will -not- be able display the hidden process. And I expect
> pviewer to react pretty much the same way, although I haven't
> actually tested that.

You are definitely speaking on the "DLL injection" thing described in
numerous places like Geoffrey Richter's Win32 book.

Strictly speaking, this is not _process_ hiding - no _process_ is created,
what is performed is that _some malicious machine code (not even a
full-blown binary image maybe) is injected in some pre-existing victim
process without practically any traces of it_.

Surely taskman, pviewer and tlist will not be able to catch such thing. The
only traces are +1 thread in the process and +1 private VM allocation in it.
(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).

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.
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.

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.

    Max

----------------------------------------------------------------------------
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]