Holy cow, I wrote a book!
Not every code injection bug is a security hole.
Yes, a code injection bug is a serious one indeed.
But it doesn't become a security hole until it actually
allows someone to do something they normally wouldn't be able to.
For example, suppose there's a bug where if you type
a really long file name into a particular edit control
and click "Save",
the program overflows a buffer.
With enough work, you might be able to turn this into a code
injection bug, by entering a carefully-crafted file name.
But that's not a security hole yet.
All you've found so far is a serious bug.
(Yes, it's odd that I'm underplaying a serious bug, but only because
I'm comparing it to a security hole.)
Look at what you were able to do:
You were able to get a program to execute code of your choosing.
You can already do that without having to go through all this effort.
If you wanted to execute code of your own choosing,
then you can just put it in a program and run it!
It's like saying that somebody's home windows are insecure because
a burglar could get into the house by merely unlocking and opening
the windows from the inside.
(But if the burglar has to get inside in order to unlock the windows...)
Code injection doesn't become a security hole until you have elevation
In other words, if attackers gains the ability to do something
they normally wouldn't.
If the attack vector requires setting a registry key, then
the attacker must already have obtained the ability to run enough code
to set a registry key, in which case they can just forget about
"unlocking the window from the inside" and just replace the code
that sets the registry with the full-on exploit.
The alleged attack vector is a red herring.
The burglar is already inside the house.
Or suppose you found a technique to cause an application to
log sensitive information, triggered by a setting that only administrators
Therefore, in order to "exploit" this hole, you need to gain
administrator privileges, in which case why stop at logging?
Since you have administrator privileges, you can just replace the
application with a hacked version that does whatever you want.
Of course, code injection can indeed be a security hole if it
permits elevation of privilege.
For example, if you can inject code into a program running at
a different security level, then you have the opportunity to elevate.
This is why extreme care must be taken when writing
unix root-setuid programs and Windows services:
These programs run with elevated privileges and therefore any
code injection bug becomes a fatal security hole.
A common starting point from which to evaluate elevation of privilege is
the Internet hacker.
If some hacker on the Internet can inject code onto your computer,
then they have successfully elevated their privileges, because
that hacker didn't have the ability to execute arbitrary code on your
machine prior to the exploit.
Next time, we'll look at some perhaps-unexpected places your program
can become vulnerable to an Internet attack, even if you think
your program isn't network-facing.