Types of vulnerabilities - the missing scales on the dragon
Back after a busy time and a break. Sometimes we get pulled on to a critical issue where we burn a lot of cycles and have nothing that we can discuss publically after the event. I lost a week or so doing that and then headed off to Kefalonia for a week in the sun – and if anyone is considering going there then I recommend the White Rocks in Lassi.
Anyhow, none of that is about security so let me share some of the things that I was thinking of as I was lying by the pool. One thing that I haven’t done is discuss the different classes of exploit that we tend to be concerned about. Here is a more or less complete list:
1. Remote code execution (RCE). Any vulnerability which allows this is going to be rated as critical unless there are massive mitigations. I can think of one that was only rated as important but that required a number of really complex user actions to make the exploit work. These generally rely on bad buffer/structure checking and the ones that we are seeing are increasing really obscure – the recent Office ones were about streams in the OLE compound document. Not exactly a mainstream area.
2. Cross Side Scripting. This is script injection and is not always as serious as a remote code execution because the script is often limited in what it can do. That said, if you can inject script to be run from a system account then that would be pretty nasty. These are not all that common with the exception of SQL injection attacks which many applications are vulnerable to.
3. Elevation of Privilege. Not good. Basically, this class of vulnerability allows running code to do things that that should not be possible for that user – it might be able to do something from a different account (see “shatter attacks”) or jump in to Kernel mode to do something nasty. Of course, you have to able to run code on the machine so this sort of attack is most dangerous when used as part of a blended attack.
4. Information disclosure. These are not typically the sort of vulnerabilities that cause great concern among users. Vulnerabilities of this type in the past have allowed web pages to be able to look at part or all of a clipboard entry or tell if a particular filename was used on that system. By themselves, these tend to be relatively harmless although there are obvious exceptions – disclosing a password for example. However, the last one that I recall offhand let you see the first 2 characters of a text box remotely. This is typically worthless to a criminal.
5. Spoofing. Not normally of identity but more commonly of interface. If we allow a webpage to display an address different to its real address then that would be spoofing – and indeed, there are a couple of ways in which that can be done. The most trivial way to do it would be to have a webpage with no borders but which had bitmaps that looked like borders and an address bar. It is often difficult to prevent pages from doing this although IE7 goes a long way towards addressing this.
6. Impersonation – of course, it is sometimes perfectly legitimate for a process to run as a different user. DCOM is set up with that as a central concept and is COM+. However, if an attacker can pretend to be a user due to poor validation, there is a vulnerability. This is sometimes by poor design and sometimes by poor administration. Many years ago when I was young and foolish, I noticed that the Unix systems at university did not protect data streams very well although file areas were excellently protected. Hijacking the text output and text input streams allowed me to act as Root. This class of vulnerability is not commonly found although there is one area of cybercrime that often relies on this. It is trivially easy to spoof the headers of SMTP messages – the design was created for a more trusting time. Accordingly, we all get messages apparently from our banks, paypal or whoever.
7. Blended attacks – these are attacks that use more than one of these at once – remote code execution will often get you in to a context where the user has very few rights and the code can not do much. Getting in to LocalSystem with no network rights doesn’t help a Worm spread. In those cases, using elevation of privilege or some other weakness in conjunction is the way to go.
I will talk about how to avoid at least some of these in future post.
Oh, by the way, just a little housekeeping thing. This is just my blog. The MSRC blog at https://blogs.technet.com/msrc/ is the definitive Microsoft Security Blog. If it says one thing and I say another then I am wrong. Should we have a major issue that you need to know about, look there and not here. Think of this as a place where you might find the odd nugget of value but the MSRC blog as the mother lode :-)
Until next time
Mark