To Bug or not to Bug

An IIS bug reported towards the end of last year brought an abrupt response from Microsoft. According to the Register, Microsoft acknowledge that the bug exists in IIS 6 but claim that it doesn’t present a risk as you would need to be running your Web Server in an insecure configuration for it to be exploited. Umm, that’s alright then as we all know that everyone runs their applications in a secure config.

The vulnerability arises because of the way IIS6 parses semi-colons. If you had a file called badcode.asp;.jpg, everything after the semi-colon would be ignored and the web server would process the file as if it were called badcode.asp. The end result in this case would be that the file is processed on the server and not the client.

How could this be exploited in the real world? Consider that many sites allow anonymous users to upload documents to a webserver. This could be in the form of a photo or a CV. In order to stop malicious users uploading harmful content there would normally be a filtering process in place that would block files of type .exe, .asp etc. However, if the user were to append ;.jpg or ;.doc to their file the filtering process would be bypassed and the file uploaded to the server. If the file resides in an accessible web directory with script execute permissions, any user can execute the file.

Microsoft rightly point out that you would be foolish to allow uploaded content to be available from the web especially in a directory with execute permissions. Best practise would also not allow the end user to choose their own file names. Personal experience however suggests that best practise is not always followed. Given that IIS may occupy 21% of the entire web server market, I would be confident that some fairly high profile sites could be vulnerable. The worst case scenario would be something like a bank being exposed to the bug. It could lead to the ultimate phishing scam as malicious code would be authenticated and encrypted by a valid SSL certificate.