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


Current thread: