Earthquake Retrofit's Journal: Buffer overflows explored

As a beginning assembly language programmer, I've been having trouble getting my head around buffer overflows as a security vulnerability. The popular media has many lurid stories containing few details and the detailed descriptions often mean nothing to me. So I decided to design a purposefully insecure program as a thought experiment.

I make a web page with a box labeled "Type your 16 charecter password to get the file." When the user presses ENTER whatever he typed is sent to my program without any check for the proper length. I have read that any client-side bounds checking could be disabled. Hole number one. I would leave the check in anyway.

A 16 byte variable will hold the user's password and is defined in memory and initilized to -1 just before the beginning of the code for the first procedure. So anything written starting at that address that's longer that 16 bytes overwrites what comes after in the program. Hole number two? But this is crazy, variables are defined all over the place.

Now, the first procedure displays the file. Let's say that routine is 100 bytes long. The second procedure checks for a valid password and returns zero in a register if the password is valid, unchanged if not.

A third procedure, trusting the client-side checking, if there was any, blindly writes whatever it gets from the user to memory starting at the address of the password variable, so anything bigger than 16 bytes begins to overwrite the code that follows. Overflow. Hole number three.

So if an attacker types in any 16 characters and then the exact 100 bytes of the hex code of the first procedure, which can't be changed if the attacker wants the file, then replaces the guts of the second procedure, which checks the password, with hex code that only has to set the register to zero and return from the procedure. Exploit! As long as the modified code is running, any subsequent user will also have access to the file as long as their password is 16 charecters or less.

But an attacker would have to know the exact 100 bytes of the first procedure to get the file. Get it wrong, and the program crashes or behaves unpredictably which I have no idea how to exploit. But it is a denial of service. Get it right and subsequent users could also easily crash it. But unless I publish the source or executable code how would anyone know? It's only running on my machine. Security by obscurity?

This does seem to meet the description 'allows attacker to execute arbritary code.' If the attacker isn't interested in the file, he or she could inject code to take over my box IF the running program has administrator privileges. That would be hole number 4.

All of these holes, except maybe number one and two, seem to be easily prevented, so why do buffer overflows occur so often? This all seems obvious to me as a beginner, but there's a lot I don't know yet. For instance, 19,000 windows APIs.

Steve