Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 36

Thread: Mysteries of win32k & GDI

  1. #16
    Thanks omega_red... I just found this thread and looked around Win32k.sys a bit last night and found four vulnerabilities, including the one you mentioned --Microsoft was wrong to assume this can only happen before Winlogon loads! (Sorry for being vague -- you know how disclosure works).

    I sent reports to my friends over at MSFT, but these bugs are so fun I'd love to give a talk at Blackhat about them as soon as they release patches!
    --
    Best regards,
    Alex Ionescu

  2. #17
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    Cool!
    (Maybe I'll see you in Vegas then... )
    "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."

  3. #18
    Hehe, nice that you've found something interesting Alex. I suspected that this could be more serious, but I've never been much into the software vulnerabilities area. Any code execution stuff in there?
    Vulnerant omnes, ultima necat.

  4. #19
    rofl Win32 must be a gold-mine for bugs. Didnt even have the time to examine it...

    Code:
    EngDebugPrint(PCH MyPrefix, char *DebugMsg, va_list MyArgList)
    {
      ULONG nBugCheck;
      char MyCool256byteBuffer[256];
    
      nBugCheck = BugCheckParameter2;
      DbgPrint(MyPrefix);
      vsprintf(MyCool256byteBuffer, DebugMsg, MyArgList);
      return DbgPrint(MyCool256byteBuffer);
    }
    I am curious to know what's happen if my DebugMsg is >256... will my OS bsod in mysterious ways?

    being it a DEBUG function, it reinforces my idea that for working at M$ you are thoroughly tested thru an IQ test and taken if...

    ----edit
    ouch, how can i make the code box bigger?!
    ----edit 2
    * Every driver that uses this function i.e. in response to IOControls with string data or such might be used to access R0, of course.
    * Every poor driver developer that output a string by this way is exposed to WTF! crashes...
    * etc. etc.
    Last edited by Maximus; January 29th, 2008 at 10:34. Reason: some usage footnotes...
    I want to know God's thoughts ...the rest are details.
    (A. Einstein)
    --------
    ..."a shellcode is a command you do at the linux shell"...

  5. #20
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,083
    Blog Entries
    5
    Quote Originally Posted by blabberer View Post
    playing a little with userkdx a little i accidently found that _w32threadifno type info is available in xp as well

    Code:
    lkd> dt  win32k!_W32THREAD -v -b e252eeb0
    struct _W32THREAD, 10 elements, 0x28 bytes
       +0x000 pEThread         : 0x80e0db68
       +0x004 RefCount         : 1
       +0x008 ptlW32           : (null)
       +0x00c pgdiDcattr       : (null)
       +0x010 pgdiBrushAttr    : (null)
       +0x014 pUMPDObjs        : (null)
       +0x018 pUMPDHeap        : (null)
       +0x01c dwEngAcquireCount : 0
       +0x020 pSemTable        : (null)
       +0x024 pUMPDObj         : (null)
    ...and some months later... I found something that seems to confirm this structure definition of ETHREAD.Win32Thread is correct.

    I was looking at some of the win32k!Eng*Semaphore functions, which is entirely the fault of Maximus :

    http://community.reverse-engineering.net/viewtopic.php?f=10&t=6647

    Specifically I was trying to figure out why the offset HSemaphore+0x18 points to an ETHREAD structure in the function EngIsSemaphoreOwnedByCurrentThread.

    While looking at EngAcquireSemaphore I saw that it increments W32THREAD.dwEngAcquireCount at 0x1C as posted by blabberer.

    Code:
    EngAcquireSemaphore(
        IN HSEMAPHORE  hsem
        );
    
    :BF806E7A __stdcall EngAcquireSemaphore(x) proc...
    :BF806E7A Resource        = dword ptr  8
    :BF806E7A
    :BF806E7A                 mov     edi, edi
    :BF806E7C                 push    ebp
    :BF806E7D                 mov     ebp, esp
    :BF806E7F                 mov     ecx, [ebp+Resource] ; Resource
    :BF806E82                 call    GreAcquireSemaphore(x)
    :BF806E87                 call    ds:PsGetCurrentThread()
    :BF806E8D                 push    eax
    :BF806E8E                 call    ds:PsGetThreadWin32Thread(x) // returns ETHREAD.Win32Thread
    :BF806E94                 test    eax, eax
    :BF806E96                 jz      short loc_BF806E9B
    :BF806E98                 inc     dword ptr [eax+1Ch] / W32THREAD.dwEngAcquireCount
    :BF806E9B
    :BF806E9B loc_BF806E9B:                           ; CODE XREF: EngAcquireSemaphore(x)+1C
    :BF806E9B                 pop     ebp
    :BF806E9C                 retn    4
    :BF806E9C __stdcall EngAcquireSemaphore(x) endp
    Unfortunately those Eng* functions can only be used from display drivers and not kernel mode drivers, so it's a little tricky to suss 'em out.

    Kayaker

  6. #21
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,487
    Blog Entries
    15
    Unfortunately those Eng* functions can only be used from display drivers and not kernel mode drivers, so it's a little tricky to suss 'em out.
    if some fortunate or unfortunate soul tries to suss em out here is a little hack
    to get all those sussed out information back to original win32k.sys 's PDB

    so that windbg or livekd recognises them without any problems

    1) you would need ddk or wdk or whatever rtm it is called nowadays
    for the cl.exe and build environment

    2) you would need a c file that contains the definitions like blah.c

    you would need the following command to put your blah.c information into
    microsofts pdb file

    here is the command line

    Code:
    C:\win32kpdb>cl.exe /Zi /Gz /c /Fdwin32k.pdb /ID:\WINDDK\3790~1.183\inc\wxp /ID:
    \WINDDK\3790~1.183\inc /ID:\WINDDK\3790~1.183\inc\crt /ID:\WINDDK\3790~1.183\inc
    \ddk\wxp /ID:\WINDDK\3790~1.183\inc\hal\wxp /ID:\WINDDK\3790~1.183\inc\ifs\wxp /
    ID:\WINDDK\3790~1.183\inc\mfc42 /ID:\WINDDK\3790~1.183\inc\wxp /ID:\WINDDK\3790~
    1.183\inc\processor /ID:\WINDDK\3790~1.183\inc\ddk\wdm\wxp /D_X86_=1 tagthread.c
    i used specific include paths specific to my setup of ddk your mileage may vary you would need to define _x86_ macro
    tag thread.c is the file that contains the information that i added to win32k.sys file

    whose contents at that time of experiment was

    Code:
    #include <ntddk.h>
    
    typedef void  *POINTER;
    
    typedef POINTER   PDESKTOPINFO;
    typedef POINTER   PPROCESSINFO;
    typedef POINTER   PTL;
    typedef POINTER   PQ;
    typedef POINTER   PKL;
    typedef POINTER   PCLIENTTHREADINFO;
    typedef POINTER   PDESKTOP;
    typedef POINTER   PCLIENTINFO;
    typedef POINTER   PSMS;
    typedef POINTER   PMENUSTATE;
    typedef POINTER   PTDB;
    typedef POINTER   PWINDOWSTATION;
    typedef POINTER   PSVR_INSTANCE_INFO;
    typedef POINTER   PMOVESIZEDATA;
    typedef POINTER   PSBTRACK;
    typedef POINTER   PWND;
    typedef POINTER   PIMC;
    typedef POINTER   PQMSG;
    typedef POINTER   PCLS;
    typedef POINTER   PWOWPROCESSINFO;
    typedef POINTER   PDESKTOPVIEW;
    typedef POINTER   PCURSOR;
    typedef POINTER   PW32JOB;
    typedef POINTER   KERNEL_ULONG_PTR;
    
    typedef PTHREADINFO;
    typedef PHOOK;
    
    typedef struct tagCLIENTTHREADINFO {
        UINT        CTIF_flags;
        WORD        fsChangeBits;           // Bits changes since last compared
        WORD        fsWakeBits;             // Bits currently available
        WORD        fsWakeBitsJournal;      // Bits saved while journalling
        WORD        fsWakeMask;             // Bits looking for when asleep
        LONG        timeLastRead;           // Time of last input read
    } CLIENTTHREADINFO;
    
    
    typedef struct tagPROCESSINFO {      //W32PROCESS;
     //***************************************** begin: USER specific fields
     PTHREADINFO     ptiList;                    // threads in this process
     PTHREADINFO     ptiMainThread;              // pti of "main thread"
     PDESKTOP        rpdeskStartup;              // initial desktop
     PCLS            pclsPrivateList;            // this processes' private classes
     PCLS            pclsPublicList;             // this processes' public classes
     PWOWPROCESSINFO pwpi;                       // Wow PerProcess Info
    
        PPROCESSINFO    ppiNext;                    // next ppi structure in start list
     PPROCESSINFO    ppiNextRunning;
     int             cThreads;                   // count of threads using this process info
        HDESK           hdeskStartup;               // initial desktop handle
        UINT            cSysExpunge;                // sys expunge counter
        DWORD           dwhmodLibLoadedMask;        // bits describing loaded hook dlls
     HANDLE          ahmodLibLoaded[CLIBS];      // process unique hmod array for hook dlls
     PWINDOWSTATION  prpwinsta; // process windowstation
     HWINSTA         hwinsta;                    // windowstation handle
        ACCESS_MASK     amwinsta;                   // windowstation accesses
    
     DWORD           dwHotkey;                   // hot key from progman
        HMONITOR        hMonitor;                   // monitor handle from CreateProcess
     PDESKTOPVIEW    pdvList;                    // list of desktop views
     UINT            iClipSerialNumber;          // clipboard serial number
     RTL_BITMAP      bmHandleFlags;              // per handle flags
     PCURSOR         pCursorCache;               // process cursor/icon cache
        PVOID           pClientBase;                // LEAVE THIS FOR HYDRA; offset to the shared section
        DWORD           dwLpkEntryPoints;           // user mode language pack installed
    
     PW32JOB         pW32Job;                    // pointer to the W32JOB structure
    
     DWORD           dwImeCompatFlags;           // per-process Ime Compatibility flags
     LUID            luidSession;                // logon session id
     USERSTARTUPINFO usi;                        // process startup info
    
    #ifdef VALIDATEHANDLEQUOTA
     LONG lHandles;
    #endif
    
    #ifdef USE_MIRRORING
     DWORD           dwLayout;                   // the default Window orientation for this process
    #endif
    
    } PROCESSINFO;
    
    typedef struct _HEAD {
     DWORD h; //HHOOK
     DWORD cLockObj;
    } HEAD, *PHEAD;
    
    typedef struct _THROBJHEAD {
     HEAD hdr;
     DWORD pti;
    } THROBJHEAD, *PTHROBJHEAD;
    
    typedef struct _DESKHEAD {
     DWORD rpdesk;
     DWORD pSelf;
    } DESKHEAD, *PDESKHEAD;
    
    typedef struct _THRDESKHEAD {
     THROBJHEAD tohdr;
     DESKHEAD dhdr;
    } THRDESKHEAD, *PTHRDESKHEAD;
    
    
    typedef struct tagHOOK {   /* hk */
     THRDESKHEAD     head;
     PHOOK           phkNext;
     int             iHook;              // WH_xxx hook type
     KERNEL_ULONG_PTR offPfn;
     UINT            flags;              // HF_xxx flags
     int             ihmod;
     PTHREADINFO     ptiHooked;          // Thread hooked.
     PDESKTOP        rpdesk;             // Global hook pdesk. Only used when
              //  hook is locked and owner is destroyed
    #ifdef HOOKBATCH
     DWORD           cEventMessages;     // Number of events in the cache
     DWORD           iCurrentEvent;      // Current cache event
     DWORD           CacheTimeOut;       // Timeout between keys
     PEVENTMSG       aEventCache;        // The array of Events
    #endif // HOOKBATCH
    } HOOK;
    
    
    
    
    typedef struct _THREADINFO {
        ULONG a[10];                   	 // W32THREAD
        PTL                 ptl;       	 // Listhead for thread lock list            +28
        PPROCESSINFO        ppi;       	 // process info struct for this thread        +2C
        PQ                  pq;        	 // keyboard and mouse input queue            +30
        PKL                 spklActive;   	 // active keyboard layout for this thread    +34
        PCLIENTTHREADINFO   pcti;      	 // Info that must be visible from client    +38
        PDESKTOP            rpdesk;
        PDESKTOPINFO        pDeskInfo; 	 // Desktop info visible to client            +40
        PCLIENTINFO         pClientInfo;	// Client info stored in TEB                +44
        ULONG               TIF_flags;  	// TIF_ flags go here.                        +48
        PUNICODE_STRING     pstrAppName;	// Application module name.                    +4C
        PSMS                psmsSent;    	// Most recent SMS this thread has sent
        PSMS                psmsCurrent;    // Received SMS this thread is currently processing
        PSMS                psmsReceiveList;// SMSs to be processed
        LONG                timeLast;       // Time, position, and ID of last message
        ULONG_PTR           idLast;
        int                 cQuit;
        int                 exitCode;
        HANDLE              hdesk;        // Desktop handle. Changed from "HDESK hdesk"
        int                 cPaintsReady;
        unsigned int        cTimersReady;
        PMENUSTATE          pMenuState;
        union {
            PTDB            ptdb;        	// Win16Task Schedule data for WOW thread
            PWINDOWSTATION  pwinsta;    	// Window station for SYSTEM thread
        };
        PSVR_INSTANCE_INFO  psiiList;   	// thread DDEML instance list
        ULONG               dwExpWinVer;
        ULONG               dwCompatFlags; 	// The Win 3.1 Compat flags
        ULONG               dwCompatFlags2; // new DWORD to extend compat flags for NT5+ features
        PQ                  pqAttach;    	// calculation variabled used in zzzAttachThreadInput()
        void*               ptiSibling;   	// Pointer to sibling thread info. Chnaged from "PTHREADINFO ptiSibling"
        PMOVESIZEDATA       pmsd;
        ULONG               fsHooks;    	// WHF_ Flags for which hooks are installed
        PHOOK               sphkCurrent;	// Hook this thread is currently processing
        PSBTRACK            pSBTrack;
        HANDLE              hEventQueueClient;
        PKEVENT             pEventQueueServer;
        LIST_ENTRY          PtiLink;      	// Link to other threads on desktop
        int                 iCursorLevel;   // keep track of each thread's level
        ULONG               b[2];        	//POINT           ptLast;
        PWND                spwndDefaultIme;// Default IME Window for this thread
        PIMC                spDefaultImc;  	// Default input context for this thread
        HANDLE              hklPrev;    	// Previous active. Changed from "HKL hklPrev"
        int                 cEnterCount;
        MLIST               mlPost;     	// posted message list.
        USHORT              fsChangeBitsRemoved;// Bits removed during PeekMessage
        WCHAR               wchInjected;    // character from last VK_PACKET
        ULONG               fsReserveKeys;  // Keys that must be sent to the active                +E0
        PKEVENT             *apEvent;       // Wait array for xxxPollAndWaitForSingleObject        +E4
        ACCESS_MASK         amdesk;         // Granted access                                    +E8
        unsigned int        cWindows;       // Number of windows owned by this thread            +EC
        unsigned int        cVisWindows;    // Number of visible windows on this thread            +F0
        PHOOK               aphkStart[CWINHOOKS];    // Hooks registered for this thread, local hook    +F4
        CLIENTTHREADINFO    cti;            // Use this when no desktop is available            +F8
    } THREADINFO, *PTHREADINFO;
    
    THREADINFO thinf;
    this is how you do it
    Code:
    copy the win32k.pdb from symbol cache into a folder
    copy this tagthread.c (this is crap i have changed many HWINSTA etc
    symbols to ULONG to fool errors and test
    
    and go to the build environment and pass the commandline
    
    copy back the new win32k.pbd to symbol cache (remember save original
    before replacing)
    
    go to kd and do dt _win32k!_Threadinfo <some address> here
    
    it should show some real information in formatted style
    
    like below if you are successfull
    result as follows

    Code:
    
    
    lkd> !ready
    Processor 0: Ready Threads at priority 8
       THREAD ff5e3020  Cid 0350.0b64  Teb: 7ffad000 Win32Thread: e123adc0 READY
       THREAD 810c0020  Cid 0314.07b0  Teb: 7ff8d000 Win32Thread: 00000000 WAIT
       THREAD ffbad020  Cid 0314.0330  Teb: 7ffdb000 Win32Thread: e2107a50 WAIT
       THREAD ff98bcb0  Cid 0350.0c24  Teb: 7ffde000 Win32Thread: e245c400 WAIT
       THREAD ff5e3020  Cid 0350.0b64  Teb: 7ffad000 Win32Thread: e123adc0 READY
    lkd> dt win32k!_Threadinfo e123adc0
    win32k!_THREADINFO
      +0x000 a                : [10] 0xff5e3020 <--- this is w32thread
    but i just took zairon post definition as it is to test
      +0x028 ptl              : (null)
      +0x02c ppi              : 0xe24db0c0
      +0x030 pq               : 0xe1080c18
      +0x034 spklActive       : 0xe20bcf08
      +0x038 pcti             : 0xbc662b18
      +0x03c rpdesk           : 0x810f0e10
      +0x040 pDeskInfo        : 0xbc630650
      +0x044 pClientInfo      : 0x7ffad6cc
      +0x048 TIF_flags        : 0x1000000
      +0x04c pstrAppName      : (null)
      +0x050 psmsSent         : (null)
      +0x054 psmsCurrent      : (null)
      +0x058 psmsReceiveList  : (null)
      +0x05c timeLast         : 0
      +0x060 idLast           : 0
      +0x064 cQuit            : 0
      +0x068 exitCode         : 40
      +0x06c hdesk            : (null)
      +0x070 cPaintsReady     : 0
      +0x074 cTimersReady     : 0
      +0x078 pMenuState       : (null)
      +0x07c ptdb             : (null)
      +0x07c pwinsta          : (null)
      +0x080 psiiList         : 0x00000400
      +0x084 dwExpWinVer      : 0
      +0x088 dwCompatFlags    : 0x10000
      +0x08c dwCompatFlags2   : 0
      +0x090 pqAttach         : 0xe153e8f8
      +0x094 ptiSibling       : (null)
      +0x098 pmsd             : (null)
      +0x09c fsHooks          : 0
      +0x0a0 sphkCurrent      : 0
      +0x0a4 pSBTrack         : 0x00000704
      +0x0a8 hEventQueueClient : 0xff9c3f40
      +0x0ac pEventQueueServer : 0xe153e9a4 _KEVENT
      +0x0b0 PtiLink          : _LIST_ENTRY [ 0xe1036e5c - 0x0 ]
      +0x0b8 iCursorLevel     : 0
      +0x0bc b                : [2] 0
      +0x0c4 spwndDefaultIme  : (null)
      +0x0c8 spDefaultImc     : (null)
      +0x0cc hklPrev          : (null)
      +0x0d0 cEnterCount      : 0
      +0x0d4 mlPost           : 0
      +0x0d8 fsChangeBitsRemoved : 0
      +0x0da wchInjected      : 0
      +0x0dc fsReserveKeys    : 0
      +0x0e0 apEvent          : (null)
      +0x0e4 amdesk           : 0
      +0x0e8 cWindows         : 0xf01ff
      +0x0ec cVisWindows      : 0
      +0x0f0 aphkStart        : [20] 0
      +0x140 cti              : 0
    lkd>
    
    have fun :)
    Last edited by blabberer; February 12th, 2008 at 11:59.

  7. #22
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,083
    Blog Entries
    5
    Thanks blabberer. I remember you showing me this a while back, I think in reference to this thread actually, and I can vouch that it works great. Might be a nice way to attach some of Alex Ionescu's NDK undocumented headers to Windbg output capabilities.

  8. #23
    Problem is that the structure is out-of-date...see 'PtiLink'.

    I've been using a similar trick of my own, but actually just load my module with a separate name, then I can do dt mymodule!_TYPE <ptr>.

    You can use .reload with a PDB and a valid kmode address and it usually works.
    --
    Best regards,
    Alex Ionescu

  9. #24
    Not sure where you got that, but in IDA I see:

    vsprintf_s

    Which is the "safe" version, and the length is set to 256.

    Quote Originally Posted by Maximus View Post
    rofl Win32 must be a gold-mine for bugs. Didnt even have the time to examine it...

    Code:
    EngDebugPrint(PCH MyPrefix, char *DebugMsg, va_list MyArgList)
    {
      ULONG nBugCheck;
      char MyCool256byteBuffer[256];
    
      nBugCheck = BugCheckParameter2;
      DbgPrint(MyPrefix);
      vsprintf(MyCool256byteBuffer, DebugMsg, MyArgList);
      return DbgPrint(MyCool256byteBuffer);
    }
    I am curious to know what's happen if my DebugMsg is >256... will my OS bsod in mysterious ways?

    being it a DEBUG function, it reinforces my idea that for working at M$ you are thoroughly tested thru an IQ test and taken if...

    ----edit
    ouch, how can i make the code box bigger?!
    ----edit 2
    * Every driver that uses this function i.e. in response to IOControls with string data or such might be used to access R0, of course.
    * Every poor driver developer that output a string by this way is exposed to WTF! crashes...
    * etc. etc.
    --
    Best regards,
    Alex Ionescu

  10. #25
    !!
    thanks, but this leaves me with a big problem now... what's happened to the win2k.sys of THIS machine!? The code I see is different, and WinUpdate is ON (even if in manual mode).
    mmh...
    edit------------
    mmh... only some minor, optional update is missing... oook. I'll check on other windows machines...
    Last edited by Maximus; February 18th, 2008 at 11:56.
    I want to know God's thoughts ...the rest are details.
    (A. Einstein)
    --------
    ..."a shellcode is a command you do at the linux shell"...

  11. #26
    vsprintf_s

    Which is the "safe" version, and the length is set to 256.
    out of curiosity, i checked today other windows versions. I do not see it nor in others XP (updated&original), not in 2k3server.
    the call is made by 3 parameters, not 4 as vsprintf_s requires. Also, i do not see the '256' anywhere.

    What strange version of Windows XP are you using? Is there a version of WinXP which uses vsprintf_s and my xppro uses it not?

    aaah i see now what you are looking. Well, please ask to your MS friends if they can fix this in other OSes too -especially XP
    I dont like much Vista...
    Last edited by Maximus; February 22nd, 2008 at 16:59.
    I want to know God's thoughts ...the rest are details.
    (A. Einstein)
    --------
    ..."a shellcode is a command you do at the linux shell"...

  12. #27
    Can you confirm that on SRV03SP1 this function still uses strcpy with no extra validation? That's pretty disgusting. The bug isn't there on Vista.
    --
    Best regards,
    Alex Ionescu

  13. #28
    XP SP2 5.1.2600.3099: The bug exists, but is mitigated by GS cookies:

    Code:
    .text:BF9332A4 ; int __stdcall EngDebugPrint(PCH Format,int,int)
    .text:BF9332A4   public _EngDebugPrint@12
    .text:BF9332A4 _EngDebugPrint@12 proc near
    .text:BF9332A4
    .text:BF9332A4 var_104= byte ptr -104h
    .text:BF9332A4 var_4= dword ptr -4
    .text:BF9332A4 Format= dword ptr  8
    .text:BF9332A4 arg_4= dword ptr  0Ch
    .text:BF9332A4 arg_8= dword ptr  10h
    .text:BF9332A4
    .text:BF9332A4   mov   edi, edi
    .text:BF9332A6   push  ebp
    .text:BF9332A7   mov   ebp, esp
    .text:BF9332A9   sub   esp, 104h
    .text:BF9332AF   mov   eax, gscookie
    .text:BF9332B4   push  esi
    .text:BF9332B5   mov   esi, [ebp+arg_4]
    .text:BF9332B8   mov   [ebp+var_4], eax
    .text:BF9332BB   mov   eax, [ebp+Format]
    .text:BF9332BE   push  edi
    .text:BF9332BF   mov   edi, [ebp+arg_8]
    .text:BF9332C2   push  eax                             ; Format
    .text:BF9332C3   call  _DbgPrint
    .text:BF9332C8   push  edi                             ; va_list
    .text:BF9332C9   lea   eax, [ebp+var_104]
    .text:BF9332CF   push  esi                             ; char *
    .text:BF9332D0   push  eax                             ; char *
    .text:BF9332D1   call  _vsprintf
    .text:BF9332D6   lea   eax, [ebp+var_104]
    .text:BF9332DC   push  eax                             ; Format
    .text:BF9332DD   call  _DbgPrint
    .text:BF9332E2   mov   ecx, [ebp+var_4]
    .text:BF9332E5   add   esp, 14h
    .text:BF9332E8   pop   edi
    .text:BF9332E9   pop   esi
    .text:BF9332EA   call  @__security_check_cookie@4      ; __security_check_cookie(x)
    .text:BF9332EF   leave
    .text:BF9332F0   retn  0Ch
    .text:BF9332F0 _EngDebugPrint@12 endp

  14. #29
    Actually, all the functions i did check when roamed w2k have the error not fixed in XP, but in vista (i.e. the debug function).

    By the way... why the hell the Win2k of Vista is compiled with a LOCAL rtl included in it, instead of accessing the ntos one!?!?!?!? It's just a waste of PC memory with no real advantages (no higher speed etc.).
    Mah, i start to understand why Vista is SO demanding in resources... if all files are compiled this way....


    mmh... I'd like give another look at win2k for curiosity [damn, i found there of good only one XP/Vista string overflow from userland, nice but not yet what I wanted], but work is calling in this period

    tx for having such bugs fixed in XPsp3 if possible ...I dream to be able to migrate to linux and not vista, in future ...but i dont bet much for it
    Last edited by Maximus; March 18th, 2008 at 15:23.
    I want to know God's thoughts ...the rest are details.
    (A. Einstein)
    --------
    ..."a shellcode is a command you do at the linux shell"...

  15. #30
    Looks like the bug probably got fixed in Windows Server 2003 SP1 and later, but not downstream.

    Exploiting this bug would also require you to bypass the stack cookie, which may not be trivial in this context. Also, pretty much the only way you can attack the system is to have a video driver that calls EngDbgPrint (pretty unlikely) with a string that you can control (very unlikely) and that can include any possible character (even more unlikely).

    Finally, the rtl you're thinking isn't the same RTL as in ntos/ntdll. Win32k has always had its own "rtl" library to deal with things such as LARGE_UNICODE_STRING and other Win32k-internal types.

    Quote Originally Posted by Maximus View Post
    Actually, all the functions i did check when roamed w2k have the error not fixed in XP, but in vista (i.e. the debug function).

    By the way... why the hell the Win2k of Vista is compiled with a LOCAL rtl included in it, instead of accessing the ntos one!?!?!?!? It's just a waste of PC memory with no real advantages (no higher speed etc.).
    Mah, i start to understand why Vista is SO demanding in resources... if all files are compiled this way....


    mmh... I'd like give another look at win2k for curiosity [damn, i found there of good only one XP/Vista string overflow from userland, nice but not yet what I wanted], but work is calling in this period

    tx for having such bugs fixed in XPsp3 if possible ...I dream to be able to migrate to linux and not vista, in future ...but i dont bet much for it
    --
    Best regards,
    Alex Ionescu

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

Bookmarks

Posting Permissions

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