Skip to content

Kernel double-fetch race condition exploitation on x86 – further thoughts

Ten post nie jest dostępny w języku polskim!

{ 3 } Comments

  1. Adam | 28-cze-13 at 10:07:03 | Permalink

    Thanks for the follow-up on the extremely long white paper (yes, I read all 65 pages).

    Some constructive feedback: Please remember to label the graphs (e.g. the Y axis on almost every Figure). If there’s three different definitions, maybe label them in various colors. Based on context, I was able to figure it out eventually for all of them except Figure 15.

    Also, I was confused near the beginning as how you were varying the number of instructions between the first and second access. I thought that would be determined by the specific vulnerability, and I was having trouble understanding how an attacker would be able to manipulate that. Eventually I figured out that they can’t (short of just going and finding another vuln), but it was just an example of how these techniques will work on different vulns.

    The time lines were very helpful!

    I’m very anxious to see the specifics on how you modified the emulator. Pages 16-21 of the paper conveyed the gist of it, but the details are still not entirely clear to me. I think when I see the code, that little light bulb will go on in my head.

  2. j00ru | 01-lip-13 at 07:55:17 | Permalink

    Thanks for the feedback, Adam. I updated the charts I figured would actually require the y-label.

    The post refers to different time window lengths, which are related to the number of instructions, but are often also controlled by the attacker. A piece of code which makes for the window between two fetches can take different numbers of cycles, depending on whether it contains references to user-mode memory (which ring-3 code can slow down, as shown in our white-paper), contains variable-iteration loops etc. That’s why we refer to window sizes here – we have tried to establish how useful it is to extend the time window with available techniques, and at which point it doesn’t make sense anymore.

    You’ll get the instrumentation source code fairly soon, Black Hat is only a month away now. :)

  3. jrod | 18-lut-14 at 05:11:10 | Permalink

    One thing I don’t see: what is the solution/fix/prevention? Can you show code examples of how to prevent this bug?

{ 1 } Trackback

  1. […] the scope of one system call, and produce meaningful reports. The project was called Bochspwn [1][2][3] (or kfetch-toolkit on Github) and was largely successful, leading to the discovery of several […]

Post a Comment

Your email is never published nor shared. Required fields are marked *