Are Software Vendors Ever Going to Embrace UAC?

I find it really sad that three years after Windows Vista, there’s still active software out there (distributed by leading industry vendors) that doesn’t comply with UAC guidelines and tells users to log in as administrators or to disable UAC.

Here’s Adobe Updater telling me that there’s a new version of Adobe Updater available. (Why I would need a piece of software constantly running on my system and trying to see if I want to update the software that is trying to update my software is another question, left to yet another rant.)

Right, so I wish there were a way to cancel these automatic updates altogether. Let’s see, maybe under “Preferences”?

Hmm. It seems like automatic updates are already disabled, and it seems that the software shouldn’t be checking for updates to any of the (one) Adobe products that I have installed. On the other hand, it’s trying to update the updater, so what do I know?

Anyway, I click OK, in the hope that the message will go away eventually. Guess what happens?

Well. Dear Adobe. Learn this—I am an administrator. If I log in as an administrator and run Adobe Updater (which is not on the Start menu, by the way) it’s still going to do no good—my token is filtered. And how can I reinstall Adobe Updater, if I may ask? It’s not under Programs and Features, so how am I supposed to do that? Heck, how is a user at home supposed to do that?

OK, I realize that the updater is probably the part of the app that was engineered in hindsight and implemented in a rather quick and dirty fashion, perhaps to satisfy some security requirement or please an executive who frowns upon the fact that Microsoft can deliver automatic updates to their software but Adobe can’t.

Nonetheless, if you’re writing software that is distributed to the computers of tens or hundreds of millions of users, and bundled with myriads of other software installations, please do make the little effort to make sure every corner of your application is polished and you don’t make a fool out of yourself.

How Are Methods Compiled Just-In-Time and Only Then?

We all know that the first time a .NET method is called, the just-in-time (JIT) compiler is invoked to compile the method’s IL representation to the native code for the particular platform it’s running on (x86, x64 or ia64). Did you ever ask yourself how this happens?

The naive way to think about it is the following: Every time a method is called, the generated native code checks a flag that indicates whether the method has already been compiled (jitted). If it has been, the code jumps directly to the compiled method; if it hasn’t been, the code calls the JIT to perform the compilation, sets the flag and then proceeds to the compiled result.

This is a very expensive thing to do, if you think about it. The cheapest method call in .NET is the static method call, where there are no setup steps or checks required to perform the method dispatch (unlike instance method calls, virtual method calls or interface method calls which are significantly more evolved). If we had to perform a global flag check for each static method call, it would incur an unjustified performance cost that—in performance-sensitive scenarios—could more than double the cost of the call.

It’s somewhat akin to thinking about handling access to an invalid memory location via a pointer. Instead of generating code to proactively check whether the pointer points to a valid memory location, the compiler emits code to directly access memory. If the CPU detects that the virtual address is not mapped, it causes a page fault that the OS memory manager handles and decides whether an access violation is required or the page is in fact available and should be mapped to the virtual address. (The former happens when you access a NULL pointer, or any other invalid address; the latter happens, for example, when a page is paged out to disk or when a page is first accessed after being committed so its page table entries need to be built and the page itself must be taken from the MM’s zero page list.)

The same idea is employed in the JIT-compilation scenario. Instead of checking a global flag, the JIT emits a stub at the call-site so that instead of the method, the stub is automatically called (and the calling code is none the wiser about this). It is this stub that calls into the JIT, compiles the target method and transparently replaces the call-site if necessary so that the call is dispatched directly to the target method. Subsequent calls do not go through the stub—it’s a wasteful thing to do. This implies that all but the first call to a method do not incur any additional performance cost, even though the method is jitted only at the first time it’s called.

I hope there’s nothing surprising about the idea itself: Lazy evaluation is a technique too common to even give it a name. Nonetheless, it’s good to know that frameworks and runtimes around us take advantage of this technique all the time.

Appendix: Seeing this in action

Let’s fire up a debugger with this amazing program:

I set a breakpoint at the call to Foo so that we can inspect the method descriptor for the method. Here it is:

0:000> !name2ee *!CheckingJITting.Program.Foo
Module: 69171000 (mscorlib.dll)
--------------------------------------
Module: 001d2354 (sortkey.nlp)
--------------------------------------
Module: 001d2010 (sorttbls.nlp)
--------------------------------------
Module: 001b2f2c (CheckingJITting.exe)
Token: 0x06000001
MethodDesc: 001b32c0
Name: CheckingJITting.Program.Foo(Int32, Int32)
Not JITTED yet. Use !bpmd -md 001b32c0 to break on run.

0:000> dd 001b32c0
001b32c0  40000001 20200005 001bc011 71030002
001b32d0  00200006 00250070 00060003 00000004
001b32e0  00000000 0000000c 00050011 00000004
001b32f0  693d84c0 001b2f2c 001b331c 001b1354
001b3300  00000000 00000000 69336a90 69336ab0
001b3310  69336b20 693a74c0 001bc019 00000080
001b3320  00000000 00000000 00000000 00000000
001b3330  00000000 00000000 00000000 00000000

If you look at method.hpp in the clr\src\vm folder of the SSCLI release, you’ll see that a method descriptor is in fact only the first two DWORDs here. The subsequent DWORD is the address of the jitted code, if it’s jitted (right now it isn’t—we haven’t called Foo yet).

Caveat: Using the SSCLI to examine the CLR data structures is risky because they are subject to change without any notice between service packs or .NET releases, and because they are not guaranteed to be in sync with any CLR version, for that matter.

Now let’s give the method a chance to run, and put a data breakpoint on the first DWORD of the method descriptor which contains flags (including the flag used to determine whether the method is jitted or not—as shown in the !DumpMD output above):

0:000> ba w 4 001b32c0

0:000> g
Breakpoint 1 hit
eax=00000030 ebx=00000000 ecx=001b32c0 edx=30000000 esi=0036ec60 edi=00000001
eip=6c741980 esp=0036ec08 ebp=0036ec0c iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
mscorwks!OrMaskMP+0x3:
6c741980 c3              ret

0:000> k
ChildEBP RetAddr 
0036ec0c 6c75b5dc mscorwks!OrMaskMP+0x3
0036ec1c 6c7f5da2 mscorwks!MethodDesc::SetCriticalTransparentInfo+0x23
0036ec50 6c758cc8 mscorwks!MethodSecurityDescriptor::ComputeCriticalTransparentInfo+0xb9
0036ec58 6c7f5d42 mscorwks!MethodSecurityDescriptor::IsCritical+0x10
0036ec74 6c7f5ba0 mscorwks!SecurityTransparent::IsMethodTransparent+0x39
0036ec84 6c7f8230 mscorwks!Security::CanSkipVerification+0x2f
0036ec9c 6c7f7889 mscorwks!GetCompileFlags+0xab
0036f034 6c7f771f mscorwks!UnsafeJitFunction+0x14a
0036f0d8 6c75120b mscorwks!MethodDesc::MakeJitWorker+0x1a8
0036f130 6c7513cb mscorwks!MethodDesc::DoPrestub+0x41b
0036f180 00b4087e mscorwks!PreStubWorker+0xf3
WARNING: Frame IP not in any known module. Following frames may be wrong.
0036f1c0 6c741b4c 0xb4087e
0036f1d0 6c752219 mscorwks!CallDescrWorker+0x33
0036f250 6c766591 mscorwks!CallDescrWorkerWithHandler+0xa3
0036f394 6c7665c4 mscorwks!MethodDesc::CallDescr+0x19c
0036f3b0 6c7665e2 mscorwks!MethodDesc::CallTargetWorker+0x1f
0036f3c8 6c82d7e5 mscorwks!MethodDescCallSite::CallWithValueTypes_RetArgSlot+0x1a
0036f52c 6c82d705 mscorwks!ClassLoader::RunMain+0x223
0036f794 6c82dc55 mscorwks!Assembly::ExecuteMainMethod+0xa6
0036fc64 6c82de3f mscorwks!SystemDomain::ExecuteMainMethod+0x456

It doesn’t really matter where exactly we are on the stack other than the fact that we’re inside code related to the JIT (see mscorwks!PreStubWorker on the call stack?). In other words, the method is in the process of being compiled, and after the call completes we have the following values for the method descriptor:

0:000> dd 001b32c0
001b32c0  71000001 20200005 002500a0 71030002
001b32d0  00200006 00250070 00060003 00000004
001b32e0  00000000 0000000c 00050011 00000004
001b32f0  693d84c0 001b2f2c 001b331c 001b1354
001b3300  00000000 00000000 69336a90 69336ab0
001b3310  69336b20 693a74c0 001bc019 00000080
001b3320  00000000 00000000 00000000 00000000
001b3330  00000000 00000000 00000000 00000000

The values of the flags have changed, and the subsequent address points to the actual method:

0:000> !DumpMD 001b32c0
Method Name: CheckingJITting.Program.Foo(Int32, Int32)
Class: 001b1354
MethodTable: 001b32e0
mdToken: 06000001
Module: 001b2f2c
IsJitted: yes
CodeAddr: 002500a0

0:000> !u 002500a0
Normal JIT generated code
CheckingJITting.Program.Foo(Int32, Int32)
Begin 002500a0, size 9
>>> 002500a0 55              push    ebp
002500a1 8bec            mov     ebp,esp
002500a3 33ca            xor     ecx,edx
002500a5 8bc1            mov     eax,ecx
002500a7 5d              pop     ebp
002500a8 c3              ret

.NET Performance: Tales from the Field

Today I had the pleasure of presenting at the IDCC (Israeli Developers Community Conference). This unique conference was organized by the community, for the community and the sessions were selected by members of the community. I’m also proud to say that my company, Sela Group, has sponsored the conference.

Overall the day has been great with lots of interesting talks. My session, .NET Performance: Tales from the Field, was one of the only sessions I ever delivered that didn’t have any code at all. I’m not usually proud of not showing code, but I deliberately wanted to focus on tools, analysis and mitigation of as many performance case studies as I could manage in a 75-minute session.

We discussed seven case studies, six of which were real performance issues I worked on as head of the Performance Team at Sela, and one that I borrowed from Microsoft’s Rico Mariani:

• Modifying an authorization-search algorithm from using a top-down tree search to a bottom-up tree search
• Improving the cold startup performance of a mixed managed/native application
• Decreasing time in GC from 70% to approximately 3% by shortening the lifetime of temporary managed objects
• Fixing 250ms delays caused by GC suspension
• Marshaling data between byte arrays and managed structures using code generation
• Converting lock-based in-memory queues to lock-free queues
• Improving WCF serialization performance in .NET-to-.NET scenarios with complex object graphs

You can download the slides—no demo code—from here.

It’s been a great pleasure to see everyone who attended my session. It was recorded by Sela and the recording should be available online in the next few days on the IDCC website.

(The pictures in this post courtesy of Gadi Meir.)

C++ Wrapper for Windows 7 Taskbar Tabbed Thumbnails

A few weeks ago we took a detailed look at the intrinsic details of providing Windows 7 taskbar tab thumbnails and live previews in a Win32 application.

As part of that post I mentioned a C++ wrapper called TabWindow which takes care of most of the nasty details and leaves only the work of creating the tab controls and rendering them to the application developer.

Here’s the public API of the TabWindow class and its corresponding TabWindowEventsSink callback interface (slightly edited to fit):

The use of this class is fairly straightforward. The UI controller of your application is responsible for the creation of tab windows that correspond to individual tab controls (or possibly a completely different UI paradigm).

On initialization, the UI controller should pass the ITaskbarList3 pointer to the static SetTaskbarListPtr method and call the static RegisterClass method. When a new tab window is created, an associated TabWindow instance should be created and associated with an index (for book-keeping purposes). Next, your UI controller should derive from the TabWindowEventsSink abstract class and implement its pure virtual methods—the first two provide the window thumbnail and live preview, and the former two react to the user activating or closing the tab from the taskbar.

A picture is worth a thousand words and a complete sample is probably worth even more, so I simplified the HOL solution from the Windows 7 Training Kit to demonstrate the TabWindow class for thumbnail and preview management. The resulting application looks like this:

…and has the following taskbar preview:

All the obvious commands work—you can activate a tab from the taskbar and it will activate the appropriate tab in the application, you can close a tab from the taskbar, and so on.

The sample solution can be downloaded from here. Have fun!

Exploitable Crash Analyzer

The Microsoft Security Science Team released a debugger extension that performs automated crash dump analysis and assesses the security risk associated with the crash. It’s extremely simple to use—fire up WinDbg, open the crash dump (or debug the application until it crashes), load the debugger extension and execute the !exploitable command to receive an immediate risk assessment.

I immediately wanted to try this thing out, so here’s what I did. I wrote a simple console application that reads user input with gets into a 4-character buffer:

I ran the application in Release mode (in Debug mode the CRT will raise an assertion, obstructing the natural flow), gave it a string of approximately 20 characters, and sure enough, it crashed. Next I opened the crash dump in WinDbg, loaded the debugging extension and voila:

0:000> .load D:\Development\MSEC_DebuggingExts\Binaries\x86\msec.dll
0:000> !exploitable
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - Data Execution Prevention Violation starting at Unknown Symbol @ 0x00000000736a6661 called from kernel32!BaseThreadInitThunk+0x000000000000000e (Hash=0x14055f47.0x0f50276b)
User mode DEP access violations are exploitable.

As you see, the crash was classified as exploitable—it’s basically execution of a random return address that has overwritten the stack (DEP prevented it because the value reflects some random characters I typed, but it could be shellcode from an attacker).

Here’s another example that I generated by emitting the cli privileged instruction in a user-mode process:

(178c.16d0): Unknown exception - code c0000096 (first chance)
(178c.16d0): Unknown exception - code c0000096 (!!! second chance !!!)
[...]
ExploitableBug!main:
00cb1000 fa              cli
0:000> k
ChildEBP RetAddr 
0044fc08 00cb116d ExploitableBug!main [d:\development\scratch\exploitablebug\exploitablebug.cpp @ 8]
0044fc4c 76103f39 ExploitableBug!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586]
0044fc58 77ea0409 kernel32!BaseThreadInitThunk+0xe
0044fc98 77ea03dc ntdll!__RtlUserThreadStart+0x70
0044fcb0 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> .load D:\Development\MSEC_DebuggingExts\Binaries\x86\msec.dll
0:000> !exploitable
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - Privileged Instruction Violation starting at ExploitableBug!main+0x0000000000000000 (Hash=0x415f583b.0x5827743b)
A privileged instruction exception indicates that the attacker controls execution flow.

All in all, this is a really simple debugging extension that can be automated and streamlined. As you can see, it even suggests a bucket for the bug—which means it’s very useful for automated crash analysis (and that’s how it is used by various teams at Microsoft).

This debugging extension also ships with source code, which means you can dig right in and see how the various detection rules are implemented. You can find them in the exploitable_rules.h header file in the form of nested macros such as the following:

// Rule: Stack Buffer Overruns (/GS Exceptions) must be fixed
BEGIN_ANALYZE_DATA
    PROCESSOR_MODE                DONT_CARE
    EXCEPTION_ADDRESS_RANGE        DONT_CARE
    EXCEPTION_TYPE                STATUS_STACK_BUFFER_OVERRUN
    EXCEPTION_SUBTYPE            DONT_CARE
    EXCEPTION_LEVEL                DONT_CARE
    ANALYZE_FUNCTION            NULL
    RESULT_CLASSIFICATION        EXPLOITABLE
    RESULT_DESCRIPTION            L"Stack Buffer Overrun (/GS Exception)"
    RESULT_SHORTDESCRIPTION        L"GSViolation"
    RESULT_EXPLANATION            L"An overrun of a protected stack buffer has been detected. This is considered exploitable, and must be fixed."
    RESULT_URL                    NULL
    RESULT_IS_FINAL                true
END_ANALYZE_DATA

It’s fairly easy to add additional rules and detection heuristics, recompile, and you have a crash analysis extensions tailored for your needs. (This is also a great way to learn about how debugging extensions can be implemented and how simple and sophisticated instruction analysis in a crash dump can be performed.)

Creating a Custom Windows 7 Troubleshooting Pack

Windows 7 offers a built-in troubleshooting platform that consolidates the typical user’s support and troubleshooting needs into a single consistent user interface with dozens of specific troubleshooters for common problems.

If you haven’t seen the Troubleshooting Platform in action yet, go ahead and type “troubleshooting” into your Windows 7 start menu and open the Troubleshooting control panel applet.

You can try some of the troubleshooters now. I’ll wait here. One of the easiest ones to repro and use is the “Check for performance issues” troubleshooter. Go ahead and change your power plan to the “Power Saver” plan and run the troubleshooter (while on AC power). The troubleshooter will attempt to detect performance problems for a few seconds, and then it will tell you that you’re using a power plan that can decrease your system’s optimal performance, and even offer to automatically fix the problem by moving you back to the “Balanced” power plan.

The first thing I thought about when I saw this platform in action was: How can I write a troubleshooter myself? How can I use the same consistent user interface to offer users of my software a self-support mechanism? (…And if you currently have any support costs at all for your own software, you must be asking yourself the same questions.)

Fortunately, writing a troubleshooting pack is fairly easy. There’s a neat tool that ships with the Windows 7 SDK called the Troubleshooting Pack Designer. You’ll find it in your SDK root under the Bin\TSPDesigner folder.

What I’m going to do in this short blog post is show you how to create a simple troubleshooting pack that will troubleshoot a very simple problem—if there is no folder named Temp in the C:\ root drive, it will create that folder automatically. You can imagine how this can be useful for legacy applications that disregard UAC and create folders all over the place.

To begin, I’ll click the new project icon and choose a location for the troubleshooting pack that I’m creating.

Next, there are all kinds of details to fill in, including the project name, description and privacy URL for the troubleshooter users. Next, we need to add a root cause, which is a general title for the thing that the troubleshooting pack can detect. Again we need to fill in some details.

Now it’s time to define the troubleshooter. Again there are some questions to answer first—the troubleshooter might or might not require elevation and might or might not require user interaction. My troubleshooter doesn’t require any of these.

Now we’re going to create a resolver—that’s the part of the troubleshooting pack that actually solves the problem. Again we need to give it a name and a description, and answer a few questions—does the resolver have any adverse side effects, does it have to run elevated, does it need any user interaction.

Finally, we have to define a verifier script—that’s the part that makes sure the problem is gone. In this case, we can reuse the troubleshooter script, so that’s what I’m telling the designer to do.

Now that I’ve defined all the parts of the troubleshooting pack, I need to write the actual code that detects, resolves and verifies the problem. That is done by using the “Edit Root Cause Scripts” link on the left. This opens the PowerShell IDE that ships in Windows 7. The language of choice for the Windows Troubleshooting Platform is PowerShell 2.0, which means that you can easily integrate your existing troubleshooting scripts using the standard .NET facilities or interop mechanisms.

In the troubleshooter script, I’m going to do a very simple check for the existence of the C:\Temp directory (the same script can be reused by the verifier part of the pack because it doesn’t have any side effects). Here’s the code:

$RootCauseID = "NoTempDirectory"
$RootCauseDetected = -not [System.IO.Directory]::Exists("C:\\Temp")
update-diagrootcause -id $RootCauseId -detected $RootCauseDetected

Now let’s move on to the resolver script. Here we’re going to create the C:\Temp directory, nothing more. Here’s the code:

[System.IO.Directory]::CreateDirectory("C:\\Temp")

That’s all there’s to it—we now have a troubleshooting pack that is ready for action! One minor thing remaining is to actually sign the troubleshooting pack and then distribute it to your clients, but you can test-run the thing from the designer by clicking the green “Play” button, and voila:

If you look at the output\cab folder under the troubleshooting pack’s root directory (which I chose when creating the project), you’ll find a stand-alone .cab file ready for use.

Double-clicking that file brings us to the troubleshooting pack wizard, first step.

This post was just a brief overview of how easy it is to create a troubleshooting pack. It didn’t feature any sophisticated user interaction (and there are quite a few built-in interactions in the Troubleshooting Platform), so we basically only scratched the surface of this subject.

If there will be interest (and time) I will write more about troubleshooting packs, but in the meantime I suggest that you take a look at the Troubleshooting Pack Designer and learn how to write troubleshooting packs for your own software.

Parallel Programming in Visual Studio 2010: MSDN Event Deck and Demos

A couple of days ago I delivered a session on Parallel Programming in Visual Studio 2010 at the Microsoft offices in Raanana.

The deck and code will appear on the official website (of Israel MSDN Events) shortly, but for now you can download them from my SkyDrive:

• Deck
• Demo code

This session complements my earlier session on Concurrent Programming fundamentals, in which I provided a theoretical overview of some of the architectural and implementation issues in modern concurrent applications.

In this session, I focused on code and demos—I wanted to show off the Microsoft offering for parallel programming in managed code, specifically in Visual Studio 2010 (with .NET Framework 4.0).

The slides might not be of much value if you haven’t attended the session, but do take a look at the demos. Here are some of the things I showed:

• Explicit creation of Task objects for parallelization
• Linking tasks in parent-child relationships and cancellation propagation
• Continuation of tasks (forming task component chains)
• Implicit parallelization of loops using Parallel.ForEach and Parallel.For
• Custom partitioning of data for dynamic iteration using Parallel.ForEach
• Parallel LINQ (PLINQ) with ordering and cancellation
• Synchronization using SpinLock vs. Monitor and using thread-local state in an implicit parallel loop
• Producer-consumer using ConcurrentQueue
• Creating Tasks out of APM constructs (specifically on top of FileStream.BeginRead/EndRead, FileStream.BeginWrite/EndWrite)
• Debugging parallel applications in Visual Studio 2010 with the Parallel Tasks and Parallel Stacks tool windows
• Profiling parallel applications using the new Visual Studio 2010 “Concurrency” profiler mode