3

I couldn't find much information about Untrusted integrity level in Windows, and have some questions about it:

  1. Is there a place where an untrusted integrity level process can create named objects? (mutexes, events, etc..)
  2. Should untrusted integrity level process be able to open an existing named object, that was given a security descriptor in it's creation time with ACE with SYSTEM_MANDATORY_LABEL_NO_WRITE_UP to MandatoryLevelUntrusted? When I try it, it fails with 0xc0000022(access denied), while with MandatoryLevelLow it works great.
  3. How do usually untrusted integrity processes communicate with their broker process? (like how does a google chrome tab communicates with the google chrome broker?)
macro_controller
  • 1,469
  • 1
  • 14
  • 32
  • but are you can create process with *WinUntrustedLabelSid* which not fail on start ? in my test, this find of process is fail when try load *kernel32.dll* - because in load process process he try open *\KnownDlls\kernel32.dll* section with `SECTION_MAP_WRITE` in access mask. and fail here, because it require write access, but this section have `Low Mandatory Level` but not `untrusted`. – RbMm May 17 '17 at 15:24
  • As far as I understand, in order to have an untrusted process, you need first to create it as low integrity, let it do it's work that requires higher mandatory level (like loading dlls), and than to turn it to be untrusted. However I didn't try it myself. – macro_controller May 17 '17 at 15:34
  • yes, this can work, but however what is your target goal ? `Is there a place where an untrusted integrity level process can create named objects` - this must be folder with `Untrusted Mandatory Level` - if i not mistake (need check) - no default folders in windows NT namespace with this. you need be create it yourself. and for 2.) - for read only access we can open object with any label. but for write access need untrusted label. if you got `0xc0000022` when assign sid with this label - some error in your code – RbMm May 17 '17 at 15:42
  • Untrusted is precisely that, a level that has permissions to do exactly nothing itself. Usually a parent process with higher integrity would create any objects that the child would need and then explicitly pass them to the child process after setting permissions as part of start up. The [Chromium source](https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md) should have a good example of this. – Mgetz May 17 '17 at 19:08

1 Answers1

4

Is there a place where an untrusted integrity level process can create named objects? (mutexes, events, etc..)

by default - no. code with untrusted token (thread or process) can create object only in directory with Untrusted Mandatory Level - no one standard folders have this kind of label. some have Low Mandatory Level but untrusted - no.

but you can easy create this folder yourself. with Untrusted Mandatory Level and NULL DACL - untrusted code can create objects in this folder. 

NTSTATUS CreateUntrustedFolder(PHANDLE phObject, PCUNICODE_STRING ObjectName)
{
    ULONG cb = MAX_SID_SIZE;
    PSID UntrustedSid = (PSID)alloca(MAX_SID_SIZE);
    if (CreateWellKnownSid(WinUntrustedLabelSid, 0, UntrustedSid, &cb))
    {
        PACL Sacl = (PACL)alloca(cb += sizeof(ACL) + sizeof(ACE_HEADER) + sizeof(ACCESS_MASK));
        InitializeAcl(Sacl, cb, ACL_REVISION);
        if (AddMandatoryAce(Sacl, ACL_REVISION, 0, 0, UntrustedSid))
        {
            SECURITY_DESCRIPTOR sd;
            InitializeSecurityDescriptor(&sd, SECURITY_DESCRIPTOR_REVISION);
            SetSecurityDescriptorDacl(&sd, TRUE, NULL, FALSE);
            SetSecurityDescriptorSacl(&sd, TRUE, Sacl, FALSE);

            OBJECT_ATTRIBUTES oa = { sizeof(oa), 0, (PUNICODE_STRING)ObjectName, OBJ_CASE_INSENSITIVE|OBJ_OPENIF, &sd };

            return ZwCreateDirectoryObject(phObject, DIRECTORY_ALL_ACCESS, &oa);
        }
    }

    return STATUS_UNSUCCESSFUL;
}

about untrusted code creation - if start process at begin with token marked as untrusted integrity level - process fail to start. this when ntdll.dll try load kernel32.dll - it try open section \KnownDlls\kernel32.dll with SECTION_MAP_WRITE as well , but this object have Low Mandatory Level with SYSTEM_MANDATORY_LABEL_NO_WRITE_UP - as result untrusted code fail open this section with write access.

as result you need initially create process say with Low Mandatory Level and then set untrusted level

ULONG SetProcessUntrusted(HANDLE hProcess)
{
    TOKEN_MANDATORY_LABEL tml = { { (PSID)alloca(MAX_SID_SIZE), SE_GROUP_INTEGRITY } };

    ULONG cb = MAX_SID_SIZE;

    HANDLE hToken;

    if (!CreateWellKnownSid(WinUntrustedLabelSid, 0, tml.Label.Sid, &cb) ||
        !OpenProcessToken(hProcess, TOKEN_ADJUST_DEFAULT, &hToken))
    {
        return GetLastError();
    }

    ULONG dwError = NOERROR;
    if (!SetTokenInformation(hToken, TokenIntegrityLevel, &tml, sizeof(tml)))
    {
        dwError = GetLastError();
    }

    CloseHandle(hToken);

    return dwError;
}

Should untrusted integrity level process be able to open an existing named object

this depend from object label(level and mask) , code intergrity level and required access. if code intergrity level >= object label level - we can open object (if dacl let do this). otherwise need look for object label mask and required access. for example object have Low Mandatory Level with SYSTEM_MANDATORY_LABEL_NO_WRITE_UP and code Untrusted Mandatory Level - this code can open object with read and execute access, but fail open it for write access

RbMm
  • 31,280
  • 3
  • 35
  • 56
  • 1
    From [ZwCreateDirectoryObject](https://msdn.microsoft.com/en-us/library/windows/hardware/ff566421.aspx): *"If the call to this function occurs in user mode, you should use the name "**NtCreateDirectoryObject**" instead of "**ZwCreateDirectoryObject**"."* – IInspectable May 18 '17 at 13:55
  • @IInspectable - in user mode absolute no different between *Nt* an *Zw* - this is alias - both names always point to same address. in kernel mode different is huge - *Zw* is thunk which reenter kernel and *Nt* is actual function. why in documentation written that in user mode need use *Nt* variant (when this is the same as *Zw* here) - i don't know. you think microsoft can remove *Zw* export from *ntdll.dll* and left only *Nt* exported names ? this is only reason which can explain this note. i however include *wdm.h* in own code. here *ZwCreateDirectoryObject* only is declared. so i use it – RbMm May 18 '17 at 14:37
  • I don't argue about the virtues of adhering to a written contract. If you do, you need to provide a **much** stronger rationale, why this is a Good Thing. The fact that it happens to work is pretty weak, and mis-documenting code along the way is right out wrong. – IInspectable May 18 '17 at 14:48
  • @IInspectable - this is interesting. at first this info is relative recently in MSDN. yearly no was this. look like it [added to all](https://www.google.co.uk/#q=%22If+the+call+to+this+function+occurs+in+user+mode,+you+should+use+the+name%22) api. but how about **all** ntdll api is **unsupported** in user mode ? now *Nt* names *became* **supported** already and it can legal call ? if i in some code snippet call for example `NtOpenFile` instead `CreateFileW` - you will be not comment that this is not legal and not supported in user mode ? – RbMm May 18 '17 at 14:55
  • @conio - you confuse **kernel mode** versions of *Nt/Zw* api from **ntoskrnl.exe** and **user mode** versions of this api from **nrdll.dll** - in kernel mode *Nt* this is real function when *Zw* is stub, which reenter kernel and call *Nt* function. but in **user mode** - *Nt* and *Zw* is **alias** - both names point to the **same** function. so no different which call *Nt* ot *Zw* variant from **user mode**. only if in future *MS* not plan remove *Zw* export from **ntdll.dll** and funny that *MS* yourself in many examples use *Zw* version in user mode. – RbMm Jun 03 '17 at 23:30
  • look for example [this](https://msdn.microsoft.com/library/windows/desktop/mt809132(v=vs.85).aspx) msdn page - note here `ZwQueryInformationProcess` - but why not `NtQueryInformationProcess` ? @conio - not want report bug for msdn ? and are you windows kernel developer ? you yourself use this api in kernel/user mode ? – RbMm Jun 03 '17 at 23:32
  • @conio - and your link - **only for kernel mode version** - Zw/Nt - all what here said - related only to kernel mode. while here we have **user mode** code – RbMm Jun 03 '17 at 23:34
  • `That's an interesting interpretation of what the page says, but certainly not the only one. Not even the obvious one` - what page - your first link ? no any interpretation. this page for windows kernel **only**. here nothing said about user mode **implementation** - `When a user-mode application calls the Nt or Zw version of a native system services routine, the routine..` - may be this confuse you - but here again said about routine **in kernel** - kernel version of Nt/Zw api which invoked when `user-mode application calls the Nt or Zw` – RbMm Jun 03 '17 at 23:40
  • @conio - and yes, not good enough write on english. but however what i wrote - possible understand, if you yourself was windows **kernel mode** developer. – RbMm Jun 03 '17 at 23:42
  • @conio - this is you **nothing understand** in last paragraph said that *NtNotifyChangeKey* - have **different semantic** depended from previous mode ! – RbMm Jun 03 '17 at 23:45
  • @conio - you are **not kernel mode developer** and you **never** call *ZwNotifyChangeKey* or *NtNotifyChangeKey* version of this api **from kernel mode** (i call and not once) - you still cannot understand that when called from user mode the *ZwNotifyChangeKey* and *NtNotifyChangeKey* in ntdll - this is **ONE** function. it the **SAME**. in **user mode NO AND CAN NOT BE DIFFERENCE** - this is aliases. exist **HUGE DIFFERENCE IN kernel mode**. the *NtNotifyChangeKey* from **ntoskrnl.exe** work differently based on **PreviousMode.** – RbMm Jun 03 '17 at 23:50
  • all what said here - that **ntoskrnl!NtNotifyChangeKey** depending on whether the parameters are from a user-mode or kernel-mode source ( more exactly depending on [PreviousMode](https://msdn.microsoft.com/en-us/library/windows/hardware/ff559860(v=vs.85).aspx)) different interpret and use arguments – RbMm Jun 03 '17 at 23:58
  • and need clear understand that ntdll.dll and ntoskrnl.exe - different modules.all what said [here](https://msdn.microsoft.com/en-us/library/windows/hardware/ff565438(v=vs.85).aspx) related **only** to ntoskrnl.exe export. nothing said about ntdll.dll – RbMm Jun 04 '17 at 00:01