CS591 ST 008

I've spent a few hours trying to find the magic address value for i[129].

After emailing with Jed, I've looked at the dump file and tried to relate it to the server2.c file. I'm just not too sure how to read this dump file. I'm looking for an address where the size value would be pushed onto the stack.

I'm done guessing. I"ve tried just about every address that I could possibly think would be a location for the stringLength variable being passed into the Capitalize function as the last parameter. I believe once I find the location of the stack for this function call, I would then need to add 8*511 to that address to represent offset location of the last char position in the array of data..?

I'll take my 0.
This is foo-bar'ed...I haven't even started to look at the new test...uggg.

Here is what I have:
the root jail break order-
strcat(myexploit, nopsled);
strcat(myexploit, mkdir);
strcat(myexploit, chroota);
strcat(myexploit, setuidzero);
strcat(myexploit, chdirloop);
strcat(myexploit, chrootdotdot);
strcat(myexploit, doexecve);

the i[129] value:
i[129] = 0x080487d0; //note, i've tried so many values from the dump file

the magic number for the printf:
//should be JMP ESP ..... 0xff 0xe4
printf("58623\n"); //little endian, so 0xe4 0xff

Seattle, WA - Pictures..

Spent most of the day today at the Pike's Market (Farmer's Market). This is in downtown Seattle right along the water edge. Mostly food items for sale such as seafood, vegtables and fruits. But also you can find other trinket items.

Here is a picture of the front area of the Farmer's Market.













Here is a nice view outside to the water side. I walked out thru a door and said "WOW", I gotta take a picture.


















This picture is in front of the Art Museum. This statue's hammer arm goes up and down. I think they call him "Hammer Man". I just thought it was cool to see.

Seattle, WA after work...

I went to downtown Seattle last night and really didn't get to see much. I thought it would be fun to go back during the daytime...well, at least after work. Booyaa, I hit traffic; no big deal (I'm from Houston biatches).

Pictures are from my camera phone, so quality is not the best. The Space Needle in daylight and a stadium (QWest Field) somewhere in downtown. I think I'm going to have to visit the Pike's Market this weekend ("fish tossing").

Redmond, WA

I arrived in Seattle,Wa yesterday after a 3 hour flight. I was lucky enough to have my company send me out to Redmond to work with my team in person. I have been working on this team for about 5 months and never seen them in person. It is nice to put a face to those voices.

Our work site is surrounded by the Microosft campus. Actually, I have been told that they will take over the remainder of the buildings in the near future.

It is Saint Patrick's day and my co-workers didn't seem to want to go out. I'm still a bit under the weather anyway; who knows..I might find a pub anyway.

Oh, did I forget to mention, this area is full of old white people. I feel like an ambassador for the South ;-)

Redmond, WA

I arrived in Seattle,Wa yesterday after a 3 hour flight. I was lucky enough to have my company send me out to Redmond to work with my team in person. I have been working on this team for about 5 months a never seen them in person. It is nice to put a face to those voices.

Our work site is surrounded by the Microsft campus. Actually, I have been told that they will take over the remainder of the buildings in the near future.

It is Saint Patrick's day and my co-workers didn't seem to want to go out. I'm still a bit under the weather anyway; who knows..I mi

CS591 ST 008

Lab 2 (due 3/11/09)

Ok, this is what I have done so far with lab2.

1) downloaded all files for lab2
2) combed thru lab2exploit.c program
3) combed thru server2.c program
4) updatd lab2exploit.c with new order of assembly commands
5) guessed a number to use for the string size which is larger than 32768 and less than 65536
6) ssh to shasta and passwd
7) ssh to Aleph and passwd (noticed I don't have a user space for diabloo)
8) on Aleph, played with: >% nc 10.0.0.2 8084

Some issues I have had up to this point are:
1) shasta and Aleph have been down almost every time I've tried to log onto them.
2) I'm not sure what the magic number should be. I know the concept of the exploit and the number being too large will be seen as a negative number with a short int variable and thus passes the if validation. Then when the buffer is filled it will be filled passed capacity, upto the return address for when the function finishes its operation. I'm just not sure what value to use to reach this area, and when reached, should this area be filled with another address where the actual asm code is located or should the asm code occupy this area (where the RA is located)?

CS591 ST 008

Lab 1.5 (due 3/4/09)

After reading Aleph One's paper "Smashing The Stack For Fun And Profit", it seems that the buffer overflow problem can teach us much about exploits in general.

Looking at The Basic Principles of Information Protection by Saltzer and Schroeder, one design principle in particular sticks out: Economy of Mechanism. This single rule seems to play a reverse role in exploits such as Buffer Overflows. High level languages such as C, have been designed to make programming easier for the user. Libraries with functions such as strcpy() were designed to make certain tasks as easy as possible (less complication), not knowing that this will actually cause more problems than it solves.

The lessons from Saltzer and Schroeder isn't that it is good enough to implement a few of these principles but all are very important. Yes, it is important to make your implementation as least complicated as possible but it must be cognizant of underlining issues.

So how does this lesson apply to other or all/most exploits. Most exploits are played off of the idea that something is being done that was not protected against and probably never thought about. I really liked the "Puzzle for February 15, 2006" about how General William T. Sherman used the act of surprise to fight his foes. With program vulnerability, the same follows true. Programs must be written to expect the unexpected. It is never possible to make a 100% full proof program, especially as the complexity and size grows, but it should be possible to ensure the Basic Principles are being implemented to the best of the programmer's abilities.

In my own personal opinion/experience, these principles should be part of every programmer's check list or programming standards. Coding tools (ie. valgrind) should be used to automatically check for the obvious errors (eg. strcpy() vs strncpy()) and other deprecated interfaces. Sometimes, a programmer needs the experience to be able to prevent exploits in his/er code. It is often the case that this experience is not available in a team and code is written without detail knowledge of what is really happening (eg. race conditions, dead locks, etc..).

It makes me cringe when I think about defects from a peer review I have performed were rejected, with the response "...it will just take too long..". This seems to be the attitude and direction many large companies instill in their workers...at least until they get audited...? (stepping down from soap box)