A legacy of neglect

Microsoft says on its developer network site that the ISAPI/COM/IIS model is secure; on the other hand it warns not to accept "unchecked" or "unknown" ISAPI/COM objects, as they could compromise system security. Is it really an administrative problem? Of course not.

Get used to that insecure feeling

When feature-laden shrinkwrapped software opens up your organisation to well-documented security breaches, who’s to blame for the potential cataclysm? Auckland developer Zsolt Pardi (see below) blames the software vendor, while part-time sys admin Juha Saarinen (see A conspiracy of ignorance) says responsibility rests with the user.

It’s a common development practice to use ISAPI extensions or COM objects on a web application running on Internet Information Server (IIS) under Microsoft Windows. Such two-tier development is a way of implementing a web or e-commerce application’s relatively complex business requirements.

Is it secure? Yes and no: the situation is complicated if IIS operates as a hosting service’s web server and the service accepts ISAPI/COM objects from its clients.

What kind of files can the client upload to the hosting service’s IIS server? Quite clearly, any files or applications can be uploaded that are used by Microsoft’s web technology, such as ASP web pages, COM objects and ISAPI extension DLLs. I don’t know of any IIS hosting companies in the US that don’t accept ISAPI extensions from their clients, and they appear happy to register a COM object as well (for an extra charge). COM and ISAPI are fundamental components of the IIS web model and it doesn’t make any sense to decline to use Microsoft technology on a Microsoft web server. On IIS the web pages are running in the web server process or alternatively as an out-process application.

Either way, a web application can’t compromise the system security, as anonymous web user privileges are very restricted — in theory, at least.

But there is a security flaw in Windows that can be exposed through the LPC (local procedure call) port. It means a user mode application (such as ISAPI extensions), even with IUSR — that is, anonymous or with any other restricted security context — is able to call undocumented kernel functions in the NTDLL.dll and the application is able to gain full control of the machine. I reported this security problem to Microsoft in January and my discovery was backed up in March by EliCZ, an independent researcher in Europe.

Unfortunately, EliCZ’s source code is already circulating on the internet, so it is available for hackers and cyber-terrorists. I have outlined to Microsoft a theoretical cyber-terrorist attack, in which a client of a hosting service uploads an ISAPI extension and takes over the network or reformats the hard disk of the server.

But my concerns have basically been rejected by Microsoft. A hot fix for the EliCZ exploit is not yet available from Microsoft. It says it is not a security problem, as the system administrator is the one who must control what kind of files are uploaded.

The poor system administrator must be really confused. On the one hand, Microsoft says on its developer network site that the ISAPI/COM/IIS model is secure; on the other hand there is a warning from Microsoft which says don’t accept “unchecked” or “unknown” ISAPI/COM objects, as they could compromise system security. Is it really an administrative problem? Of course not.

The sys admin didn’t assign administrative privileges to ISAPI/COM; it is running under the IUSR or IWAM security context. The malicious code can gain administrative privileges on the system using a fundamental architecture problem of the Windows system.

Hosting services are a multibillion-dollar business in the US, with a huge number of websites sitting on those servers. The sys admins of hosting services should be sent a clear message from the creator of the ISAPI/COM/IIS model that accepting ISAPI/COM on IIS could put their servers at an incredibly high security risk.

Most importantly, the clients of the hosting services should be aware that IIS servers that accept ISAPI/COM objects from their clients are completely vulnerable to the LPC security flaw, and sensitive information such as credit card numbers or clients’ email addresses must not be kept on those servers (at least until Microsoft issues a fix for the LPC vulnerability).

Pardi is an Auckland software developer with an interest in security software. His website is www.zolt.org.

Join the newsletter!

Error: Please check your email address.

Tags security

More about Microsoft

Show Comments
[]