Regardless of whether you are a Windows exploitation guru, a professional win32 application developer or someone whose curiosity occasionally tells him to dig up the MSDN library looking for interesting quirks or undocumented functionality, the following examples of MSDN article excerptions are very likely to look familiar to you:
Simply put, the operating system operates on an enormous number of structures, unions and flags defined and developed throughout the 20+ years of Windows being around. Many of them are used internally within userland, kernel space or both parts of a specific functionality implementation, while typical developers never get a chance to even learn about them. Often times, however, these constructs are used to actively communicate with the operating system from within third-party software, be it a regular word processor or a custom device driver for an uncommon sound card. While reading through the Microsoft documentation library (perhaps this also applies to other environments?), it is exceedingly easy to stumble upon a sentence like “don’t use it”, “always set it to zero” or “if you use it,
Windows might format your C: disk you can encounter undefined behavior”. It always sounds very mysterious, but in reality, there can be only several different reasons for that:
- The item is in fact reserved for future use and disregarded by the current implementation, thus one could get away with setting it to an unsupported value at this point, but might face compatibility issues when the parameter, field or flag becomes fully functional. Not very interesting from a security or research perspective.
- The item is supported, but reserved for use in a different context: for example, employed within a system process with higher privileges or a system DLL.
- The item is supported, but Windows reserves the right to behave in an undefined way in case a specifically described (invalid) state of a structure, one of its field or a parameter is encountered.
Now, providing the user with an ability to even attempt to perform forbidden operations is often tricky and very easy to get wrong. In theory, all components of the operating system should perform strict verification in order to determine whether all input data obtained from an untrusted source (in a given security model) meets the requirements and restrictions established in the documentation. What we observe is different though – Windows often lacks proper sanitization in such cases. Additionally, rather than working in a security by obscurity manner (“it’s not clear how it works, I’ll just leave it alone”), such reserved or undefined places are usually a clear indicator that something fishy is going on there and it might be worth a deeper investigation. After all, it’s not such a rare phenomenon that the operating system trusts that a specific interface would never be used in an unexpected way – and if it does, we might end up being able to perform certain operations that we wouldn’t be normally allowed to (we’re talking privilege escalation here), or just finding out how a specific system mechanism works internally. One great example of the latter is the KEY_CREATE_LINK flag: reserved for system use, but reverse engineered and used to build third-party applications that can create registry symbolic links, despite it being formally not supported! In fact, when we looked at it several years back, the mechanism turned out to have never been properly reviewed, so we managed to spot quite a few vulnerabilities related to this very functionality, all resolved by MS10-021. Also, I don’t have to mention that when “undefined behavior” means a buffer overflow within a kernel pool allocation, it’s really appealing, too :)
Grepping through the entire MSDN library in search of those special keywords is a very intuitive idea that comes to mind. I have recently done just that, but it appears that I already have a lot of plans for the few incoming months, so I decided to share these logs with a wider audience – hopefully you will be able to put them to good use by finding yourself a good research subject, or at least spend a nice evening looking through the list for entertainment purposes :) Please don’t mind my poor HTML/CSS skills, I am really not a website designer…
Note: I have put together a list of seven phrases that I found most frequently indicating interesting spots in the documentation. If you have any more cool ideas of what to look for, let me know and I’ll consider them!
Microsoft MSDN User-Mode Library keyword grep report: https://j00ru.vexillium.org/msdn/user.html.
Microsoft MSDN Kernel-Mode Library keyword grep report: https://j00ru.vexillium.org/msdn/kernel.html.
7 thoughts on “Crawling MSDN for fun and profit”
Would a search for just “reserved” give too many false positives?
@Peter Jaric: Unfortunately, yes. There are just so many instances of “reserved” fields which really are reserved (i.e. aren’t used for anything) for it to be an effective keyword.
Comments are closed.