PoC or GTFO, Volume 2

Home > Other > PoC or GTFO, Volume 2 > Page 32
PoC or GTFO, Volume 2 Page 32

by Manul Laphroaig


  >++++++++++>+>+[[+++++[>++++++++

  <-]>.<++++++[>--------<-]+<<<]>.

  >>[[-]<[>+<-]>>[<<+>+>-]<[>+<-[>

  +<-[>+<-[>+<-[>+<-[>+<-[>+<-[>+<

  -[>+<-[>[-]>+>+<<<-[>+<-]]]]]]]]

  ]]]+>>>]<<<]

  Progress! Now we add lines to accommodate input and output, although these will be left empty for now:

  _i :

  _o :

  To perform output, our program will need to convert the numeric memory cells to ASCII values. This can easily be done by adding an ASCII lookup table to our program:

  _a :

  ... __65 A__66 B__67 C__68 D ... _127 ._uuu.

  The arrangement of underscores and spaces will assist us in navigating the table with vim commands. Providing an “unknown” uuu allows us to process values outside the ASCII range.

  Now for the fun part—how do we execute our BF program using just our simple vim commands? We would envision a small set of commands running continuously to interpret the program. Of course, we could manually type out these commands ourselves, over and over, to perform the execution (and we indeed encourage this as an enjoyable exercise!), but in the unfortunate situation in which an interpreted program fails to halt, we may come to find this process laborious. Instead, we will insert the keys for these commands directly into our vim file. When complete, we can automatically run the commands on the first line of the file by typing:

  ggyy@"

  If the first line, in turn, moves to other lines, and repeats this process of yanking a line of commands (yy) and executing the yanked buffer (@"), execution can continue indefinitely, without any additional user action.

  So to begin, let us simplify the process of navigating the text file by setting marks at key points. At the start of our text file, we add commands to set a mark at the beginning of the file.

  ggOmh

  A mark at the memory tape:

  /_t^Mnjmt ‘h

  A mark at the BF code:

  /_p^Mnjmp ‘h

  A mark at the input, output, and ASCII table:

  /_o^Mnjmo ‘h/_i^Mnjmi ‘h/_a^Mnjma ‘h

  Although these steps are not strictly necessary, they will simplify navigating the file for future commands.

  Now for execution! BF contains 8 instructions: increment the current data cell (+), decrement the current data cell (-), move to the next data cell (>), move to the previous data cell (<), a conditional jump forward ([), a conditional jump backward (]), output the current data cell (.), and input to the current data cell (,). Let us construct a table of vim commands to carry out each of these operations; each label will act as a marker for looking up the corresponding commands.

  _c:

  _>-???X

  _<-???X

  _[-???X

  _]-???X

  _+-???X

  _--???X

  _.-???X

  _,-???X

  _f:_???X

  _b:_???X

  We again apply the trick of special characters around each operation to simplify the search process—we may find many >’s in our file, but there will be only one _>-. We mark the end of the command with an X. We preemptively supply additional _f and _b commands, to carry out the conditional part of the BF branch operations [ and ]. We will determine the exact commands for each momentarily, which will replace the unknown ??? above. For now, let us continue the previous process of adding marks to each for quick navigation.

  /_c^Mnjma ‘h/_c^Mnf_mf ‘h/_b^Mnf_mb

  Now that our marks are set, we add to the top of our file the commands to execute the first instruction in the BF program.

  ‘pyl ‘c/_V^R"^Mf-ly2tX@"

  This will move to the BF program (‘p), yank one BF instruction (yl), move to the command table (‘c), find the BF instruction in the table, (/_V^R"^M) move to the list of commands for that instruction (f-l), yank the list of commands (y2tX)—skipping an X embedded in the command, and seeking forward to the terminating X—and execute the yanked commands (@"). With this, our execution begins!

  Let’s now complete our table by determining the commands to execute each BF instruction. > and < are particularly simple. For >,

  ‘twmt ‘p mpyl ‘c/_V^R"^Mf-ly2tX@"

  Plainly, this is: move to the memory tape (‘t), move forward one memory cell (w), mark the new location in the tape (mt), move back to the BF program (‘p), move forward one character to progress over the now executed BF instruction ( ), mark the new location in the BF program (mp), yank the next BF instruction (yl), and follow the previous process (‘c/_V^R"^Mf-ly2tX@") to locate that instruction in the command table, yank its commands, and execute them.

  <, then, is similarly implemented as

  ‘tbmt ‘p mpyl ‘c/_V^R"^Mf-ly2tX@"

  What of + and -? + can be performed with

  ‘t^A ‘p mpyl ‘c/_V^R"^Mf-ly2tX@"

  This is virtually identical to the < and > implementation. This time, we move to the current data cell and increment it with ^ A. Strictly speaking, this is a violation of the copy/paste/search/replace type execution we have been using. However, with minimal effort, the increment could be performed via a lookup table (as we do for the ASCII conversion)—we simply elide this for brevity.

  Simply replacing ^ A (increment) with ^ X (decrement), - is derived.

  ‘t^X ‘p mpyl ‘c/_V^R"^Mf-ly2tX@"

  Now, certainly, our interpreter is not useful without input and output, so let us add . and , commands. . may be

  ‘tyw ‘a/_(^R"|uuu)^Mellyl ‘op$mo ‘p mpyl ‘c/_V^R"^Mf-ly2tX@"

  This of course is: move to the memory tape (‘t), yank a cell (yw), move to the ASCII table (‘a), search for the yanked cell or, if it is not found, move to the uuu marker, (/_(^R"|uuu)^M), move over the marker characters (ell), yank the corresponding ASCII character (yl), move to the output (‘o), paste the ASCII character (p), move to the end of the output ($), mark the new output location (mo), and finally, move back to the BF program, move over the executed instruction, grab the next instruction, locate its commands, and execute them, as before.

  (‘p mpyl ‘c/_V^R"^Mf-ly2tX@")

  Data input with , is similarly:

  ‘iy mi ‘a/^R"_^MT_ye ‘txt p ‘p mpyl ‘c/_V^R"^Mf-ly2tX@"

  Which simply performs the reverse lookup and stores the result in the current memory cell.

  We are close, but, alas!, nothing is ever simple, and BF’s conditional looping becomes more complicated. The BF [ instruction means, precisely, “if the byte at the data pointer is zero, then instead of moving the instruction pointer forward to the next command, jump it forward to the command after the matching ] command.”

  ‘tyt ‘f/(^R"|n)x^Mf-ly2tX@"

  Meaning, navigate to the memory tape (‘t), yank a memory cell (yt ), navigate to the forward assist commands (‘f), search for either the yanked cell, or, if it is not found, the character n, followed by x (/(^R"|n)x^M), and yank and execute the given commands, using the process as before (f-ly2tX@"). This search allows us to achieve the conditional portion of the [ instruction—we will include a marker for only 0, so only a memory cell of 0 will find a match—all others will be directed to the n character. Our forward assist then appears as

  _f:_0x:-‘p% mpyl ‘c/_V^R"^Mf-ly2tX@"X_nx:-‘p mpyl ‘c/_V^R"^Mf

  ly2tX@"X

  If the memory cell is 0, the previous search matches _0x, and the commands following it are yanked and executed. If the memory cell is not 0, the previous search matches _nx, and the commands following it instead are yanked and executed. For 0, we have: go to the BF program (‘p), navigate to the corresponding ] instruction (%), move to the instruction after this ( ), mark the new location in the program (mp), and then yank and execute the next instruction, as before. (yl‘c/_V^R"^Mf-ly2tX@") For non-0, we have: go to the BF program (‘p), navigate to the next instruction ( ), mark the new location in the program (mp), and then yank and execute the next instruction, as before. (yl‘c/_V^R"^Mf-ly2tX@")

  ] is now straightforward.
Following the same patterns, we have

  ‘tyt ‘b/(^R"|n)x^Mf-ly2tX@"

  for the conditional search, and

  _b: _0x:-‘p mpyl ‘c/_V^R"^Mf-ly2tX@"X_nx:-‘p% mpyl ‘c/_V^R"^Mf-

  ly2tX@"X

  as the backward assist commands. An ardent observer may argue the vim % command violates our copy/paste/search/replace design, and, alas!, this is so. However, we argue that a series of searches, increments, and decrements—like those we have already shown—could be used to implement %’s functionality in a more perfect manner. We leave this as an exercise for purists.

  But lo! With the implementation of the eight BF instructions, our execution engine is complete! Page 586 shows a cleanly formatted version of the final machine. The demonstration machine uses our copy/paste/search/replace commands to calculate the prime numbers up to 100. For ease of use, we add an introductory %0s search and replace sequence—momentarily allowing ourselves to enter ex commands—in order to insert the control characters (^ M, ^ R, etc.) needed throughout the rest of the machine. This provides us a pure-ASCII file, without the need to enter special characters. Simply copy the text, paste into vanilla vim, launch with gg2yy@", and witness the awesome Turing-complete power of our benevolent editor!53

  12:10 Doing Right by Neighbor O’Hara

  by Andreas Bogk

  Knight in the Grand Recursive Order of the Knights of the Lambda Calculus Priest in the House of the Apostles of Eris

  What good is a pulpit that can’t be occasionally shared with a neighborly itinerant preacher? In this fine sermon, Sir Andreas warns us of the heresy that “input sanitation” will somehow protect you from injection attacks, no matter what comes next for the inputs you’ve “sanitized”—and vouchsafes the true prophecy of parsing and unparsing working together, keeping your inputs and outputs valid, both coming and going. —PML

  Brothers, Sisters, and Variations Thereupon!

  Let me introduce you to a good neighbor. Her name is O’Hara and she was born on January 1st in the year 1970 in Dublin. She’s made quite an impressive career, and now lives in a nice house in Scunthorpe, UK, working remotely for AT&T.

  I ask you, neighbors: would you deny our neighbor O’Hara in the name of SQL injection prevention? Or would you deny her date of birth, just because you happen to represent it as zero in your verification routine? Would you deny her place of work, as abominable as it might be? Or would you even deny her place of living, just because it contains a sequence of letters some might find offensive?

  You say no, and of course you’d say no! As her name and date of birth and employer and place of residence, they are all valid inputs. And thou shalt not reject any valid input; that truly would not be neighborly!

  But wasn’t input filtering a.k.a. “sanitization” the right thing to do? Don’t characters like ’ and & wreak unholy havoc upon your backend SQL interpreter or your XHTML generator?

  So where did we go wrong by the neighbor O’Hara?

  There is a false prophesy making the rounds that you can protect against undesirable injection into your system by input sanitization, no matter where your sanitized inputs go from there, and no matter how they then get interpreted or rendered. This “sanitization” is а heathen fetish, neighbors, and the whole thing is dangerous foolery that we need to drive out of the temple of proper input-handling.

  Indeed, is the apostrophe character so inherently dirty and evil, that we need to “sanitize” them out? Why, then, are we using this evil character at all? Is the number 0 evil and unclean, no matter what, despite historians of mathematics raving about its invention? Are certain sounds unspeakable, regardless of where and when one may speak them?

  No, no, and no—for all bytes are created equal, and their interpretation depends solely on the context they are interpreted in. As any miracle cure, this snake oil of sanitization claims a grain of truth, but entirely misses its point. No byte is inherently dirty so as to be sanitized as such—but context and interpretation happeneth to them all, and unless you know what these context and the interpretations are, your sanitization is useless, nay, harmful and unneighborly to O’Hara.

  The point is, neighbors, that at the input time you cannot possibly know the context of the output. Your input sanitation scheme might work to protect your backend for now—and then a developer comes and adds an LDAP backend, and another comes and inserts data into a JavaScript literal in your web page template. Then another comes and adds an additional output encoding layer for your input—and what looked safe to you at the outset crumbles to dust.

  The ancient prophets of LISP knew that, for they fully specified both what their machine read, and what it printed, in the holy REPL, the Read-Eval-Print Loop. The P is just as important as the R or even the E—for without it everything falls to the ground in the messy heaps that bring about XSS, memory corruption, and packet-in-packet. Pretty-printing may sound quaint, a matter unnecessary for “real programmers,” but it is in fact deep and subtle—it is unparsing, which produces the representation of parsed data suitable for the next context it is consumed in. They knew to specify it precisely, and so should you.

  So what does the true prophecy look like? Verily sanitize your input—to the validity expectations you have of it. Yet be clear what this really means, and treat the output with as much care as you treat the input. The output is a language too, and must be produced according to its own grammar, just as validating to the input grammar is the only hope of keeping your handler from pwnage.

  Sanity in input is important in structured data. When you expect XML, you shall verify it is XML. When you expect XML with a Schema, also verify the schema. Expecting JSON? Make sure you got handed valid JSON. Use a parser with the appropriate power, as LangSec commands. Yet, if your program were to produce even a single byte of output, ask—what is the context of that output? What is the expected grammar? Verily, you cannot know it from just the input specification.

  Any string of characters is likely to be a valid name. There is nothing you should really do for sanitation, except making sure the character encoding is valid. If your neighbor is called O’Hara, or Tørsby, or Åke, make sure you can handle this input—but also make sure you have the output covered!

  This is the true meaning of the words of prophets: input validation, however useful, cannot not prevent injection attacks, the same way washing your hands will not prevent breaking your leg. Your output is a language too, and unless you generate it in full understanding of what it is—that is, unparse your data to the proper specification of whatever code consumes it—that code is pwned.

  Parsing and unparsing are like unto the two wings of the dove. Neglect one, and you will not get you an olive branch of safety—nay, it will never even leave your ark, but will flap uselessly about. Do not hobble it, neighbors, but let it fly true—doing right by neighbors like O’Hara both coming and going!

  EOL, EOF, and EOT!

  12:11 Are All Androids Polyglots or Only C-3PO?

  by Philippe Teuwen

  $ pm install/sdcard/pocorgtfol2.pdf

  That’s all it takes to install this polyglot as an Android application. So what’s the Jedi mind trick?

  Basically, we merged the content of an Android application with the ZIP feelies. (Please excuse the cruft you’ll find in the feelies!)

  Now I won’t teach you anything if I tell you that an APK is just a ZIP. It is, of course, a ZIP, but not just, if we also want it to be an Android app; we need the application itself, for one thing, and then some.

  The Android OS requires all applications to be signed in order to be installed, so our polyglot needs to be signed by our Pastor, which is actually not a bad practice. Beyond this, Android doesn’t really care about what else the ZIP could be (e.g., it can be a PDF, as is the glorious PoC‖GTFO tradition), but the trick is that all of the archive contents must be signed. In particular, this must include all the original feelies, as you can observe in META-INF/MANIFEST.MF.

  The resulting polyglo
t can be installed directly if dropped on /sdcard/, as well as locally, by using the Android Package Manager as shown above.

  But I expect most readers—well, only those crazy enough to give execute permission to the Pastor on their terminals—to install it via the Android Debug Bridge tool adb. This method expects the application package filename to end in .apk, so let’s humor it.

  $ ln -s pocorgtfo12.pdf pocorgtfo12.apk

  $ adb install pocorgtfo12.apk

  But what does this application do? Not much, really. It copies itself (the installed APK) to /sdcard/pocorgtfo12.pdf and opens this copy with your preferred PDF reader.

  Note: Imperial security is improving and on the latest versions of the OS, even if this ’droid polyglot gets installed, it may fail in dex2oat. You may need to develop your own Jedi tricks to tell them these are not the droids they are looking for—and if you do, please send them to us!54

  And you, my friend, are you a polyglot? Let’s celebrate this fine Québécoise release with a classic charade!

  Charade des temps modernes

  Mon premier est le nombre de Messier de la Galaxie d’Andromède.

  Mon second est la somme de quatre nombres premiers consécutifs commençant par 41.

  Mon troisième est le nombre atomique de l’Unennquadium.

  Mon quatrième est le nombre modèle qui succéda au Sinclair ZX80.

  Mon tout lève tous les obstacles sur le chemin de la Science.

  13 Stones from the Ivory Tower, Only as Ballast

  13:1 Listen up you yokels!

  Neighbors, please join me in reading this fourteenth release of the International Journal of Proof of Concept or Get the Fuck Out, a friendly little collection of articles for ladies and gentlemen of distinguished ability and taste in the field of reverse engineering and worshippers of weird machines. This fourteenth release is given on paper to the fine neighbors of São Paulo, San Diego, and Budapest.

 

‹ Prev