Lon.gs: A URL shortener in C (lon.gs)

If the database could theoretically hold it according to its schema, the program should be prepared for the largest row size that is still technically legal. (Where "prepared" may simply mean that it throws a "This should never happen" error and aborts the request.)

Here's a contrived example:

At the user creation page the malicious user wants to get admin access.

They have their username be: admin' --

They do this because they are betting on a user named 'admin'.

Their password is: alwaysSanitizeInputs

So, a user is created named "admin' --".

Now, they go in to update their password.

The DB nicely pulls out their username, "admin' --", and it says:

  UPDATE users SET password = SHA1('newPassword') WHERE username = 'admin' -- AND password = SHA1('alwaysSanitizeInputs');

Ideally a corrupt record only breaks the requests that read that record with an HTTP 500 or something similar.

A segfault only happens when you try to access a virtual memory address not mapped to your process, or try to write to a page mapped to you but not mapped as writable.

Remember, this is C. There's nothing to stop you from writing past the end of some memory like an array as long as whatever memory you're writing into still belongs to you. If you write far enough, you'll eventually walk out of your mapped memory pages and trigger a segfault, but if you don't stray toooo far, you can overwrite some important data and absolutely nothing will complain. When people say C isn't a safe language, they mean it. C will let you get away with murder.

And it turns out that there's some very important data you can overwrite this way.

> How would you get a bash shell?

Let's say there's a function foo() that writes some data to a buffer on foo's stack, and I can control what data it writes (because it's data from a text box on a webpage, let's say). And foo() is buggy and doesn't validate that in all cases the data I control fits in the bounds of the buffer it writes to.

I can then overflow the buffer with my data, and take advantage of that to overwrite the return address of foo(), because the return address for the function happens to exist past the end of all the stack local memory for the function. When foo() returns, it will jump to the address I wrote in there, instead of where it was supposed to go back to. And as long as that address is in the process's mapped memory pages, again, nothing will complain.

To get a shell, as part of the overflow I either insert the binary data corresponding to the x86 instructions for something like a call to execve("/bin/sh", ...) and then have foo()'s return jump to the beginning of my instructions, or I cause the return to jump to some other code or library that will do that for me that happens to already be in place (there are more sophisticated versions of this exploit called Return Oriented Programming).

If want to read up on this: https://www.win.tue.nl/~aeb/linux/hh/hh-10.html