Geeks With Blogs
Greg Young Greg.ToString()

I knew there was a reason I kept Junfeng Zhang's Blog on my list (even during the slow months). I hadn’t checked the blog in a few weeks but reading it now just made my day.

There are two new items listed on the blog. The first is that someone fixed a huge security hole, I have actually run into this particular security hole. Junfeng calls it kernel object name squatting. I have never heard it called by this name but it is a pretty simple problem. Shared objects between process are shared the question is who protects them from prying eyes?

Let’s propose you have the following code (note this is a trivial example and likely has bugs in it but it should illustrate the point).

static void Main(string[] args) {
  bool Created;
  Mutex m = new Mutex(false, "MutexWeWillSteal2", out Created);
  if (Created) {
  for (int i = 0; i < 100; i++) {
    bool havelock = false;
      havelock = m.WaitOne(5000, false);
      if (havelock) {
         Console.WriteLine("acquired lock");
       } else {
         Console.WriteLine("Unable to acquire lock");
     finally {
       if (havelock) {


As we can see this application is simply starting up, creating a mutex if it does not exist already then simply obtaining and releasing the lock. You can quite easily bring up two of these applications to notice that they are synchronizing with each other. Using a named mutex like this is extremely common in order to synchronize two processes.

The problem with mutex is not as great as some objects as I can apply an ACL to prevent people not at a certain level from accessing it. Unfortunately I still suffer from a denial of service attack from applications at my own level. One can quite easily use the debugger (or other tools) to find out the names of the objects I am using (!handle in windbg will bring this right up for me). Once I have that name I can write a bit of code such as the following.

static void Main(string[] args)

bool Created;
Mutex m = new Mutex(true, "MutexWeWillSteal2", out Created);
m.WaitOne(-1, false);


Providing this code access the mutex before our other processes, our other processes will just fail. We have effectively made the other application unable to do anything (the basis of a denial of service attack).

What is being introduced in LH is the ability for me to make my two processes share a namespace. As such their namespace can be protected. The malicious program can start but one can avoid it from having access to the mutex explains exactly how it works but basically the processes that want to share the data define a boundary (and requirements to get into the boundary that they both share)

This function requires that you specify a boundary that defines how the objects in the namespace are to be isolated. Boundaries can include security identifiers (SID), session numbers, or any type of information defined by the application. The caller must be within the specified boundary for the create operation to succeed.



The second post I found really interesting was condition variables Condition Variables are one of the 3 locking mechanisms (along with mutex and semaphore). I do not quite understand the excitement over it (perhaps POSIX compatibility?). I was under the possibly misinformed impression that it was roughly equivalent to Events in windows.

Basically I can in POSIX use

Pthread_signal() which alerts one thread waitingPthread_boradcast() which alerts all of my threads waiting


In Win32 I can use

PulseEvent() but there are two types of events

AutoResetEvent which will only let one thread though and ManualResetEvent which I can use to let some or all through

I am now morbidly curious on the subject; it has been way too long since I was at this level

Posted on Thursday, June 1, 2006 7:04 PM | Back to top

Comments on this post: Private Object Namespaces and Condition Variables

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Greg Young | Powered by: