Monday, 22 August 2011

More on validating input

Continuing from last nights post on securing code with coffee and sleep, I am following up with with more tips of coding that seem to be neglected by the text books.

I will get to picking on others (many others) in time, but right now I am working on and and up to errors in Chapter 4 of the same book which is:
Teach Yourself C in 21 days by SAMS.

As noted yesterday, day 4, has a type and run as they call it. You enter the code even if you do not understand all of it yet.

I have modified the code as is listed below. I have not tidied this such that printf() has been replaced and there are many other things I could do to improve this, but the point is that a simple change can make this more resilient.

Figure 1: The modified section of code.

This compiles well enough and we can see the results in figure 2.

Figure 2: Type and Run “Find_nbr.c” now accepting valid data

I do not see the code changes as too onerous. The “Type and Run” was not designed to have students understand this day, but as a prelude in any event.

Figure 3: We can handle non-numerals now and over large values!

Again, why must we teach poor coding skills and then have to relearn secure coding?

C has NO native error handling and bounds checking. You as the programmer have to tell C just what it needs to do and it will try to do what you want no matter how illogical this can be. As such, you need to defend C from bad code. You need to make sure that any input is validated first.

5 comments:

Anonymous said...

thanks for knowledge sharing. very helpful.

Anonymous said...

thanks for sharing this is very helpful.

Nam Nguyen said...

Hello Dr Wright,

Thank you for pointing out the errors in the interest of making text books better.

I do share with you the overall sentiment. At the same time, I also feel it is appropriate for book authors to intentionally skim over security details. Remember the "do one thing and do it well" philosophy? I guess book authors are trying to do just that. It is hard enough to cover appropriate language syntax and constructs. Security would be a nice to have here.

Secondly, and more importantly, Bruce Schneier [1] once said not everyone was cut into a security engineer. It is evidenced in your fix too. If there is still a buffer overflow vulnerability in a security fix by an expert like yourself, how do you suppose another regular developer can plug it all?

I could only hope book authors and university lecturers care more for security errors. And hope is as far as we can go.

[1] http://www.schneier.com/essay-211.html

Dr Craig S Wright GSE said...

Nam,
Thanks for the comment.

I know, I did not completely fix the code. It was a quick rush to point out one of the flaws in the original from the book. In time and as the posts progress I do plan of fixing more of the errors and showing how it could have been done correctly from the start.

One big issue is of course format string vulnerabilities.

In the book in question, there are several examples without a format identifier. This is simply poor coding and is not something that should be taught at any level.

What I am trying to do is to have people care more. So hope is good, but without action it does little.

You have noted that it is:
"It is hard enough to cover appropriate language syntax and constructs."
See here is an issue in itself. When an author has missed a format string identifier in the printf() functions for example, they have not taught the student the correct syntax.

Thanks, I appreciate the comment and that you took the time after reading.

Dr Craig S Wright GSE said...

Oh, and I know I have not used format identifiers in my example. :)

I know I should have, but it is a quick change from that in the text only and not a fix.