Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

The Microsoft Small Business engagement team created these news feed widgets as a promotion. They’re pretty cool (unfortunately, they don’t fit in the layout template of the JW Secure website).

The full list is here. A sample is here:



Permalink | Comments (0)

Anyone going to Microsoft Worldwide Partner Conference 2009 in New Orleans? I’ll be there.

(Sounds like madness to be in New Orleans in July, doesn’t it?)

Permalink | Comments (0)

Now all of the project landing pages for the Samples 2009 group on CodePlex have nice “inline” screenshots. That way, if you’re looking for reusable XAML, you know what you can get from these projects. Here are the five project URLs:

Permalink | Comments (0)

Is here.

Primarily, Tim’s paper attempts to answer the question, “what do we call an application that doesn’t run in the browser?” and he defends his choice of ‘rich client’. I personally prefer ‘thick client’, since it clearly contrasts what the likes of Sun (moment of silence please) and Google have been trying to push as the thin client, or the equivalent of terminal- or browser-only, solutions that are in their best interest. However, I freely admit that ‘thick client’ doesn’t have all of the right connotations, especially in the PR department, and that my business is in the ‘thick client’ camp.

I disagree with some of Tim’s points. First, he says that some things are impossible to do in the browser. Given the extensibility of today’s browsers, and the software tools available to web application programmers, this is not true, even if we generously interpret ‘impossible’ as a relative term.

This serves as a segue (Segway?) to the next point, though, which is that just because you can do almost anything with an ActiveX control in IE, for example, doesn’t mean you should use that approach - security generally being the primary issue when it comes to browser plug-ins. However, this brings me again back to the first point, which is that just because the ActiveX approach is harder to do securely doesn’t mean it’s impossible to do securely. And - this is the key thing when it comes to the relative security of the “rich client” approach (another of Tim’s points) - regardless of where the application lives, inside or outside the browser, security requires diligence and careful analysis.

Thirdly, Tim’s points imply that richness is easier to achieve outside the confines of the browser. A relevant measurement for this claim would be the development cost of equivalent applications, one browser-based and one not, that solve a business problem. Admittedly, those are difficult data to obtain for a couple of reasons. First, the biases of the customer as well as of the developer influence technology choice. Second, my first point notwithstanding, I freely stipulate that many problems are more easily solved by one approach (in the browser) or the other (outside the browser), if for no other reason than industrial inertia.

Still, regarding the ease of achieving richness, I cite two counter-arguments to Tim’s viewpoint: first, there is tremendous competition in the custom web development market, both domestically (US) and overseas. This has driven down prices and driven up quality (although not uniformly). And second, while it’s not clear whether richness implies a professional design and UX, it should, and that’s neither cheap nor easy regardless of the technology. But, in my experience, it’s easier to find experienced web designers than experienced “non-browser-based-UI” designers (easier being, again, a relative term; it’s really hard to find either).

Permalink | Comments (0)

Many have already been provided in the Windows API Code Pack for Microsoft .NET Framework. What’s more, you get the full code.

Particularly interesting to me is the Sensor API support, which relates to a recent JW Secure project, and the Network List Manager (NLM). NLM is a little-known feature introduced in Vista that gives you network connectivity data and change notification.

Permalink | Comments (0)

Check out several of our Samples 2009 series of projects highlighted here (hosted on microsoft.com, no less!).

Permalink | Comments (0)

Because it’s done! Check out its CodePlex project site for updated demo binaries, source code, and the whitepaper.

Permalink | Comments (0)

The Cloud Backup code and whitepaper are final. See the CodePlex project page.

Permalink | Comments (0)

Good explanation is here.

In summary:

  1. A protected admin can run a non-elevated process which injects a thread into a process such as Explorer (an OS application that’s almost always running and has the IFileCopy COM control loaded).
  2. The remote thread creates a temporary dll in the same folder as a built-in application binary that’s not under system32 and that’s blessed to silently elevate (i.e. the new Windows 7 UAC behavior). An example is sysprep.exe. The name of the dll must correspond to one that’s not on the “known dlls” list.
  3. The remote thread launches the application (e.g. sysprep.exe), which ends up loading the trojan dll for its local folder. The trojan is now running elevated.

A few comments:

A response from Microsoft is here. They’re right in saying that the issue above requires getting code running locally which, reading between the lines, almost always means that the security game is lost. However, I also agree with the security researchers who respond that UAC prompts are supposed to mitigate those risks, and in the above case, the user never sees one.

The worst offense is that the UAC whitelist is internal-only. That is, in a managed desktop environment, an IT professional can’t deploy a program that requires elevation in such a way that it won’t prompt. I.e., he can’t reproduce the behavior of built-in applications like sysprep.exe (it’s because the feature requires Microsoft’s code signing certificate). If Microsoft really wanted to get itself into PR trouble over this, applying a double-standard to its most contentious feature (i.e. UAC), which is also the feature that’s proven to be the worst for application compatibility, was a good way to do it.

The known-dlls issue is secondary, but still interesting. I believe that it’s for performance reasons that that list needs to be kept very short, since I suspect that the list of dlls that only can load from system32 may also be the list of dlls that, by default, also load into every process. So if that list gets long, system perf would tank. Now, I may be wrong that those are the same list, but in any case, I can’t see why every OS dll shouldn’t be on a list that only loads from system32 (and only when explicitly loaded).

Permalink | Comments (0)
Newer Posts »