DosCreateMutexSem privilege escalation

345 pts.
Tags:
Security
Vulnerability Assessment & Audit
I am looking for an explanation of how a privilege escalation hack would be able to be inserted with a call to doscreatemutexsem function from a windows service that is running under the local system account.  I was unable to find anything on Google and not being a security expert I just don't see where a hack would occur with the call.

Software/Hardware used:
windows 2000 server
ASKED: September 16, 2013  6:33 PM
UPDATED: September 27, 2013  1:59 PM

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 6  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    It's not clear what problem you are having. We can't post clear descriptions of how an escalation such as this could be exploited nor post enough valid info to make the needed steps clear. But if you are having an actual problem, we can possibly post remediation steps. -- Tom
    125,585 pointsBadges:
    report
  • CarlCioffi

    My problem is trying to figure if it's a problem or if I should just ignore the findings by the OUNCE scan software with a line of code in a windows service.  I need to have some kind of intelligent answer for the higher ups about the following code and whether it's a security risk or not.

       // Create and open the Log semaphore
       rc = DosCreateMutexSem(LogSemaphoreName,&LogSemaphoreHandle,0,0);
    
       if (rc) {
          Log(DEBUG_ERROR,"Log DosCreateMutexSem %d",rc);
       }
    
    345 pointsBadges:
    report
  • CarlCioffi
    And the answer is.  When creating a named mutex, that mutex is visible throughout the operating system leaving open a place for a hacker to create a denial of service attack by attaching the mutex and thereby locking the real application indefinitely.  The only recovery is to find the rogue process that has a hold on the mutex and exterminate it or reboot the system which would not be a good thing to do when we are talking about a system that must handle all of the banking transactions for a retail establishment.  The solution is to use the windows API CreateMutex instead which is a newer version and create a mutex that is unnamed making it only accessible to the current process.
    345 pointsBadges:
    report
  • TomLiotta

    Note that as with many items, it isn't the function itself that is the problem. It's how the function is applied and how subsequent use of related objects is coded. If the mutex semaphore is private to the service and is properly closed and errors are handled, there should be no problem.

    What OS is involved? Usually, DosCreateMutexSem() is used with OS/2 subsystem code under Windows. In OS/2 the mutexs are reentrant and shouldn't be an issue unless it's intended for some kernel or server function that might deadlock on it and cause an unintended recovery branch. Since the mutex is created here, if it's only used in the service and all errors are handled, nothing significant should be affected.

    Tom

    125,585 pointsBadges:
    report
  • CarlCioffi
    This is a windows server 2000 application that was ported from OS/2 and is now C++ instead of C.
    345 pointsBadges:
    report
  • CarlCioffi
    I have figured out the answer.  when creating mutexes using a named mutex it is possible for another application to request the mutex because named mutexes are visible throughout the operating system.  The fix is to use NULL for the mutex name which makes it accessible only the application that created it.  I found no need to have a named mutex so I changed them all to unnamed mutexes and all is well again.
    345 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following