Buffer Overflows pt. 1

Posted on 7th May 2011 in Tutorials

From a book I’m reading called Hacking: The Art of Exploitation, I recently learned what a buffer overflow is, and how it can be used to make a program do something totally separate from what it was designed to do (such as run code that spawns, for example, a shell prompt with root privileges). A buffer overflow is the result of a character buffer in C being filled with more bytes of data than were allotted to it. C doesn’t have any measures in place to stop the programmer from accidentally (or purposefully) overflowing a character buffer, which means that if you put ten bytes (characters) into an 8-byte buffer, you’ll see the entered values actually overflowing into variables that are next to the buffer in memory. Example:

Let’s say you declare two 8-byte buffers, one after another, at the top of your main function, like this:

char buffer_one[8], buffer_two[8];

What is this line of code actually doing? It allocates memory that will be used to store two buffers. The buffers are actually located right next to each other in memory. buffer_two might be located at 0xbffff29c, and buffer_one might be located at 0xbffff2a4. The reason that the second buffer is at a lower memory address is that the stack structure in memory that contains a function’s variables grows up toward lower addresses, rather than down toward the higher ones. You’ll notice that the two example memory addresses I just gave are exactly 8 bytes apart (a4-9c), which is due to the declaration of buffer_two as one that would be used to hold up to 8 bytes of data (buffer_one is also 8-bytes long, with the allocated memory ending at 0xbffff2bb). This is fine if nothing longer than 8 bytes ever gets copied to these buffers, but in the event that it does, it will cause a buffer overflow.

Say that we used strcpy() to copy a command-line argument into the space allocated for buffer_two like this:

strcpy(buffer_two, argv[1]);

We could run the example with different values for buffer_two just by adding them at the command line. Something like

./a.out AAAAAAAAAAAAAAAAAAAAAA

where the long string of A’s is the set of characters that will be copied into buffer_two. Remember that since the second character buffer is located at a memory address lower than that of the first one, any characters beyond the eighth in buffer_two will overflow into the next memory addresses, which happen to belong to buffer_one. If, after copying the argument to the buffer, you were to print the contents of each buffer with

printf("buffer_two is at %p and contains \'%s\'\n", buffer_two, buffer_two);
printf("buffer_one is at %p and contains \'%s\'\n", buffer_one, buffer_one);

you’d see that both buffers contained some part of the argument string. buffer_two, located before buffer_one in memory, has overflowed into buffer_one. We only ever assigned the argument to the second buffer, yet part of it appears when we print the first buffer. This is the basic idea of a buffer overflow.

Check back for more in the next few days. I’m going to explain some more, including how to use a buffer overflow to divert the control flow of a program to different sections of the existing code. Thanks for reading!

Got Disassembled

Posted on 26th April 2011 in Something Daily

I’ve taken a few computer science classes now and in pretty much all of them, there has been some discussion of how memory works. Usually this means we’ve talked about function calls being used to build and shrink a stack somewhere in the nebulous area of “memory”, but that’s about the extent of what the classes I’ve taken so far have talked about. Today, though, I made a discovery on the matter as a result of working my way through my new book’s tutorial on C and assembly language. Essentially, what I learned today constituted a solidification of what I already understood in a general sense – the process by which functions cause the stack to change. Previously, I was able to explain the process in general terms (that the function is pushed onto the stack and popped off after execution), but with the help of the GNU debugger, I was able today to examine the actual memory addresses of the various pointers involved in the process. Basically, I understand it a lot better now, as I was able to see precisely the movement of data as the memory is allocated for a function call. This is a big revelation – it’s getting me more excited about assembly. If you use mac, install XCode from your original install disc, and if you use linux, sudo apt-get install gcc gdb. Do hello world in C and disassemble it with GDB – if you’ve never done this before, you’ll be amazed. So deep!

Also, I successfully created the beginning of my first working WordPress theme today by adapting my static mockup to a locally installed version of WordPress. It’s actually an incredibly easy process, as they give you all the tools you could want to use wordpress as a basic CMS. This is all fun!

Just felt like sharing a bit of my nerdiness. That was the good part of my day. I don’t feel like talking about the bad part. It wasn’t that bad, but it was bad enough for me to call it “bad”.

comments: 0 » tags: , , , , , ,

[insert name of beatles song here]

Posted on 24th April 2011 in Something Daily

Yesterday I got the first comment ever to be perpetrated on this blog that involved a positive reaction to one of my computer tutorials. It was the one where I explain how to make the keyboard backlight buttons work on Macbooks running Ubuntu. Surprisingly, someone actually followed the steps and it worked for them! Unexpected, for sure. Yet, of course, totally awesome.

I spent most of this wonderful afternoon in central park with my friend Sarah, just chatting and enjoying the very nice weather. I would have felt awful not spending at least part of today outside. I was tempted to wear shorts – that’s how warm it was, you guys. I got over my fear of sitting in the grass in new jeans, and I was reminded of the Tower of Terror by all the buildings surrounding central park. You know, they kind of look like this when you’re in the park and there are trees blocking the lower portions.

At least that’s what I think whenever I’m in the park. It reminds me of when we went there, and I rode that ride for the first and last time. Falling straight down isn’t really my thing. I like falling sideways, or forward.

I continued learning assembly, C, and as a result, memory architecture, today, and learned an interesting lesson in the process. Of course, this makes total sense, but I had to learn it firsthand. I’m following a tutorial that uses Linux and the GNU debugger to step through programs and teach assembly, and I decided to try it on Mac. I downloaded XCode and started running all of the tutorial examples, but soon found out that all of the register names are different under Mac. EIP wasn’t doing anything for me other than causing an unknown register error. So I examined the registers, and sure enough, they were all totally different from the Linux ones. I’m sure they have similar functions, but for now, I’m sticking to Linux, because that’s what the book I’m using covers, and it covers it very well. Interesting lesson, though. I also noted that the memory addresses that my Mac was displaying were twice as long as those on my Linux system, which makes a lot of sense as the Mac has 4GB of RAM and the Linux box only has 2GB. Hooray for learning.

Maybe I’ll go watch a movie tonight. Maybe I’ll just keep coding. Both are fun.

Moved into Place

Posted on 24th April 2011 in Something Daily

I’m learning a lot about assembly and C as a result of reading this book I got called “Hacking: The Art of Exploitation” from No Starch Press. And no I was not paid to plug them just now. The reason I was originally attracted to this book is probably obvious: because the idea of being able to crack computer security sounds awesome. But as it turns out, being able to stuff like that requires a huge amount of prerequisite knowledge, or so this book would have me believe. I’m learning to use the GNU C debugger and write in C, as well as look at actual assembly instructions generated by the code that I write. This is some deep stuff. Fun, but it seems impenetrable sometimes. I’m having fun anyway. Of course I’m having fun. I’m coding.

Also, my roommate moved into our new place today, so I was able for the first time to see it with some real amount of furniture in it. Surprisingly, it looks a lot bigger when it’s crammed full of stuff. But it’s awesome to actually be moving into an apartment instead of a dorm. I made a trip from my 14th street dorm down to our 9th street apartment this morning in the pouring rain carrying four bags full of various things from my room to put in the apartment, so that was interesting. I was soaking wet by the time I got there. But it was worth it.

comments: 0 » tags: , , ,

Learning New Languages

Posted on 23rd February 2011 in Something Daily

Wednesdays often end up being my busiest days in a given week. For every semester that I’ve been at NYU, they’ve always been the one day of the week that goes from start to finish without a break (I define a true “break” as one where I go back to my dorm and chill out). I’ve got a late class tonight (Electronic Music Performance), and then a friend’s birthday dinner – the combination of which is compelling me to write in the small break between the halves of my Recording Tech class. It’s been a busy two-day week so far – I’m becoming more and more addicted to the MIT OpenCourseWare Computer Science lectures, which take up a decent amount of time and brainpower. It’s sort of an accellerated version of what I’m doing in my own classes, which means that it works as a great counterpart when it’s paired with an in-person lecture and homework assignments. I’m learning a lot. Watching those is increasing my interest in gaining experience with popular algorithms and languages (I wrote binary search in Perl last weekend); this weekend I plan to write something in Python and something in Ruby, somewhere in the realm of the basic sort algorithms (bubble, selection, and merge). They’ll be interesting, and possibly a little tougher than the Perl one was, since I’m even less familiar with Ruby and Python. C++…I’ll get to that eventually. I’m honestly a little bit intimidated. Once I’ve got a few minor projects in a decent amount of other languages under my belt, then I’ll probably face the challenge. It’s a summer thing, since I’ll be taking a class in assembly language in the fall, and C++ is just one step closer to that.

I’m getting really close to the end of Chrono Trigger; after 21 hours, it’s about time. I’m done six out of the seven sidequests, many of which were pretty tough. But it appears as though I may be close to powerful enough to finish the final boss; last time I tried it, I was completely demolished, but that was before doing any of the sidequests. It’s a fantastic game – absolutely one of the best SNES games I’ve ever played. Remind me, tomorrow or later tonight (probably tomorrow) I’m going to put together a semi-definitive “Emmett Butler’s Top 40 video games” list. That’ll be great fun. And then I’ll go see My Morning Jacket for free ninety nine.

Programming Homing Missile Behavior

Posted on 15th February 2011 in Something Daily

Once again, I thought that my Tropicana stuff was going to get here today, and of course I have nothing in the mail. I did also order that Andrew WK shirt, but that was last night, and I don’t think it would have come in less than 24 hours. Still, I’m waiting for way too much stuff in the mail.

I spent a much longer time than I should have today reacquainting myself with right triangles and the unit circle as they relate to 2D game programming. I found a tutorial that shows one how to model “homing missile” type behavior, where one object moves toward the position of another. It shows how to use trig and the Pythagorean theorem to get the same result, and while reading it, I was a little embarrassed that I wasn’t totally conversant with those already. I did go through the admittedly arduous process of figuring out for myself how to make homing missile/physically “accurate” motion over the summer using the same techniques, and it took me a while to independently come to the correct solution. I thought today was going to be a lot easier, because I started with the goal of reading this guy’s C++ and translating it to Java. It was absolutely easier than the first time I tried homing behavior, but I still had to do a lot of thinking during debugging. I guess it’s just practice that will help, though.

In case you’re wondering, I came up with this upon completion:
int dx = target_x - missile_x;
int dy = target_y - missile_y;
double sep = Math.sqrt(dx * dx + dy * dy);
double scale = length / sep;
missile_x += dx * scale;
missile_y += dy * scale;

All that said, I did succeed in my goal of modeling homing missiles in Java today. In the process, I also neglected a lot of homework. Now I have to make up for this. I’m going to go write some more code for my Data Structures class and listen to some Parliament.