j00ru//vx tech blog

(Collaborative post by Mateusz “j00ru” Jurczyk & Gynvael Coldwind)

Early Sunday morning discussion has resulted in j00ru coming up with an idea to mitigate some variants of kernel exploitation techniques by introducing a CPU feature that would disallow execution control transfers in kernel-mode to code residing in user memory area pages (e.g. addresses < 0x80000000 on a 32-bit Windows with default settings). The idea was that the system would mark every page as either being allowed to execute code in ring-0 or not. And hey, guess what… Intel has already proposed such a feature a month ago! Furthermore, it seems that this exact idea was already described in 2008 by Joanna Rutkowska, and two days ago she has published a follow up post on her blog.

The feature is called Supervisor Mode Execution Protection (SMEP for short) and it is documented in the newest release (May 2011) of the Intel manual 3A sections 2.5 (CR4.SMEP flag) and 4.6 (per memory page settings). For convenience reasons, we have quoted the related parts at the end of this post. Also, Dan Rosenberg has already (May 16, 2011) discussed, how this feature will interact with Linux and its specifics. To contribute to the discussion, we decided to do a similar write-up, and describe the implications of SMEP on Windows (and possible ways of bypassing it).

Read more

Although not the most common vulnerability class, it sometimes happens that a ring-0 module (or the kernel itself) references a local variable or buffer, which wasn’t previously properly initialized. The threat is usually mitigated by compiler warnings / errors, informing about potential security flaws present in the source code – as life shows, it is not always enough to avoid serious vulnerabilities of that kind. Having the knowledge about a buggy function, one might stumble upon a serious problem – how to actually make use of the information in a beneficial way (e.g. execute code in the security context of the faulty function – here, kernel-mode). The problem actually boils down to another matter – how can one control the trash bytes present on the ring-0 stack, from within a ring-3 perspective. It is primarily caused by the fact that each thread present on the Windows platform has two separate, dedicated stacks – a user- and kernel-mode one. Such security design obviously limits any possibility for an application to poke with the execution path of a highly-privileged code. Unfortunately, it also narrows down the amount of controllable data, which the user is able to (indirectly) move to the ring-0 stack… or does it? In this post, I am going to focus on my recent, minor discovery, which makes it possible to insert large amounts of arbitrary data into the stack memory areas of the current thread.

In the remaining part of the post, an assumption is made that the faulty device driver code runs in the same thread context as the code that actually triggers the vulnerability.

Read more

While performing some random research related to the WIN32K.SYS driver syscalls a few months ago, I stumbled on an interesting finding – when examining the full 32-bit (or in the case of the original research – 64) return values, some of the services seemed to return unusual numbers, for example 0xfffffa8000ea0000. After investigating the subject for a while, it turned out that a part of the WIN32K syscall interface indeed does not always return a value of the native CPU size (as opposed to the core NT kernel). Instead, some of the graphical services seem to be explicitly declared as:

VOID NtUserRandomService( ... )

 or

USHORT NtUserRandomService( ... )

Funny enough to find such types of quirks in the Windows kernel, eh? A list of the flawed syscall names is as follows:

• ETHREAD (full disclosure)
  • NtUserAlterWindowStyle
  • NtUserSetThreadState
  • NtUserNotifyWinEvent
  • NtUserModifyUserStartupInfoFlags
  • NtUserSetThreadLayoutHandles
  • NtUserNotifyIMEStatus
  • NtUserSetThreadLayoutHandles
  • NtUserSetRipFlags (Windows XP only)
  • NtUserSetDbgTag (Windows XP only)
• ETHREAD (partial disclosure)
  • NtUserRegisterClassExWOW
  • NtUserGetKeyState
  • NtUserGetAsyncKeyState
  • NtUserVkKeyScanEx
  • NtUserSetWindowWord
  • NtUserSetClassWord
• W32THREAD (full disclosure)
  • NtGdiEngUnlockSurface
  • NtGdiPATHOBJ_vEnumStartClipLines
  • NtGdiEngDeletePath
  • NtGdiEngDeleteClip
  • NtGdiFONTOBJ_vGetInfo
• Other (unknown?)
  • NtGdiFlush
  • NtGdiEngUnlockSurface

Read more

Around three weeks ago, Bartek announced a competition called “Pimp My CrackMe” on his http://secnews.pl/ website. The main prize was a free pass to the CONFidence 2011 conference, which is going to take place in on 24-25 May, in Cracow. The task was to create an interesting CrackMe program, which would then be judged based on its difficulty level (on the other hand, it had to be solvable), inventiveness of the applied techniques, and general visual presentation. Since I wasn’t yet registered on the conference at the time of the announcement, I decided to take part in the contest – traditionally, teamed up with Gynvael Coldwind. The final results were eventually declared yesterday evening; it seems that me made it to the first place ;)

There were three crackmes reported, in total – as Gyn says: It’s not bad, but I was hoping for a higher scene activity. What should be noted, is that based on the number of submitted programs, the organizer managed to get another two conference admissions, so that all of the contest participants are rewarded. Well done!

The complete results, together with the Jury‘s justification of the decision, is presented below:

1. Mateusz “j00ru” Jurczyk & Gynvael Coldwind

   For an interesting approach to the serial number verification problem, technical aspects related to how the CrackMe works, and an unusual interface.

2. hasherezade

   For a custom encryptor (and the effort put in making it function correctly), and an interesting verification algorithm.

3. Grzegorz “haker500” Jastrzębski

   For the willingness of taking part in the competition and creating a CrackMe in assembly.

Read more

Today, I would like to present the fifth issue of the well-known Hack In The Box e-magazine, originally brought back to life by Zarul Shahrin, in January last year (see the complete release history here). As usual, every Windows Internals maniac can find something for himself: this time, I described some of the most interesting parts of the Windows Subsystem (commonly known as CSRSS) internals, or more precisely, the potential advantages one can take from the undocumented mechanisms found in the subsystem (e.g. obfuscating a local thread creation). Besides this one article, you can also find another five write ups, related to Linux and Network Security, as well as professional development. Most of all, however, I would like to recommend the Interview section, where a well known RE community figure – Rolf Rolles – talks about his current occupation and shares his thoughts about the current state of the reverse engineering world.

Read more

I would like to present the results of a research performed by Gynvael Coldwind and me during the last three or four weeks – an almost 40-page long article, entitled “Exploiting the otherwise non-exploitable: Windows Kernel-mode GS cookies subverted” (yes, that’s an obvious reference to the “Exploiting the otherwise non-exploitable on Windows” by Skywing and Skape, Uninformed 4). The paper aims to describe the current protection level of a specific stack protection found in a majority of Windows device drivers (both default and 3rd party) – the GS cookies, and cover the cookie generation weaknesses, found in the actual protection implementations on Windows XP, Windows Vista and Windows 7 (both 32-bit and 64-bit platforms).

As it turns out, all of the entropy sources used to form the final cookie value – preventing the attacker from hijacking the return address – are extremely weak, and therefore easy to guess or calculate by a potential attacker. A total of five cookie-prediction techniques can be found in the article; three of which are designed to estimate the system tick count (the only truly unknown factor of the cookie value), with the highest possible accuracy degree. Apart from theoretical considerations, we have also performed a number of practical tests, proving the real effectiveness of the presented methods. By making use of the most precise measurement techniques we are currently aware of, we have managed to reach around 50% of cookie prediction reliability (and thus, the same degree of stack-based vuln exploitability).

Read more

Traditionally – during the annual, last Hack in the Box 2010 conference edition held in Kuala-Lumpur, Malaysia (follow HITBSecConf @ Twitter), an IT-security related magazine is released ;) Since three issues, I have been contributing to the paper with my Windows-oriented articles. This time, I would like to present a publication called Creating custom console hosts on Windows 7, describing the potential possibilities in the area of console windows’ customization, being a consequence of a design-level modification, introduced in the latest Microsoft operating system – you’re encouraged to download, read, and criticize, as well as share ideas regarding the subject. Have fun.

Additionally, the editors have also put a few, particularly interesting articles from the past HITB Magazine editions. I am very happy to announce that one of the Reader’s Choice papers is my publication – Windows Objects in Kernel Vulnerability Exploitation – originally released in HITB eZine 002. This gives us a total of two papers authored by me – if you haven’t had the chance to take a look at either of them, feel free to do so. The article (as well as all of the other ones) was given a new, brilliant graphics outfit, making the entire issue pleasant for the eye, and rich in practical knowledge ;)

Read more

Before I start talking (writing?) about the real subject of this short post, I would like to make some interesting announcements.

1. My friend mawekl has recently fired up a project called Security Traps. The website consists of numerous IT-related challenges, ranging from typical JavaScript-hackmes, through Windows software Reverse Code Engineering tasks, up to C/C++ riddles and logical puzzles. If searching for non-trivial solutions of simple problems is what you like, taking a look at the system might appear to be both entertaining and informative – at least, it was for me ;)
   BTW. Try to beat the top2 players ;D.
2. a_d_13, the http://kernelmode.info/ forums administrator and author of the RootRepeal anti-rootkit software has published an interesting tool called MemMAP v0.1.2, just a few minutes ago. The interesting thing about the program is that it was originally inspired by what I released in January this year: the tiny KernelMAP. AD’s application greatly enhances my idea of memory visualization, by including additional kernel memory areas (kernel stacks and GDI objects), as well as makes it possible to observe the contents of user-mode memory. Feel encouraged to take a look at the production and possibly share interesting screens of the program output ;)

Now, to the point. In the most recent post, I tried to describe the ways of performing ring0-to-ring3 transitions on the Windows platform – in particular, the ways that were known to me at the time of writing the article. After publishing the entry, I had a few interesting conversations, and I was pointed out that there is at least one (possibly more) solution with the reliability level not lower than the nt!KeUserModeCallback method, claimed to be the best one. In this post, I am going to introduce yet another way of lowering the processor privilege level in a stable manner.

Read more

I have recently came across (well, not entirely by myself… cheers Nahuel!) a fairly (un)common problem related to performing ring0-to-ring3 transitions, after a successful kernel vulnerability exploitation. As I have managed to come up with a bunch of possible solutions, and even write example code for some of these, today I would like to present my thoughts, together with some brief explanation.

Introduction

Before trying to find a reliable solution to the problem, it should be clearly stated first. And so, we are considering a 32-bit Windows NT-family version (one of the supported ones), suffering from a stack-based buffer overflow inside one of the system call handler functions. The attacker is able to overwrite memory placed after a fixed-size buffer, including the stack frame, return address, syscall arguments and anything else reachable from this point. As opposed to the reality, we assume that there is no stack protection (i.e. a cookie) implemented, so the security flaw can lead straight into malicious code execution and system compromise. Furthermore, the overflow is triggered right inside the syscall handler, not a nested function of any kind.

The following ascii picture, presenting the stack layout at the time of the overflow, should give you a better insight of the described scenario:

Read more

A quick beginning note: My friend d0c_s4vage has created a technical blog and posted his first text just a few days ago. The post entry covers a recent, critical libpng vulnerability discovered by this guy; the interesting thing is that, among others, the latest Firefox and Chrome versions were vulnerable. Feel free to take a minute and read the article here.

Additionally, the video and mp3 recordings from the presentation performed by me and Gynvael on the CONFidence 2010 conference, are now publicly available on the official website: link (Case study of recent Windows vulnerabilities).

Foreword

A majority of the LPC /supposedly an acronym for Local Inter-Process Communication rather than Local Procedure Calls, as stated in WRK/ basics have been described in the first post of Inter-process Communication chapter, together with the corresponding, undocumented native functions related to LPC Ports. As you already have the knowledge required to understand higher abstraction levels, today I would like to shed some light on the internal Csr~ interface provided by NTDLL and extensively utilized by the Win32 API DLLs (kernel32 and user32).

Read more