MLP

One reason you should clean up warnings

What's the difference between Windows Mobile 5.0 and Windows CE 5.0?

I got the following question in email today:

Can you please explain me the difference in windows CE 5.0 and windows mobile 5.0? Isn't windows 5.0 is based on windows CE 5.0? If yes then why is the development tools for these are different, i mean windows CE based applications can be developed using evc++ 4.0 but for WM 5.0 based application we need Visual Studio 5.0?

Well, I’ve kind of answered this question already. The only new thing to add is that Windows Mobile 5.0 for Pocket PCs is based on Windows CE 5.1 bits according to the About screen (Microsoft using pre-release versions of Windows CE in Windows Mobile again? That caused a boatload of trouble for Pocket PC 2000 and 2002 and I thought they’d finally got over it.)

As for the development tools question, don’t ask me – ask Microsoft. The simple answer is that they didn’t generate an eVC-compatible SDK therefore it doesn’t register with eVC 4.0 therefore you can’t select Windows Mobile 5.0 as a target. As to why they didn’t do this, who knows? Perhaps something to do with the old Platform Manager, which was not the most reliable of software (understating the case severely). Also, it appears that MFC 6.0/CE and ATL 3.0/CE are not supported for new development; they don’t ship with the SDK any more, although the DLLs do ship on the device I think.

Two more alleged WMF 'vulnerabilities' - but there's a problem with the 'exploit'...

A number of news sites are pointing to a post on the Bugtraq mailing list alleging more problems with Windows’ handling of the Windows Metafile format.

Just a quick recap on the original issue: I originally thought that this was simply a buffer overflow issue, but in fact it appears that it’s something different – that an intended feature can be used in an unintended way. As I said last time, a WMF file contains a sequence of GDI commands. One of the supported commands is the GDI Escape function, which allows the application programmer to pass additional commands to the graphics driver, which – because GDI is a unified screen and printing API – can be a printer driver. The exploit apparently uses the SETABORTPROC escape. This escape was intended to permit GDI to call the application back, periodically during printing, to determine whether the user had tried to abort the print job. The attacker can use the SETABORTPROC escape to point to another part of the WMF file which contains code, which will be executed by GDI. It’s a case of an overlooked feature with insufficient security protection, not a failure to correctly validate the input parameters – the parameters are valid.

To the new ‘vulnerability’. Here we are dealing with a malformed file. The attacker supplies sizes for some of the parameters which are larger than the amount of data supplied. There is no vulnerability here – all that happens is that Windows tries to copy more data than is supplied. When the source pointer goes off the end of the input buffer, it may encounter an unallocated page. When this occurs, an access violation exception occurs, which, unless the application has been written to guard against it, causes the application to crash.

Note that this cannot crash Windows itself. It can only crash the process performing the file parsing. Now, in many cases this will be Windows Explorer (explorer.exe) – but Explorer should restart after a crash (it always used to – I haven’t actually had a problem in a while so I don’t recall if it still does). If an attacker put a WMF malformed in this way on a website, and the user browsed to it, the browser would simply crash. So yes, it is a denial of service, of a sort, but it’s not a serious issue.

With this information in hand, Microsoft’s response seems pretty reasonable.

Don’t believe everything you read on Bugtraq.

WMF vulnerability patch to be released early

2pm Pacific Time today. That’s 10pm GMT according to my handy World Clock app (recently updated to not crash if you’ve disabled automatic daylight saving adjustment).

Thoughts on the WMF vulnerability

OK, so we know there’s a zero-day vulnerability (i.e. one which was not reported to any security organisation or vendor before being exploited) out there which utilises a malformed WMF file to execute code on a victim’s computer. This is being termed a ‘remote code execution’ vulnerability – this term is now being used to cover any situation where an attacker could cause code to be executed, but doesn’t differentiate between a situation where this can be done by the attacker actively sending data over a network to the victim, and one (such as this) where the victim must request data from the attacker. However, the attacker can cause software executing on the victim computer to automatically request the bad data – in this case, for example, by sending an email message to the victim containing a suitably malformed image file, which will cause some email packages to automatically render (draw) the image when the message is displayed.

Firstly, what is a WMF file? It stands for Windows Metafile. That’s a pretty meaningless name. What it actually contains is just a sequence of commands – that map one-to-one to GDI API calls – for producing a drawing. The easiest way to construct a WMF is to use the CreateMetaFile API which produces a GDI drawing surface, a device context, and returns a handle to it, an HDC. Once you’ve finished drawing – using the regular GDI API calls – you then call CloseMetaFile which gives you a HMETAFILE. You can then draw the metafile again using PlayMetaFile. It appears that this API is the one which contains the vulnerability – that some part of the format is insufficiently checked and the attacker can therefore cause the processor’s instruction pointer to end up pointing at a part of the supplied file.

This does suggest that any application that renders WMF data using the PlayMetaFile API could be an attack vector. Because it is such a venerable format, many applications will support it. You can include WMF drawings in your Word documents. You can process WMF files in Paint Shop Pro.

The current advisory from Microsoft suggests unregistering the shimgvw.dll component. This component is responsible for much more than WMF rendering. It performs all thumbnail rendering in Windows Explorer for all the best-known filetypes. It provides the size and other information for the Task pane and status bar. It also implements the ‘Windows Picture and Fax Viewer’ frame that appears if you click Preview on the context menu for an image. Unregistering this DLL kills all this functionality – but it does not protect against the vulnerability in other applications which call PlayMetaFile (except those which use shimgvw.dll as a proxy, such as Internet Explorer). This is my supposition, anyway – I would be astonished if shimgvw.dll did not render WMF simply by calling PlayMetaFile, and likewise Enhanced Metafiles by calling PlayEnhMetaFile.

While WMF files are most often used in the filesystem for storing vector-based clip-art (one among many other formats), you can also find them used within other formats, because of the native OS support. For example, when copying a diagram from Visio to Word, you will find that the prerendered version of the diagram (used for a linked or embedded diagram when the diagram is not active) is a metafile – although in this case it is most likely an Enhanced Metafile. Whether the Enhanced Metafile format can also be exploited is an unknown.

How to stop TlbImp requiring admin privileges

It seems that the Type Library Importer tool, TlbImp.exe, sometimes needs administrative privileges to do its job, if you’re trying to create a Primary Interop Assembly (or otherwise a strong-named reference). At work today, even admin privileges weren’t enough – I’m not sure if something’s been broken after installing Visual Studio 2005 since it used to work fine. The error given is ‘Invalid strong name parameters specified.’

What seems to be required is that the strong-name-key needs to be added to a key container in order to be used, which TlbImp is doing for you behind the scenes. The container used by strong-name functions can be either a user or a machine container. The default seems to be a machine container (at least that’s been the case both here at home and at work).

You can switch to a user container using the following command from a Visual Studio command prompt (either from the Start Menu’s Visual Studio group, or by running vsvars32.bat from the Common7\Tools directory, or sdkvars.bat from the .NET Framework SDK Bin directory):

sn -m n

Having done this, you should no longer need administrative privileges to strongly-name an assembly.