|
Vulnerability Development
mailing list archives
ImpersonateNamedPipeClient() vulnerabilities
From: Mikael Olsson <mikael.olsson () ENTERNET SE>
Date: Wed, 2 Aug 2000 19:42:05 +0200
Hi,
This is clearly on topic for the NTBugtraq list, but something
tells me that I'll get moderated down there, as per usual.
I'll take my chances with Blue Boar instead :)
-----8<---- Quote latest Microsoft security bulletin
Microsoft Security Bulletin (MS00-053)
- --------------------------------------
Patch Available for "Service Control Manager Named Pipe
Impersonation" Vulnerability
Issue
=====
The Service Control Manager (services.exe) is an administrative tool
provided in Windows 2000 that allows system services (Server,
Workstation, Alerter, ClipBook, etc.) to be created or modified. The
SCM creates a named pipe for each service as it starts, however,
should a malicious program predict and create the named pipe for a
specific service before the service starts, the program could
impersonate the privileges of the service. This could allow the
malicious program to run in the context of the given service, with
either specific user or LocalSystem privileges.
----8<----
I've had a note in my cell phone for the better part of july
reminding me to investigate the exact circumstances of the
ImpersonateNamedPipeClient() API call, but I haven't gotten
around to it, and will likely not in the near future.
I'm posting this on a theoretical ground only, simply because
I think it's time to let someone else have a go at it.
Anyhow, couple the above information with this information
from the Microsoft developer docs:
The ImpersonateNamedPipeClient function allows the server end of a
named pipe to impersonate the client end. When this function is
called, the named-pipe file system changes the thread of the calling
process to start impersonating the security context of the last message
read from the pipe. Only the server end of the pipe can call this function.
Then add this:
The "Server End" of a named pipe doesn't necessarily imply that
it's sitting at a server. Instead, consider this:
The network administrator is about to reboot a server. He does
"net send * The server is rebooting in five minutes!" from the
server as the domain administrator and acts as a client, connecting
to every server (connected computer) in the network. (I could be wrong
here, this may not be named pipes, but to my recollection, they are.)
And if the above one doesn't work, try this:
It isn't altogether impossible to impersonate servers by fooling
around with NetBIOS name resolution, faking registrations to
WINS servers, etc. As soon as you get someone to connect to your
named pipe, you can impersonate that client.
Well, that's about it. Do with this what you want (install packet
filters everywhere that block ports 135-139?).
I didn't bother sending this to Microsoft simply because I don't
consider it to be a bug (if my theories hold up to scrutiny, that
is), but rather a very basic design flaw that we can't expect
to get "patched" any time soon.
Regards,
/Mike
--
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK
Phone: +46 (0)660 29 92 00 Direct: +46 (0)660 29 92 05
Mobile: +46 (0)70 66 77 636 Fax: +46 (0)660 122 50
WWW: http://www.enternet.se/ E-mail: mikael.olsson () enternet se
By Date
By Thread
Current thread:
- ImpersonateNamedPipeClient() vulnerabilities Mikael Olsson (Aug 02)
|