Introduction

Well, It's now two weeks since the release of Shatter, and my inbox has finally started calming down. I've tried to reply to most of the messages I've received, but I'm getting a lot of the same things said over and over and over again, and there's a fair amount of FUD going round about this thing. So, I've written this as a followup, to try and answer some of the more common questions I'm being asked, and to present some new Shatter techniques that I've been working on (often at the suggestion of others). Corrections are immediately below, followed by some new techniques, and then finally some explanations to common questions I'm being asked.

I have working code to substantiate most of what I say in here, but don't expect me to release ANY of it. Don't even ask. I only wrote the code because a) I wanted to prove to my own satisfaction whether or not these things are possible, and b) because I'm a professional security consultant. Anything that escalates privileges is useful to me, so I'm using these tools for my job. When I say that something works you'll just have to either take my word for it or write some code yourself to verify it. None of my code after Shatter is ever going to be released. Please don't waste my time and yours by asking for it.

The information contained in this followup is just the tip of the iceberg, believe me. Every time I work on Smashing (my own exploit code) I think of new techniques to try, new code injection mechanisms, and new services to exploit. These things are everywhere. There's a lot of ways to exploit them too - don't believe for a second that simply filtering WM_TIMER is going to fix this. It's not. One chap wrote an application to try and prove that message filtering was the solution to Shatter attacks. He successfully filtered WM_TIMER messages for the edit control in his test app, but forgot to filter the messages for the parent window. It took me less time to shatter his application than it did to write out an email explaining to him how to repeat my results. Smashing is now a generic exploit mechanism for these attacks, and adding new examples is trivial. I'm willing to bet that there are dozens of people around the world writing similar applications. My point has been proved - these vulnerabilities are everywhere, and they're going to keep on biting anyone trying to keep a system secure. Internet cafes beware.


Clarifications

A few things I got a little bit wrong...:)

1. WM_TIMER DOES get placed in the message queue. Yes, the application has the choice of whether or not to process the message. The problem is that unless a new handler for WM_TIMER has been installed, it's caught by DefWindowProc(), which conveniently jumps to the callback address, if specified. Yes, you can filter it out. No, that won't solve the problem (read on for why).