No Victory Lap

Now that the echoes of PWN2OWN competition are fading, I would like to tell you my thougts about it. First of all, the contest itself is a great way to bring the information security to the mind of the average it worker out there. Too often security is a topic that is deemed too obscure to be given proper coverage by the mass media.

Secondly, security research is a critical component in the software ecosystem and it sure needs their own rituals and celebrations where talented researchers get together to show off or become known. 

Finally, as much as anybody else who end up unscathed I (we) would like to boast but can’t.

There is no known metric to decide among web browsers which one is more secure. Certainly a 20 hour contest where $5K is at stake (and you need to leave your country) is not the place. What if the objective whas to steal your facebook cookie?

MSFT and Mozco have tried to come up with metrics. They sure feel biased and self-serving, just like benchmarks but worse, since there is noting that you can test yourself.

But one thing most software professionals must have taken home: security in depth (aka the sandbox) is your friend. Why aren't more people implementing sanbox-like technolgies to their internet facing apps?

Yes, FF3 I am looking at you.

Yes, Windows Media Player, I am looking at you too.

It beats me. Do they think they can eventually catch all bugs?

ps. The second day, when you can use flash, and I did expect somebody do use that vector. I can only think that flash exploits sell very well.

Sandbox woes with injected dlls

One of the interesting things about the Chromium sandbox is that on Windows, there are a lot of random dlls that can load into the sandboxed process. They fall into 4 categories:

• Malware : Yeah that funny powerpoint that you aunt send you had extra fun inside.
  
• Anti-Malware : You pay a private outfit for protection, just like Chicago 1920's
  
• Power tool: Yeah so you can burn a CD from *any* app. How convenient. Sigh.
  
• Games: You cannot be that good; the game need to spy on all your processes to see if you are getting help.
  

The outcome of these injected dlls  trying to run in the Chromium sandbox invariably is one of the following:

a) Can't do anything so it exits, leaking memory of some some shared resource.

b) Can't do anything and it was not expecting that so it crashes the process.

c) Can't do anything so it lingers, bidding time to do a) or b) at a later time.

So how ofter these injected dlls cause crashes? Well, it turns out a lot. A whole lot. Apparently most people have one or more of these applications.

There are solutions, but is hard to do one that scales. I might go into that at some point.

A better questions is why are these application injecting dlls in all the user's processes? I don't think there is a definitive answer but I'll try to tackle that in the next post.

Element 24 is out

Yes! finally Google Chrome and Chromium have been launched and I can talk about what I have been doing. Unless you have been in a deep comma you should have seen the news about it and you might have already tried it. In my humble opinion it has been well received, even by many skeptics and even a few praises by people that are well versed in windows which are MSFT fans.

From all the stuff that goes in a browser I have been most involved with the Sandbox, the first-run experience and with the installer. I'll talk about them in due time. Of course, in many cases it would be somewhat peripherial because I rather improve the official documents that make my blog (that at last count had two subscribers) the place to go to learn about them.

By far to me the most interesting thing is the Sandbox but I haven't seen much talk about it on the security and rev-engineering sites that I monitor. In the RE community I guess is not that interesting since it is open source, so not much to reverse there. The system-level security community still silent, I think they are digesting it.

Anyhow, here is the obligatory link to the design documents. The sandbox design doc is there.

Also, Nic is also going to talk about the sandbox.

Long time no post

So I haven't written anything in a while. Since mid-May I have been working on a large software company (the small company I used to work for got acquired by this other big company) which has many interesting but secret projects. And secrecy is a big thing for my new master.

Therefore me blogging about software seems kind of dangerous. Anyhow, is not like there are people reading this blog anyway.

This is more like a note in case somebody finds this blogs and wonders what happened. Did he got abducted by aliens? a CIA 'wet' operation?

Nope. I just got a job.

Memory latency

I recently found someone that measured (circa 2006) the different latencies of the memory hiearchy on a typical PC. Here are the important numbers:

level	latency
L1 cache (on die)	1.4ns
L2 cache (off die)	9.7ns
RAM (PC2700 DDR)	28.5ns
Hard Drive (250 GB Maxtor 7200 RPM)	25.6ms

The test machine had an AMD Athlon XP 3000+ processor. Another interesting piece of data is the throuput (sustained data transfer) of the RAM, 2541 MB/s versus of the hard disk: 67 MB/s.

Note that in Intel x86 and AMD processors besides the hiearchy of cache, you also have the translation lookaside buffer (aka TLB) which is a small cache that keeps the most recent virtual-to-physical translations. This quite important if you code runs in an OS that uses virtual memory such as Windows or Linux or Solaris or MacOsX. When there is a TLB miss the CPU has to scan the page tables (living in RAM) to find the appropiate entry. This results in about 3 to 4 RAM reads. In terms of the size, the 1995 Pentium had one code TLB and two data TLBs, one of the data TLB has 64 entries (for 4Kb pages) and the other 8 entries (for 4Mb pages). The instruction TLB is 32 entries.

The biggest hit in terms of TLB-related (or virtual-to-physical translation) happens when the OS switches processes. This causes the active page tables to change which in turn requires a total (or partial) TLB invalidation.

The credits for the measures go to Diomidis Spinellis in his paper "Some Types of Memory are More Equal than Others".

IShellExecuteHook is dead

Some products like to oversee certain user activities such as the act of starting a new applications (or opening documents) using the shell (explorer). For this purpose Microsoft invented (and documented/supported) a handy little COM interface known as IShellExecuteHook. The monitoring program registers it on a specific path in the registry and the shell loads and calls it when the user executes something in the shell. Here is a sample ATL class with the obvious code omitted:


class ATL_NO_VTABLE
MyShellExecuteHook : public IShellExecuteHook
{
public:
// Provide implementation for IUnknown::QueryInterface
STDMETHOD(QueryInterface)(REFIID riid, void** ppvObject)
// Stock implementation of AddRef and Release works
_ATL_ADDREF_RELEASE_IMPL(MyShellExecuteHook)

// IShellExecuteHook has just one method
STDMETHOD(Execute)(LPSHELLEXECUTEINFO lpsei)
{ your code here }
};


The beauty of IShellExecuteHook is that it allows you to pass along any requests that you don't care about to the shell. You are basically an observer with the right to veto (block) anything you don't like.

In Vista, the IShellExecuteHook API has been deprecated. There is a workaround involving editing a couple of undocumented registry entries but I won't go in there since the message is loud and clear: do not use this.

However, if you ask a lot Microsoft support will coff a workaround which is to take over the open command by changing the registry like so:

REGEDIT4

[HKEY_CURRENT_USER\Software\Classes\Folder]
@=""

[HKEY_CURRENT_USER\Software\Classes\Folder\shell]

[HKEY_CURRENT_USER\Software\Classes\Folder\shell\open]

[HKEY_CURRENT_USER\Software\Classes\Folder\shell\open\command]
@="path to your exe here"


Now, if you do this then you have to take over the interaction with all shell namespace extensions, including third party extensions (specially the ones that use IShellFolder).

Of course this is insane. So scratch that idea.

A better idea would be to register another verb such as 'open with xxxx' and make it the default verb (the default verb handles the double-click action). Yes, I hear you; that is not the issue that was solved by IShellExecuteHook.

At this point in the game people that were relying on this documented way to intercept the shell and do something unique for special cases but for everything else fallback to let the shell do it's thing are left with no option. And when people are left with no documented option but still have to ship a product they start reverse engineering the shell. It turns out that the shell itself has a special magic component that takes over for 'open'. Meet the DelegateExecute.

The DelegateExecute Value in HKCR\Folder\shell\open\command is a CLSID and if you put your own COM object there you get queried for ICommandExecute interface. I have not verified this myself nor I am interested in cooking an unsupported way to observe the shell actions. My point was a) Microsoft giveth and Microsoft can taketh away and b) people will find a way to get it back by force if necessary.

Such are the wonderful dynamics of developing for Windows.

A funny question from my bank

Yesterday I logged on to my bank account and applied for a service. After the second or third page of the application form the website lobbed this question to me:

Are you a senior foreign political figure or a family member or associate of a senior foreign political figure?

What??

Mmmm.. I guess it not something you want to answer in the positive to get the VIP-level service. Now come on .. seriously, what does it mean to be an 'associate' and what qualifies as 'senior'.
The other interesting fact is that I applied a couple of months ago for the very same service, different bank (different account) in person. The service desk lady asked me all the standard questions and most certainly did not ask that one. I guess this is either a) something that a bank employee can tell just by looking at the person or b) my other bank has gone bananas.

If I had to choose, I'll go with a) and that means that the lady selected 'yes' (selecting 'no' will be worse for her) and that means that I'll get a visit from the secret service (or the FBI) any day now.

On a more serious note, after some research I can tell you where this nonsense comes from. It is the implementation of section 312 of Title III of the Patriot Act of 2001 that "requires financial institutions to determine whether any holder of a private banking account is a senior foreign political figure or a family member or close personal associate of such person and to report any known or suspected violation of law conducted through or involving the account". So how do you do that if you are not a private investigator? Simple, just ask the customer.

So I guess who is going to pay me a visit is more likely the department of homeland security.