Page 3 of 3 FirstFirst 123
Results 31 to 36 of 36

Thread: Mysteries of win32k & GDI

  1. #31
    omega_red: Looks like I'll be making it at Blackhat after all. Thanks again for making me look down some common paths as the issue you've brought up. Don't worry, the talk won't be about your bug per se, since that's your own work. But I'll definitely mention you when I bring up your bug as an example!
    Best regards,
    Alex Ionescu

  2. #32
    Yep, these bugs are fixed in Vista, so probably elsewhere. But not in Xp, unfortunately.

    I've not said it is simple to exploit them, i just pointed that just opening w2k shown up quite a number of exploitable weaknesses, just in a bunch hours of free-time, hobby analysis. Which is surely not very encouraging, if we are talking about the overall security of it, no?

    About w2k and rtl... no. w2k in xp does use ntos for supporting wide chars, many RTL operations, memmoves etc. unless it does cross-ref ntos export calls in whole w2k code for joke and fun...
    This is not true for Vista, which uses its own embedded RTL code to do the same things (comparing the codes, it seems that the vista build just embedded the RTL at compile time using a compiler option, since code is 'almost' identical, bug included).

    But it is irritating to open a critical OS file and find such weaknesses with virtually no analysis spent over it. Because such bugs (like the vsprintf one) are huge, easily spottable and ...and we are in 2k8.
    I want to know God's thoughts ...the rest are details.
    (A. Einstein)
    ..."a shellcode is a command you do at the linux shell"...

  3. #33
    1) Four disclosures and a BlackHat talk later, Microsoft in their infinite wisdom decided not to fix one of the bugs I talked about (related to the Winlogon issue dELTA found), and even make it worse by adding two more functions that exhibit the same bugs (these ones leading to privilege escalation, not just Dos!) So if you attended/read my paper on "pointer assumptions" on the CSRSS/desktop issue, well the bug is still there (and in multiple system calls)
    2) In Win7, the Win32k.PDB now contains all the user types, like tagTHREADINFO & friends. I don't know if it's an oversight, but it's making analysis much easier

    Just wanted to update this thread
    Best regards,
    Alex Ionescu

  4. #34
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Ring -1
    Blog Entries
    Hey Alex, nice to have you passing by, and thanks for the update.

    For the sake of truth and honesty though, it was omega_red that found the bug, not me.

    I was just the annoying guy who chatted you up after the above mentioned Black Hat talk.
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

  5. #35
    Errr crud, sorry omega_red, no disrespect intended!

    Thanks dELTA

    So maybe anyone has some suggestions? This latest bug has two possibilities:

    1) A race condition in which you can increment any value of your choice (the race can be made to work 100% of the time). After the race, the value is restored back.
    2) A condition in which you can OR the value 2 to any value of your choice.

    Just curious what some of you would do to "weaponize" this?

    For both of these, I went back to my 2003 subversion whitepaper, in which I re-enabled access to \Device\PhysicalMemory by patching the kernel.

    The check basically does this:

    if (AccessMode == UserMode) && (Object->Flags & PROTECTED) fail;

    The assembler is really: if (AccessMode == KernelMode) break; if (ObjectFlags & PROTECTED) break; fail;

    For #1, I simply patch KernelMode to UserMode (0 + 1 = 1) during the race, and then I can get my handle.

    For #2, I patch KernelMode to IllegalMode (0 + 2 = 2) and then patch the je in the if with jbe (je + 2 is jbe). Thus the code becomes (if AccessMode <= 2) break;, which means the protected check is not done anymore.

    The problem is this requires a Vista system with > 255MB memory (easy) or a Win 7 system with > 2GB (harder) since Large Pages are not enabled otherwise, meaning the kernel will be R/O.

    On 64-bit, PatchGuard becomes an issue.

    So just out of curiosity, what are some things you'd think of doing with a 1-byte increment (which is volatile/temporary) or a 2-byte OR (which is permanent, but it's an OR) to elevate from user to kernel, that don't involve code patching.
    Best regards,
    Alex Ionescu

  6. #36
    Quote Originally Posted by aionescu View Post
    Errr crud, sorry omega_red, no disrespect intended!
    No problem, I'm glad that you actually took your time to investigate this!
    Vulnerant omnes, ultima necat.

Similar Threads

  1. A story of win32k!cCapString, or unicode strings gone bad.
    By j00ru vx tech blog in forum Blogs Forum
    Replies: 0
    Last Post: April 16th, 2013, 10:21
  2. patching win32k.sys
    By tlgspk in forum Advanced Reversing and Programming
    Replies: 0
    Last Post: December 13th, 2012, 00:55
  3. Analyzing local privilege escalations in win32k
    By Uninformed Journal in forum Blogs Forum
    Replies: 0
    Last Post: October 19th, 2008, 01:01
  4. Null pointer dereference in win32k
    By OpenRCE_omega_red in forum Blogs Forum
    Replies: 0
    Last Post: November 24th, 2007, 18:50
  5. Mysteries of win32k & GDI - Win32Thread
    By OpenRCE_omega_red in forum Blogs Forum
    Replies: 0
    Last Post: November 24th, 2007, 18:50


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts