Safer Code – Secure Coding In C \ C++ And More..

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

Last time, we advised you to use ditch the unsafe functions like strcpy and strcat, and use their safer replacements (strlcpy, strlcat) instead. However, there is a small problem with this that you might discover that your compiler (especially gcc) does not have these functions in their implementation of the c library (libc). Why is this so? Read this thread about the original patch that was submitted to add these functions to libc. Essentially, it was rejected on the basis that these functions hide problems instead of solving them and would actually lead to hard to detect bugs that creep in because of unsolicited truncation caused by these functions. A sample implementation of strlcpy looks like this:

#include <sys/types.h>
#include <string.h>
 
/*
 * Copy src to string dst of size siz.  At most siz-1 characters
 * will be copied.  Always NUL terminates (unless siz == 0).
 * Returns strlen(src); if retval >= siz, truncation occurred.
 */
size_t
strlcpy(char *dst, const char *src, size_t siz)
{
	char *d = dst;
	const char *s = src;
	size_t n = siz;
 
	/* Copy as many bytes as will fit */
	if (n != 0) {
		while (--n != 0) {
			if ((*d++ = *s++) == '\0')
				break;
		}
	}
 
	/* Not enough room in dst, add NUL and traverse rest of src */
	if (n == 0) {
		if (siz != 0)
			*d = '\0';		/* NUL-terminate dst */
		while (*s++)
			;
	}
 
	return(s - src - 1);	/* count does not include NUL */
}

Now, there are supporters for both the sides. Solaris and BSD accepted these functions while GNU/Linux refuses to do so till date. The stand that I’d like to take here is that this is at least a step towards the right direction because a truncation bug is much better than an attacker taking over the control of your network just by pushing out a long string onto the stack. However, we could indeed augment the implementation above to communicate back to the caller somehow that truncation occurred. Whichever side you choose, be aware that these problems are very real and don’t just keep on using the older unsafe versions (Even in words of Ulrich Drepper, the opposer of strlcpy: “ The users of these functions[strcpy, strcat] should be severly punished”).

© Safer Code | Unsafe Functions In C And Their Safer Replacements: Strings Part II

Liked this post? Get FREE Updates Subscribe to RSS feed Or Enter Your E-mail ID below

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

Many times people ask me about what keyword \ type they should use to declare a generic function pointer in C, or worse still, they don’t ask and steam ahead using “void *”. Well, C does not have a generic function pointer type but it does have a generic function pointer. We’ll see why void * cannot be used to denote generic function pointers and so how we can declare them, but first a brief word on why would someone need a generic function pointer in the first place.

Why do we need Generic Function Pointers?

Well, let’s explain this with the help of a slightly advanced example of a module M1 that supplies information to a lot of other modules M2, M3, M4…Mn. M1 provides this information to modules Mn through callbacks but all these modules need different kind of information and different prototypes for their callback functions. These modules register with M1, using an API, say M1_register(Mn_callback_ptr). Now, either we could have a separate registration API for each “type/class” of subscriber Modules depending on what kind of callback they are giving, or we can have a generic function pointer, to which they typecast their actual callback to and then call the registration API. M1, on the other hand, typecasts this callback pointer to its original form while calling callbacks appropriately.

Why can’t we use void* for a Generic Function Pointer?

This is because a void* is a pointer to a generic “data” type. A void * is used to denote pointers to objects and in some systems, pointers to functions can be larger than pointers to objects. So, if you convert amongst them, you’ll lose information and hence, the situation would be undefined and implementation dependent. Most compilers won’t even warn you if you convert between them but some might error out, if you try to call such a void * to function pointer converted. But even they might fail to alert you, if you take care of typecasting the call perfectly (Enclose in parentheses before function call brackets). And then, one fine day, you’ll try to compile and run your program on one of the aforementioned systems, and then keep on wondering why your program segfaults.

Note: C++ does allow this “conditionally” which means that such a conversion is allowed but a compiler is not bound to implement this feature, which again makes its usage circumspect.

So, how exactly do we declare a Generic Function Pointer?

(more…)

© Safer Code | Generic Function Pointers In C And Void *

Liked this post? Get FREE Updates Subscribe to RSS feed Or Enter Your E-mail ID below

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

A string is a fundamental part of programs all around us. Data exchange in many forms happens in strings (e.g. user input, command line arguments, web forms, text protocols and what not.) But most programs written in C are plagued by security issues because of their usage of unsafe functions. A string is not a built-in data type in C, instead it is termed as a continguous sequence of characters terminated by a NULL character (‘\0’). Now, many of the “standard” string manipulation functions written in early part of C development took this definition by heart, assumed that a programmer always knows what he is doing (though I agree that this MUST be true), and put out a code meant to be used in an everyone-is-good world. Subsequently, the shortcomings were noticed, stronger sibling functions were created but the older ones are still supported because they are “standard”. This means that naive programmers continue to use them and put their programs’ security into jeopardy. This series will do an in-depth analysis of such unsafe functions, tell you why they are unsafe, and bring out what alternatives you have in-built and what alternatives you can create.

Our first candidate is the very famous “strcpy()”. Lets see why it is unsafe.

(more…)

© Safer Code | Unsafe Functions In C And Their Safer Replacements: Strings Part I

Liked this post? Get FREE Updates Subscribe to RSS feed Or Enter Your E-mail ID below

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

The biggest bottlenecks in making efficient code today are jumps or branches. You must have always heard of people telling you to use switch-case blocks instead of cascadin if-else’es. They were right, but partially.

This is because a cascading if-else block will check for each condition in each iteration until it reaches the correct one. On the other hand, switch-case blocks are “supposed to” (why supposed to, we’ll see just now) just execute the correct statement and move on.

Optimization Technique 1: Keep the case label values close and small (Answer to “supposed to”)

Actually switch-case statements are also many times changed into if-else cascades by the compilers. This happens when the case label values are too far apart and/or are spread over a fairly large range. If you have a small switch-case statement like below, then the compiler will generate a jump-table instead of the if-else cascade.

switch(a)
{
  case 0: /*do something*/
  case 1: /*do something*/
  case 2: /*do something*/
  case 3: /*do something*/
  default:
}

A jump table is like a “lookup table” or a “dispatch table”. You can assume that compiler creates an internal array of addresses. The array is indexed by the case lable values and the value at that index is the address of instructions corresponding to that case.

Optimization Technique 2: Place those cases first which are more likely to occur

(more…)

© Safer Code | Optimizing Switch-Case Statements In C For Speed

Liked this post? Get FREE Updates Subscribe to RSS feed Or Enter Your E-mail ID below

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

What would be the best way to start a blog that talks about building safer code? Yes, it would be to talk about the first thing you think when you start coding. The “main” function (as seen in C/C++).

We’ve been brought up with many different variations of this popular function. Some books/teachers like to write it as “int main”, some write it as “void main” and then there are some who make do with just “main”, forgoing the return type altogether. So, which one out of them is correct? Or does it even make a difference?

The answer to the 2nd question is “YES”. It makes a whole world of difference as in it could:

• do nothing
• or give you a compile time warning
• or crash the program
• or cause problems in your invocation environment

Now, we go back to the first question. Which is the correct form and why?
The answer is “int main” is the correct type for C++.
But for C, it is a bit tricky and I’d say “int main” is the recommended way.
The simple reasoning is “because the C and C++ standards say so”. (See this however, which is what is leads to a bit of confusion though and makes it implementation dependent in c)

But lets take a brief look at the practical reasons for this because you might wonder “My compiler doesn’t give me a warning for void main, so why should I care?” (If your compiler does that, then its time to switch to something else. Did I hear you are using a Microsoft compiler? ).
(more…)

© Safer Code | int main() vs void main()

Liked this post? Get FREE Updates Subscribe to RSS feed Or Enter Your E-mail ID below