What’s the connection between Microsoft, Intel and AMD?
The answer is that they are all trying to control code execution, such as the type done by exploiting a buffer overflow or a format string vulnerability.
While I do not think that this should be implemented in the OS, it might have been a good idea to implement it on the CPU level.
But there is another way to solve most of the buffer overflows from happening without involving any hardware or operating system in the middle.
The most common problem that causes buffer overflow related problems, is the use of a specific programming language and specific syntax.
That is, most problems in the security world today still happen because someone was “smart” enough to use the C programming language to do something that resulted in a security risk or just a simple bug.
Sure this is the “standard” today, but it does not mean that it’s a good standard.
I keep saying that the use of C is problematic for many years now, and in return I hear many nice explanation why it is not a good idea to stop using the language.
Sure it is the most widely used language out there, and it became a standard, but the language and language structure (syntax) is so bad, that we see on a daily basis new languages that try to fix it without any real success.
Lets see few problems with the C language (and Syntax):
What do you think about the following code ?
if (1== number)
{
printf (“And the winner is: %s”, winner);
}
Here we use 1== number because if we used number==1 and forget one “=”, we will place a value into the variable number, and therefor we will have a bug, and maybe a security risk (off by x, limit check, etc..).
Here is another common code in C:
char dest [10];
char src [12]
strcpy (dest, src);
And we have a buffer overflow on our hands !
But these two problems are very easy to solve (for expert developers).
So how about some real problematic code, that even expert developers may not notice that it happens, and most of you never thought it is possible to do:
memcpy (src ,(*)letsExecuteOurBufferContent, size);
Do you know what this code does ? Other then using memcpy in a wrong manner, it just opened a back door on a machine that used this code. Yup, all I need to do in C to make it a security risk is to use two variables, and one function!
Yes I know that it is possible to do it in other languages as well, but in C this type of code is so common, that many experts will look at it and still will not see the problem in front of their eyes, while on other languages, it might cause a big red light bulb to glow even by the average developer, even if the vulnerability itself is not noticed.
The problems with C are so bad, that even when it is used to compile an interpretor for other languages (and most of the interpreters out there have been written in C/C++) it may create bugs on the byte code/compiled result of what the user have created.
Just take a look at Perl as one of many examples:
http://www.securiteam.com/unixfocus/5QP0I15EUK.html
http://www.securiteam.com/securityreviews/6D0042AEUQ.html
Or what about issues with the Java Virtual Machine ? We can even create a Java code that will cause our VM to execute arbitrary code just because it was written in C:
http://www.securiteam.com/windowsntfocus/5DP0G0K8BI.html
http://www.securiteam.com/windowsntfocus/5RP0L0U8AS.html
http://www.securiteam.com/securitynews/5LP0L0U2AQ.html
http://www.securiteam.com/exploits/6L00S2A8KC.html
http://www.securiteam.com/windowsntfocus/5LP0P0K8AI.html
And still we didn’t even scratch the surface of the problem.
Many times there is a code that you need to write in C that look so bad that even using AT&T/INTEL based assembler syntax looks so much clearer and easier to use all of the sudden.
Many times you need to find yourself writing so much code just because you used C/C++, and when you start writing too much code, you start having bugs (the urban legend claims that on every line of code there is at least one bug waiting to surface!)
And many other times “ANSI C” is not portable at all between compilers, so we can experience a lot of problems from data swapping between parameters (thats a security risk BTW!), continuing between code that is unable to be compiled (the best thing we can expect from such problem), DoS condition, or other missbehavior of the program.
And if the above isn’t bad enough, many C/C++ programs out there arrive with some debug information inside, because there are bugs the programmer was unable to locate without a debugger, but to use a debugger you need debug information, but then you find out that things are acting a bit different on the version without the debug information, so you ship the version with the debug information.
So with all of the above problems, and with almost all of the programs and OS’s out there using C, how can you sleep well at night ?!
So lets stay away from C and find better language. TY.