Posts Tagged ‘security holes’

Predicting the rand() and using Cryptographic Random Numbers

Tuesday, February 10th, 2009

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

Everyone must have used rand() sometime or the other while writing C code. The problem with rand() in most of the platforms is that it is easy to predict the output. Being based on unsigned int, it is just a simple function using a seed which is always the last randomly generated some number. This seed is not very tough to guess for an advanced hacker. once this seed is guessed,, any password or information based on random number generation can be easilt cracked and maligned.

following code is abridged code of rand() function implementation referenced from the book The C programming Language written by Brian Kernighan and Dennis Ritchie

unsigned long int next = 1;
int rand(void)
{
    next = next * 1103515245 + 12345;
    return (unsigned int)(next / 65536) % 32768;
}

This type of function is generally called linear congruential function. As you can notice yourself, that these type of linear congruential functions are very much predictable and are not recommended for security sensitive applications. If you look at the above given code, it is obvious that if the underlying environment does not change, then the random number generation can easily be guessed as it will generate same random number on running the application again and again.

Continue Reading the rest of the entry

© Safer Code | Predicting the rand() and using Cryptographic Random Numbers

Liked this post? Get FREE Updates
Subscribe to RSS feed

Or
Enter Your E-mail ID below

All Input is Evil

Tuesday, November 18th, 2008

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

In my previous posts, I have been emphasizing on validating Integer and String inputs by putting various checks in place. But now, I’ll suggest you to consider any type of input to your application or software as “Evil”. Consider the following two rules for any input data:

  1. All input is evil until proven otherwise.
  2. Data must be validated as it crosses the boundary between untrusted and trusted environments.

Till now, I explained how to validate Integer and String data, but today, I’ll explain what is to be validated in the input data. First things first, Look for valid data and reject everything else. You should deny all access until you are sure that the input in the request is valid. You should look for valid data and not look for invalid data for two reasons:

  1. There might be more than one valid way to represent the data.
      • For example: a word “Rose” can be represented in many ways like “ROSE”, “rose”, “R%6fse”, “RoSE” et cetera. All the mentioned words are the variations of single word “Rose” and they are valid variations. But, This can definitely be a problem for an application.
  2. You might miss an invalid data pattern.

Consider the following code: (more…)

© Safer Code | All Input is Evil

Liked this post? Get FREE Updates
Subscribe to RSS feed

Or
Enter Your E-mail ID below

About

Sunday, October 12th, 2008

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

This site is an attempt to solve a very major problem. The problem of people all around us producing code that is inefficient or ridden with security holes. The problem is created and aggravated because everything is not taught in school, and there is too much, too distributed or too vague information available on the internet.

We attempt to solve this problem by brining concepts about the issues of optimization, safety and security to you at a gradual pace that gives you time to learn, understand, ask questions and imbibe them into your daily routines. The problems and solutions would range from the very basics and trivia to the most advanced. We’d concentrate mostly on examples through C/C++ with a bit of JAVA and others interspersed here and there when needed. But we’ll not tell you how to program in C, we assume you already know, but we’ll tell you how to program efficiently and securely in C.

Amit Goel / Shantanu Goel

© Safer Code | About

Liked this post? Get FREE Updates
Subscribe to RSS feed

Or
Enter Your E-mail ID below