It's kind of amazing how everyone was flipping out left and right
about -- gasp! -- OpenBSD finally having a DoS issue. What a lot of
people missed was this little gem:
On Mon, 27 Jul 1998, MJE wrote:
>THE EXPLOIT, IN A NUTSHELL: by using existing Windows NT services, an
>application can locate a certain API call in memory, modify the instructions
>in a running instance, and gain debug-level access to the system, where it
>then grants the currently logged-in user complete membership to the
>Administrators group in the local user database.
One little paragraph, a world of gloom and doom. Piecemeal:
>an application can locate a certain API call in memory
Not too dangerous in and of itself, but...
>modify the instructions in a running instance
First problem: why are we allowed to modify a shared resource
(even a local copy of it) even as mortals? WARNING: Don't put
business logic in DLL's (and definitely do NOT export your
"BOOL bIsALegalTransaction(...)" type functions).
Second problem: why are we allowed to modify a text segment at all?
Is it possible to modify .EXE's locally too? (Since a lot of
programs use their own DLL's for various things, and several programs
(such as the Perl interpreter) keep the entire guts of the program
in a DLL, is that .EXE question academic?)
Imagine, if you will, taking some trusted server like IIS, getting
some code executed in its address space, patching code near where
a user context gets changed into (it just happens to be a DLL),
and execute code when someone logs into a private page (or better
still, snag their plaintext password). It's almost too easy.
WARNING: Be careful about running ISAPI applications on shared
server instances.
>and gain debug-leve access to the system
Since there was zero technical detail reported in that sentence
(and NT security types seem so reluctant to post source of sploits,
wonder why) we'll borrow from Microsoft's own security advisory:
* Locates the memory address of a particular API function
used by the DebugActiveProcess function.
So WindowsNT leaves a piece of memory wide open to reading and
writing that doesn't even contain _my_ data and then, in a context
of privilege, starts relying on code in that data range to execute
as designed?! Oversight or _deep_ design flaw?
Where else is this known to happen in NT? (Where is this not known
to happen but not known not to happen, if you get my drift?)
Does this mean that no Win32 programs that run with ANY sort of
privilege, be it user context, secret keys (ActiveX anyone?) or
business logic, can keep a secret if they load in evil DLL's? Does
this extend to DLL's loaded from the search path? Can DLL's be
preloaded into a process a la LD_PRELOAD (as seen in many Unices)?
Can this dangerous behavior of locally modifiable program text
be disabled? Is Win32 irrecoverably insecure?
(These are all honest questions; answers will be gratefully
appreciated whether I'm on or off the mark.)
-jhp
PS: While we're on the subject, I notice that most NT sploits, once
they've got LSA context, tend to add themselves to the admin group.
It's weird. If they were meant to be hacker's tools, there's SO
much more evil that can be wielded -- loading "device drivers",
shredding audit logs, and playing other merry havoc in ring 0, just
for starters. If they were meant to be demonstrations of vulnerability,
there are far more benign things that a sploit could do --
st{op,art}ing the Gopher service, deleting particular named files
from C:\TEMP no matter whose they are -- that still demonstrates
divine power just fine without providing free fun for lazy script
kiddiez.
--
"Windows NT 4.0 is 16.5 million lines of code that will never be debugged."
-Bill Joy
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:09:40 PDT