The Final Stream

Google Chrome and the Chromium Sandbox

2008-09-02T21:38:00.000-07:00

Chromium is finally out!! This is the moment I've been waiting for. I can now share the details of the project I've been working on: The Chromium sandbox.

As you know, Chromium is open source, so is its sandbox. I welcome everyone to take a look at the code, contribute patches, suggest improvements, find security bugs and most importantly, USE IT. Yes, the sandbox is not tied to chromium; it can be easily reused by any projects in need of a sandboxing solution. In the next posts I will present different parts of the Chromium sandbox in details, and I will be talking more about how to integrate the sandbox with any application.

Before going into the details, you must understand the high level architecture of Chromium, and what part of it is running in the sandbox. The best way to learn about this is to read the comic book!

The official website also has a lot of good information on Chromium and the sandbox, like our design document.

This is it for now! Try Google Chrome!

I'll be back with more information about the sandbox soon!

Namedpipe Impersonation Attack

2008-01-20T16:54:00.000-08:00

Privilege escalation through namedpipe impersonation attack was a real issue back in 2000 when a flaw in the service control manager allowed any user logged onto a machine to steal the identify of SYSTEM. We haven't heard a lot about this topic since then, is it still an issue?

First of all, let's talk about the problem.

When a process creates a namedpipe server, and a client connects to it, the server can impersonate the client. This is not really a problem, and is really useful when dealing with IPC. The problem arises when the client has more rights than the server. This scenario would create a privilege escalation. It turns out that it was pretty easy to accomplish.
For example, let's assume that we have 3 processes: server.exe, client.exe and attacker.exe. Server.exe and client.exe have more privileges than attacker.exe. Client.exe communicates with server.exe using a namedpipe. If attacker.exe manages to create the pipe server before server.exe does, then, as soon as client.exe connects to the pipe, attacker.exe can impersonate it and the game is over.

Fortunately, Microsoft implemented and recently documented some restrictions and tools to help you manage the risk.

First of all there are some flags buried in the CreateFile documentation to give control to the pipe client over what level of impersonation a server can perform. They are called the "Security Quality Of Service".

There are 4 flags to define the impersonation level allowed.

SECURITY_ANONYMOUS
The server process cannot obtain identification information about the client, and it cannot impersonate the client.

SECURITY_IDENTIFICATION
The server process can obtain information about the client, such as security identifiers and privileges, but it cannot impersonate the client. ImpersonateNamedpipeClient will succeed, but no resources can be acquired while impersonating the client. The token can be opened and the information it contains can be read.

SECURITY_IMPERSONATION - This is the default
The server process can impersonate the client's security context on its local system. The server cannot impersonate the client on remote systems.

SECURITY_DELEGATION
The server process can impersonate the client's security context on remote systems.

There are also 2 other flags:

SECURITY_CONTEXT_TRACKING
Specifies that any changes a client makes to its security context is reflected in a server that is impersonating it. If this option isn't specified, the server adopts the context of the client at the time of the impersonation and doesn't receive any changes. This option is honored only when the client and server process are on the same system.

SECURITY_EFFECTIVE_ONLY
Prevents a server from enabling or disabling a client's privilege or group while the server is impersonating.

Note: Since the MSDN documentation for these flags is really weak, I used the definition that can be found in the book "Microsoft® Windows® Internals, Fourth Edition" by Mark Russinovich and David Solomon.

Every time you create a pipe in client mode, you need to find out what the server needs to know about you and pass the right flags to CreateFile. And if you do, don't forget to also pass SECURITY_SQOS_PRESENT, otherwise the other flags will be ignored.

Unfortunately, you don't have access to the source code of all the software running on your machine. I bet there are dozen of software running on my machine right now opening pipes without using the SQOS flags. To "fix" that, Microsoft implemented some restrictions about who a server can impersonate in order to minimize the chances of being exploited.

A server can impersonate a client only if one of the following is true.

The caller has the SeImpersonatePrivilege privilege.

The requested impersonation level is SecurityIdentification or SecurityAnonymous.

The identity of the client is the same as the server.

The token of the client was created using LogonUser from inside the same logon session as the server.

Only Administrators/System/SERVICES have the SeImpersonatePrivilege privilege. If the attacker is a member of these groups, you have much bigger problems.

The requested impersonation level in our case is SecurityImpersonation, so the second point does not apply.

That leaves us with the last two conditions. Should we worry about them? I think so. Here are some examples:

I'm on XP. I want to run an untrusted application. Since I read my old posts, I know that I can run the process using a stripped down version of my token. Unfortunately, my restricted token has the same identity as the normal token. It can then try to exploit all applications running on my desktop. This is bad.

My main account is not administrator on the machine. When I want to install software, I use RunAs. This brings up a new problem. RunAs uses LogonUser, and it is called from the same logon session! That means that my untrusted application using a restricted token derived from a standard user token can now try to exploit and impersonate a process running with administrator rights! This is worse.

But how real is all this?

This is hard to say. I don't have an idea about the percentage of applications using the SQOS flags. We must not forget that allowing impersonation is also required and desired in certain cases.

For fun I took the first application using namedpipes that came to my mind: Windbg. There is an option in Windbg to do kernel debugging and if the OS you are debugging is inside vmware, you can specify the namedpipe corresponding the COM1 port of the vmware image. By default it is "com_1". My untrusted application running with the restricted token was now listening on com_1, and, easy enough, as soon as I started windbg, the untrusted application was able to steal its token.

To be fair I have to say that vmware displayed an error message telling me that the com_1 port was "not configured as expected". I should not have started windbg knowing that. But, eh, who reads error messages? :)

What should we do now?

Well, it turns out that Microsoft implemented two new restrictions in windows Vista to fix these problems. I don't think they are documented yet.

If the token of a server is restricted, it can impersonate only clients also running with a restricted token.

The server cannot impersonate a client running at a higher integrity level.

These new restrictions are fixing both my issues. First of all my untrusted application can't be running with a restricted token anymore. Then, even if the untrusted application is running with my standard token, it won't be able to impersonate the processes that I start with the "Run As Administrator" elevation prompt because they are running with a High Integrity Level.

Now it is time to come back to the main question: Is it still an issue?

My answer is yes. Windows XP is still the most popular Windows version out there and there is no sign that Vista is going to catch up soon. But I have to admit that I'm relieved to see the light at the end of the tunnel!

--

Some technical details:
When you call ImpersonateNamedPipeClient and none of the conditions is met, the function still succeeds, but the impersonation level of the token is SecurityIdentification.

If you want to try for yourself, you can find the code to create a server pipe and a client pipe on my code page.

Related link:
Impersonation isn't dangerous by David Leblanc

DuplicateHandle and Access Mask.

2008-01-20T10:06:00.000-08:00

In the DuplicateHandle MSDN documentation there is not a lot of information about the Access Mask that can be passed to DuplicateHandle.

What happens if you ask for MAXIMUM_ALLOWED?

The function succeeds, but the handle created does not have any granted access. This is not really useful.

Not all object types support the same flags in an access mask, what happens if you specify a mask that contains invalid flags?

It depends...

The function fails if you use any of these flags:


      0x00200000 = Unused standard right
      0x00400000 = Unused standard right
      0x00800000 = Unused standard right
      0x01000000 = ACCESS_SYSTEM_SECURITY [You need a privilege]
      0x04000000 = Reserved
      0x08000000 = Reserved

But if you don't, any other invalid flags are ignored and the call succeeds. The granted access is the union of all the valid flags present in the mask. It also means that if you duplicate the handle using invalid flags only, the handle will be created without any granted access.

That said, in my previous post I talked about why you should not use PROCESS_ALL_ACCESS anymore on Windows XP. This is not true for the DuplicateHandle call, you can still use it since the new flag 0xF000 will be ignored on previous version of the OS.

WINVER Mayhem. The PROCESS_ALL_ACCESS problem.

2008-01-12T11:17:00.000-08:00

If you are like me, you want to develop Windows applications that work on all the major versions of Windows. At the moment it is Windows Vista, Windows XP SP2 and maybe Windows 2000 SP4. You also want to use the new features introduced in the new versions.

Suppose that you want to use a something that is defined only when you have _WIN32_WINNT=0x600. What do you do?

There are 3 options:

1. Copy the definition manually to one of your file. This is not clean. I hope I won't have to do this.

2. Create one build per OS version. Each of them will define _WIN32_WINNT accordingly and you just have to be sure that the code specific to an OS version is inside an #IF _WIN32_WINNT >= VERSION. This makes sense, but this is a lot of troubles. Who wants to have multiple sets of exes and dlls and ship different binaries depending on the user configuration.

3. Define _WIN32_WINNT to the highest value (0x0600 for Vista in this case), and make sure that you don't use unsupported functions/structures on previous version. You need to use GetVersionEx to get the OS version and use GetProcAddress to get the address of the functions that are not defined in prior versions.

The third option is the one that I've seen most of the time. Unfortunately, changing the value of _WIN32_WINNT to 0x0600 is causing some unexpected problems.

One example is the define for PROCESS_ALL_ACCESS. It looks like this:


#if (NTDDI_VERSION >= NTDDI_LONGHORN)
#define PROCESS_ALL_ACCESS (STANDARD_RIGHTS_REQUIRED | SYNCHRONIZE | \
0xFFFF)
#else
#define PROCESS_ALL_ACCESS (STANDARD_RIGHTS_REQUIRED | SYNCHRONIZE | \
0xFFF)
#endif

They changed the mask on Vista to include 0xF000. 0xF000 contains 3 unused flags and the new PROCESS_QUERY_LIMITED_INFORMATION.

Why is this a problem?

Suppose that your code is doing this:


     OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);

This call is now going to fail on XP and 2000 because you are trying to open a process with 0xF000, and you don't have that access on the process.

You need to fix all PROCESS_ALL_ACCESS occurences in your code. The same problem exists with THREAD_ALL_ACCESS.

What would have been a better solution? I thought PROCESS_QUERY_LIMITED_INFORMATION was only a subset of PROCESS_QUERY_INFORMATION already present in the mask. Did they really need to add it? Could they have used GENERIC_ALL instead? As we saw in this earlier post, GENERIC_ALL can mean different things on different OS versions.

More GENERIC_MAPPING changes on vista

2008-01-06T18:56:00.000-08:00

In my last post I talked about the change in the generic mapping of the Process type. It turns out that Thread, Token and Key also changed on Vista.

For reference, these are the changes:


TOKEN:
                   Windows XP          Windows Vista
+-----------------+-------------------+---------------------------+
 GENERIC_EXECUTE   READ_CONTROL        READ_CONTROL
                                       ASSIGN_PRIMARY
                                       IMPERSONATE
+-----------------+-------------------+---------------------------+
 GENERIC_READ      READ_QUERY          READ_QUERY
                   READ_CONTROL        READ_CONTROL
                                       DUPLICATE
                                       QUERY_SOURCE
+-----------------+-------------------+---------------------------+
 GENERIC_WRITE     ADJUST_PRIVILEGES   ADJUST_PRIVILEGES
                   ADJUST_GROUPS       ADJUST_GROUPS
                   ADJUST_DEFAULT      ADJUST_DEFAULT
                   READ_CONTROL        READ_CONTROL
                                       ADJUST_SESSIONID
+-----------------+-------------------+---------------------------+
Note: The TOKEN_ prefix has been removed.
 
 
 
THREAD:
                    Windows XP          Windows Vista
+-----------------+-------------------+---------------------------+
 GENERIC_EXECUTE   READ_CONTROL        READ_CONTROL
                   SYNCHRONIZE         SYNCHRONIZE
                                       QUERY_LIMITED_INFORMATION
+-----------------+-------------------+---------------------------+
 GENERIC_READ      GET_CONTEXT         GET_CONTEXT
                   QUERY_INFORMATION   QUERY_INFORMATION
                   READ_CONTROL        READ_CONTROL
+-----------------+-------------------+---------------------------+
 GENERIC_WRITE     TERMINATE           TERMINATE
                   SUSPEND_RESUME      SUSPEND_RESUME
                   SET_CONTEXT         SET_CONTEXT
                   SET_INFORMATION     SET_INFORMATION
                   READ_CONTROL        READ_CONTROL
                   0x00000004          0x00000004
                                       SET_LIMITED_INFORMATION
+-----------------+-------------------+---------------------------+
Note: The THREAD_ prefix has been removed.
  
 
 
KEY:
                    Windows XP          Windows Vista
+-----------------+-------------------+---------------------------+
 GENERIC_EXECUTE   QUERY_VALUE         QUERY_VALUE
                   ENUMERATE_SUB_KEYS  ENUMERATE_SUB_KEYS
                   NOTIFY              NOTIFY
                   READ_CONTROL        READ_CONTROL
                                       CREATE_LINK
+-----------------+-------------------+---------------------------+
 GENERIC_READ      QUERY_VALUE         QUERY_VALUE
                   ENUMERATE_SUB_KEYS  ENUMERATE_SUB_KEYS
                   NOTIFY              NOTIFY
                   READ_CONTROL        READ_CONTROL
+-----------------+-------------------+---------------------------+
 GENERIC_WRITE     SET_VALUE           SET_VALUE
                   CREATE_SUB_KEY      CREATE_SUB_KEY
                   READ_CONTROL        READ_CONTROL
+-----------------+-------------------+---------------------------+
Note: The KEY_ prefix has been removed.

You want to dump the GENERIC_MAPPING structure for other object types? You can find the code on http://nsylvain.googlepages.com/.

You can terminate a higher integrity process.

2008-01-06T16:20:00.000-08:00

Integrity levels have been publicized a lot like a "No-Write-Up" technology. It means that you can't write to objects with a higher integrity level than your token. But there is more to it. Microsoft also implemented "No-Read-Up" and "No-Execute-Up" and you can use them on your objects. It is even used today for processes, by default they have a No-Read-Up and No-Write-Up mandatory label. It would have been too much of a security hole to be able to read the process memory of a higher integrity level process.

No-Execute-Up is not present though. What does it buy us?

If it was on Windows XP, then not much, but on Vista the Generic Mapping structures have changed. Let's take a look at them side by side for the "Process" object type on XP and Vista.


                   Windows XP          Windows Vista
+-----------------+-------------------+---------------------------+
 GENERIC_EXECUTE   READ_CONTROL        READ_CONTROL
                   SYNCHRONIZE         SYNCHRONIZE
                                       TERMINATE
                                       QUERY_LIMITED_INFORMATION
+-----------------+-------------------+---------------------------+
 GENERIC_READ      VM_READ             VM_READ
                   QUERY_INFORMATION   QUERY_INFORMATION
                   READ_CONTROL        READ_CONTROL
+-----------------+-------------------+---------------------------+
 GENERIC_WRITE     CREATE_THREAD       CREATE_THREAD
                   VM_OPERATION        VM_OPERATION
                   VM_WRITE            VM_WRITE
                   DUP_HANDLE          DUP_HANDLE
                   CREATE_PROCESS      CREATE_PROCESS
                   SET_QUOTA           SET_QUOTA
                   SET_INFORMATION     SET_INFORMATION
                   SUSPEND_RESUME      SUSPEND_RESUME
                   READ_CONTROL        READ_CONTROL
                   TERMINATE
+-----------------+-------------------+---------------------------+
note: the prefix PROCESS_ has been removed.
http://msdn2.microsoft.com/en-us/library/ms684880(VS.85).aspx

As you can see GENERIC_EXECUTE has changed and now gives TERMINATE access. You can then kill processes with a higher integrity level!

For completeness, PROCESS_QUERY_LIMITED_INFORMATION allows you to query the full process image name.

The integrity drop - or - How to disable UIPI take 2

2008-01-05T10:06:00.000-08:00

On vista if you create a process with a low integrity level token, the User Interface Privilege Isolation (UIPI) will prevent it from talking to windows owned my medium/high integrity level processes.

What if you don't want that? Maybe you already have another plan for UI protection? Running in a job for example.

There is the easy way: [From MSDN]

By specifying UIAccess=”true” in the requestedPrivileges attribute [of the application manifest], the application is stating a requirement to bypass UIPI restrictions on sending window messages across privilege levels. Windows Vista implements the following policy checks before starting an application with UIAccess privilege.
The application must have a digital signature that can be verified using a digital certificate that chains up to a trusted root in the local machine Trusted Root
Certification Authorities certificate store.
The application must be installed in a local folder application directory that is writeable only by administrators, such as the Program Files directory.

Unfortunately this is not going to work if you application can be installed by non-admin users.

Fortunately, there is another (not documented) way to "disable" UIPI.

Windows initializes UIPI during the process startup. If you create the process with a low integrity level, then UIPI will prevent it from accessing windows owned by medium/high integrity level processes.

But no one said that it was not possible to change the integrity level of a process AFTER it is started. If you own the process, and you trust that it's not going to run any potentially malicious piece of code before main(), you can add code at the beginning of your main() to drop the integrity level. From now on, the process is going to run with the new integrity level and UIPI won't be updated.

Dropping the integrity level is easy:

Get a handle to the process token using OpenProcessToken and call SetTokenInformation on it with the TokenIntegrityLevel information class to set the new integrity level.

But this is not all. If you only do this, your process won't be able to play sound. This is because when you play sound, audiodg.exe creates some objects on your behalf. At some point it will impersonate your token and open your process. Since your process was created with a medium integrity level token, the integrity/mandatory label on the process is Medium. When audiodg tries to open your process with your token, it does not have access and it fails.

What you must do is change the security label on the process to be low integrity level. The easy way to do this is to create a SDDL string for the integrity label and to follow the code in this example. You should use this SDDL string: "S:(ML;;NWNR;;;LW)" It means that it's a SDDL for a SACL (S:), with a Mandatory Label ace type (ML), the ace access is No-Write-Up and No-Read-Up (NWNR) and the integrity level is low (LW). The example is using NW instead of NWNR but for a process it's better to prevent lower privileges processes from being able to read it's process memory.

SetWindowsHookEx and Restricted Token

2008-01-05T08:53:00.000-08:00

One easy way on Windows to inject a DLL is to use SetWindowsHookEx.

From MSDN:

The SetWindowsHookEx function installs an application-defined hook procedure
into a hook chain. You would install a hook procedure to monitor the system for
certain types of events. These events are associated either with a specific
thread or with all threads in the same desktop as the calling thread.

When the event you are interested in is triggered for the first time in a process, your DLL is going to get loaded and your hook procedure will be called. For example, if you set a mouse hook, the DLL is going to get loaded in the process as soon as you move the mouse over a window owned by this process.

But the desktop is not a perfect security boundary. You can have applications on the desktop running as a different users, with different rights. You can also have some applications running as a restricted version of yourself. How can we ensure that an application can't use SetWindowsHookEx to elevate it's privilege?

There are multiple answers.

First of all you can put this application on a job object and set the UILIMIT_HANDLES restriction. With this restriction a process in the job object can set hooks only on processes that are also in the job. But setting this flag also means that you can't access any user handles (HWND, etc) created by processes not associated with the job. If your application has some UI, then you have a lot of work to do if you want to fix everything that is going to break! (No icons, no cursors, can't access the desktop window). UserHandleGrantAccess can help you here...

On vista it's a little bit easier, you can run the application with a low integrity level token and User Interface Privilege Isolation (UIPI) will do the work for you. Internet Explorer 7 is using it to be more secure. It will prevent your application from setting hooks on other applications running with a higher integrity level.

What if you can't use any of them? Well, if your application is running with a restricted token, you may not have to worry about this at all. A restricted token is a stripped down version of your token created with the CreateRestrictedToken api. The SidsToRestrict array passed to the function must be non-null. In other words, IsTokenRestricted must return true. If this is the case, Windows will do the right thing and will not trust your application if you try to set a hook.

I haven't found any documentation on this... but during my tests I have seen two different behaviors:

For some hooks (WH_MOUSE for example), when the event is received in another process, instead of loading the DLL, it sends a message to the thread that registered the hook. The message is handled internally and will cause the hook procedure to be called. Your application is now receiving and parsing all the events from all processes by itself in its own process. That does not sounds very efficient to me, but at least it's not a security flaw. (Don't quote me on this)
For some other hooks (WH_CALLWNDPROC for example), the event seems to be ignored and the hook procedure is never called.

I haven't done a lot of testing so far on this, but it seems like a thread running with a restricted token can't inject a DLL using SetWindowsHookEx, which is good.

One warning: If you try to do this, there is a nasty side effect. Since the events are now sent to the calling thread using window messages, you must have a message loop, otherwise your system is going hang! I don't think there was any requirement before that the caller of SetWindowsHookEx have to peek messages.

Old Old New Thing

2007-09-22T09:32:00.000-07:00

Today I was trying to catch up with all the new entries on Raymond's blog and I found some interesting posts that are worth taking a look.

What do I do with per-user data when I uninstall?

Microsoft says... oh wait... I mean.. Raymond Chen says that we should not touch it! Quick and Easy! I like that :)

Why isn't QuickEdit on by default in console windows?

Because it breaks console mode applications using the mouse.

Does creating a thread from DllMain deadlock or doesn't it?

It does not. Except if you create the lock yourself by waiting for the thread to do something, because it's not going to run until you exit DllMain.

Handle Format

2007-09-02T19:37:00.001-07:00

A couple of posts ago I talked about how to get the list of all open handles. When I started playing with that it did not work at the first try, so I had to use the brute force method to get all the handles in the current process. The code was doing a loop like this:


for (LONG_PTR h = 0; h < 0xFFFF; ++h) {
  HANDLE handle = (HANDLE)(h);
  DoSomething(handle);
}

The result was unexpected to me. All handles in the process were duplicated 4 times. It looks like the lowest 2 bits in the handle value are ignored.

If the handle to a file is 0x7C then you can use 0x7C, 0x7D, 0x7E or 0x7F to access the file.

Is this documented somewhere?

Updated on 9/3/2007:
I was talking with Ivanlef0u about this and my assumption that the last 2 bits are ignored is right. He showed me the disassembly of the function to lookup the object in the handle table and it looks like this:


ExpLookupHandleTableEntry
mov edi, edi
push ebp
mov ebp, esp
and [ebp+Handle], 0FFFFFFFCh ; Unset the last 2 bits
mov eax, [ebp+Handle]
mov ecx, [ebp+HandleTable]
mov edx, [ebp+Handle]
shr eax, 2 ; Shift right the last 2 bits
cmp edx, [ecx+38h] ; HandleTable->NextHandleNeedingPool
jnb loc_49DDF8

Thanks Ivanlef0u.

Using Visual Studio to debug your token.

2007-09-02T15:21:00.000-07:00

For as long as I remember I have been using TokenMaster to be able to see and dump the information contained in my access tokens.
Recently greggm blogged about another way to get this information. This is now integrated in the visual studio debugger. Just type "$user" in the watch window and you will get a complete view of the current token.

Updated on 9/4/2007
Thanks to Marc-Antoine Ruel for the information, Windbg also does that! Just type this command to get the same information:


      !token -n

How to list all the open handles?

2007-09-02T11:26:00.000-07:00

Recently I had to get the list of all the handles open in a process. I searched on the web to find a good way to do it, and realized that most of the articles I found are wrong.

I guess this is because the documentation in "Windows NT/2000 Native API Reference" by Gary Nebbett is a little bit misleading.

Under the SystemHandleInformation class, the structure defined is:


typedef struct _SYSTEM_HANDLE_INFORMATION {
  USHORT ProcessId;
  USHORT CreatorBackTraceIndex;
  UCHAR ObjectTypeNumber;
  UCHAR Flags;
  USHORT Handle;
  PVOID Object;
  ACCESS_MASK GrantedAccess;
} SYSTEM_HANDLE_INFORMATION, *PSYSTEM_HANDLE_INFORMATION;

One could think that the buffer returned is actually a list of structures like this one. But this is not the case, it's actually returning a structure like this one:


typedef struct _SYSTEM_HANDLE_INFORMATION_EX {
  ULONG NumberOfHandles;
  SYSTEM_HANDLE_INFORMATION Information[1];
} SYSTEM_HANDLE_INFORMATION_EX, *PSYSTEM_HANDLE_INFORMATION_EX;

Even though the description in the book is misleading, Gary Nebbett is not wrong. There is a remark saying: "The data returning to the SystemInformation buffer is a ULONG count of he number of handles followed immediately by an array of SYSTEM_HANDLE_INFORMATION".

There is another factor making this task a little bit more complex to achieve: The function is really picky about the buffer size.

Usually you can call the function with a NULL buffer and 0 for the size and then get back the size you need to allocate your buffer. This does not work here. The return value is 0xC0000004 : The specified information record length does not match the length required for the specified information class.

If you try with a SYSTEM_HANDLE_INFORMATION buffer, it won't work either. You need to pass to the function a buffer large enough to hold the number of handles and the first handle if you want to get the size needed back. This is a little bit weird.

Finally, the code:


  // Get the number of handles on the system
  DWORD buffer_size = 0;
  SYSTEM_HANDLE_INFORMATION_EX temp_info;


  NTSTATUS status = NtQuerySystemInformation(
      SystemHandleInformation, &temp_info, 
      sizeof(temp_info), &buffer_size);


  SYSTEM_HANDLE_INFORMATION_EX *system_handles =
    (SYSTEM_HANDLE_INFORMATION_EX*)(new BYTE[buffer_size]);


  status = NtQuerySystemInformation(SystemHandleInformation,
                                    system_handles,
                                    buffer_size, &buffer_size);


  printf("nb of handles = %d", system_handles->NumberOfHandles);

sizeof Cheat Sheet

2007-08-09T16:10:00.000-07:00

It's hard to justify why this kind of cheat sheet is necessary. We should all know this information by heart. Unfortunately I realize that sometimes I'm not 100% sure and I have to look it up. If it happens again, then I'll come back here!

The size of the different types is in bytes.


                win64  win32
-------------------------------
bool              1      1
BYTE              1      1
char              1      1
-------------------------------
SHORT             2      2
wchar_t           2      2
WORD              2      2
-------------------------------
BOOL              4      4
DWORD             4      4
float             4      4
HRESULT           4      4
int               4      4
long              4      4
unsigned int      4      4
unsigned long     4      4
-------------------------------
HANDLE            8      4
INT_PTR           8      4
LONG_PTR          8      4
ULONG_PTR         8      4
void*             8      4
-------------------------------
__int64           8      8
double            8      8
LONGLONG          8      8
ULONGLONG         8      8
-------------------------------
FLOAT128         16     16
-------------------------------

ThreadHideFromDebugger! But Why?

2007-08-08T20:50:00.001-07:00

At BlackHat last week Mark Vincent Yason talked about the art of unpacking. One of the techniques used by some packers is to hide their threads from the debugger so it can't be easily debugged.

It is really easy to hide a thread from the debugger, you just have to call :

NtSetInformationThread(hThread, ThreadHideFromDebugger, NULL, 0);

At this point the debugger will stop receiving debug information or exceptions from this thread. But be careful! If you are debugging the process and you set a breakpoint and it happens to hit in the hidden thread, the process will crash and windbg won't even realize it.

After the presentation I was not able to stop asking myself why did Microsoft implemented this feature. It seems like the only usage is to make "malicious" code harder to debug. Maybe they implemented it to mute some noisy threads? Or maybe they wanted to protect some system threads? If you know the answer, please let me know!

The next thing to do was to check if Microsoft is in fact using this feature. I put a conditional breakpoint on NtSetInformationThread to hit when the ThreadInformationClass is equal to ThreadHideFromDebugger.
Unfortunately it never hit. (Tested on XPSP2 and Vista). There is also the possibility that they are changing the ETHREAD structure manually, but I doubt so. I'll try to check that later.

On the other hand, something interesting came up during this experiment. On Vista it seems like NtSetInformationThread is called really often with an invalid (or undocumented) ThreadInformationClass. I'll try to investigate that and write my results in another post. In the mean time, I dumped the number of occurrences of each ThreadInformationClass during the boot of windows. I haven't found any use for that yet, but anyway:

Windows XP SP2

   4 ThreadPriority
  16 ThreadBasePriority
   2 ThreadAffinityMask
2069 ThreadImpersonationToken
  16 ThreadQuerySetWin32StartAddress
  16 ThreadZeroTlsCell

Windows VISTA

  16 ThreadPriority
 490 ThreadBasePriority
   4 ThreadAffinityMask
6293 ThreadImpersonationToken
  71 ThreadZeroTlsCell
   1 ThreadPriorityBoost
 460 Unknown - 0x16
 481 Unknown - 0x18
  10 Unknown - 0x19

David LeBlanc @ BlackHat : Practical Windows Sandboxing

2007-08-06T19:57:00.000-07:00

One of the main reasons I went to BlackHat last week was for David LeBlanc and his presentation about windows sandboxing. Unfortunately I missed it. I really don't know what happened. David was the last one of a series of three 20minute talks. I was there for the first two but it looked like they cancelled both of them. Thinking that they cancelled the series, I left the room and went to see the fuzzing talk by Pedram Amini (Very interesting by the way).

Fortunately David blogged about his presentation:

Part 1:

http://blogs.msdn.com/david_leblanc/archive/2007/07/27/practical-windows-sandboxing-part-1.aspx
Part 2:

http://blogs.msdn.com/david_leblanc/archive/2007/07/30/practical-windows-sandboxing-part-2.aspx
Part 3:

http://blogs.msdn.com/david_leblanc/archive/2007/07/31/practical-windows-sandboxing-part-3.aspx

This is actually really interesting and it's awesome that restricted tokens and job objects are now used for sandboxing by Microsoft. I really wish I hadn't missed this talk!

Why you should not trust CreateProcess' PROCESS_INFORMATION

2007-08-04T19:33:00.000-07:00

At GreenBorder I was working on a complex multi-process application with a lot of interactions between the processes through IPC and DuplicateHandle. The processes were created with CreateProcess. This call returns a PROCESS_INFORMATION structure containing the process ID of the newly created process, the thread ID of the main thread along with their handles.

I was using the structure to initialize my IPC and was using the process handle to duplicate some others handles into this new process.

Everything sounds good right? Wrong!

The problems started happening the first time I had to debug a complex bug. Since this is a multi-process architecture, the easiest/best solution to debug the child processes is to set the Image File Execution for the process to start your favorite debugger (Windbg in this case) automatically. Unfortunately it turned out to be a lot worse. After a little while I discovered that the PROCESS_INFORMATION structure returned by CreateProcess was not containing the information about my process... but the information about the debugger! All calls to DuplicateHandle were in fact duplicating handles into Windbg.

I can see how I could have refactored the code to not depend on the hProcess, but my case was not that simple. I was in fact calling CreateProcessAsUser with a restricted token. Too restricted for Windbg to be able to run properly!

To solution was to change the way I debug child processes. I'm now using the "Debug Child Processes Also" option in windbg. Oh, and if you don't control the creation of the parent process, you can still attach to it and type the command ".childdbg 1".

Note: While I was writing this post I looked on the web for some references and I found a post about this exact same issue from Raymond Chen posted only 1 month ago. My blog should also be called "The old new thing" :)

First Post!

2007-08-04T08:41:00.000-07:00

Hey!

I'm Nicolas Sylvain, software engineer in the SF Bay Area. This is my first post on this blog and hopefully not my last one. I just got the unexpected motivation to create a blog. I don't know yet how often I'll update this blog; I guess it will depend on what's happening and how much time I have. I'm really curious to see!

The main subject of this blog is Windows Internals and its security. It will be presented from the point of view of the developer. That does not mean that I'm not going to talk about random stuff, but at the end, most of the posts should talk about the security of the Windows operating system.

Why is this called "The Final Stream”? I'm not sure yet. I just think it sounds cool. I might rethink this later :)

Who am I? Well, I'm Nic. I'm from Quebec, Canada so I speak French. Please forgive my English! I moved to Silicon Valley in 2005 to work for a startup called GreenBorder who developed a sandboxed virtual environment to protect the OS and the user data from malicious code running in the browsers or email clients. Recently I joined a much bigger company. I might talk a little bit more about what I'm doing in a later post, but you should not be waiting for that :)