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

Except for few good C programmers, others generally tend to ignore variable initialization or I should rather say “proper variable initialization”. Generally seen, the variable declaration itself is not done with a good thinking. Improper local variable initialization might not be good for the working of the program but improper global variable initialization might get your software or system hacked.

The uninitialized variable or a wrongly initialized variable might lead a program to change its normal course of flow from the intended one. For example: If a variable “index” is being used for array navigation and is left uninitialized, it might contain a garbage value which can lead to array index out of bounds error. or if the variable “index” is initialized wrongly to –1, it might lead to serious flaw in code flow. Even if an integer value is being initialized to ‘0’, it might lead to a security check bypass because for some programs, even a ‘0’ is considered a valid value.

Lets take an example of a code piece.

 int isMachineRunning = GetMachineStatus();
 int state = GetUserState(isMachineRunning);
 int userid = 0;
 if (state) {
	userid = ExtractUserID(state);
 }
/* do stuff */
if (uid == 0) {
	DoAdminThings();
}

Now, in the above example, userId is initialized to ‘0′. and adminUserID is also equal to ‘0′. Consider that the GetUserState() function somehow failed to get the state of user then, the If condition check might fail resulting in failure to obtain a valid user id. This, In turn, will still lead to admin access as we have wrongly initialized the userid variable to ‘0′ which is equal to admin user id. Let’s consider another example:

char str[20];
strcat(str, "hello world");
printf("%s", str);

This might seem innocent enough, but str was not initialized, so it contains random memory. As a result, str[0] might not contain the null terminator, so the copy might start at an offset other than 0. The consequences can vary, depending on the underlying memory. If a null terminator is found before str[8], then some bytes of random garbage will be printed before the “hello world” string. The memory might contain sensitive information from previous uses, such as a password stored in a buffer. In this example, it might not be a big deal, but consider what could happen if large amounts of memory are printed out before the null terminator is found. If a null terminator isn’t found before str[8], then a buffer overflow could occur, since strcat will first look for the null terminator, then copy 12 bytes starting with that location. Alternately, a buffer over-read might occur if a null terminator isn’t found before the end of the memory segment is reached, leading to a segmentation fault and crash. I hope that the above mentioned examples are goos enough to emphasize on the correct initialization of variables and yes, that each and every needs to be initialized.

The four mandatory steps to follow for correct variable declaration is :

1. Explicitly initialize all variable or data stores with the correct and expected values either at the first usage or during declaration as a must rule.
2. Properly do input validation to make sure that the variable usage in the first statement itself is initialized to expected value.
3. Avoid race conditions during initialization routine.
4. Definitely run some static analysis tool on your code to make sure that it raises all sorts of warnings or errors to warn you before you publish your code.

Once you follow the above mentioned checklist, I am sure that you’ll face least of problems or issues with variable initializations.

© Safer Code | Improper Variable Initialization

Related posts

• And So It Begins… (0)
• “De-Bugging” Code before Check-in (0)
• Validating Untrusted Integer Inputs (6)
• Predicting the rand() and using Cryptographic Random Numbers (7)
• Validating Untrusted String Inputs (1)

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

Alright!!! Let’s get started. This is one of many subjects which always overwhelms me. Why so? Ofcourse, the reasons can not be explained here but then, the reason should be the least of your worries.

Okay, if you know enough about this, then please post your knowledge tips as comments because your comments might help towards my unexplained reasons.

You may find similar information on other websites but then, it’s a wild world and I am not intending to infringe any copyrights.

Now to begin with, let’s first understand how to evaluate the performance of java code and protect the java code from tainted objects. We’ve already talked about Tainted Object Propagation in my previous post in context with databases. now, it is in context with application code.

I’ll explain this with an example of enum pattern.

We can have enums in Java in two ways.
1) Either we have “public static final” constants declared.

public class UsingConstants {  
    public static final int CONST_1 = 1234 ;
    public static final int CONST_2 = 1 ;
    public static final int CONST_3 = 1 ;
    private int value ;
    private UsingConstants(int param) {
       value = param ;
    }
 }

2) Implement the enum pattern.

public class UsingEnumPattern {
    public static final UsingEnumPattern CONST_1 = new UsingEnumPattern(1234) ;
    public static final UsingEnumPattern CONST_2 = new UsingEnumPattern(1) ;
    public static final UsingEnumPattern CONST_3 = new UsingEnumPattern(1) ;
    private int value ;
    private UsingEnumPattern(int param) {
       value = param ;
    }
    public static int getValue()
    {
       return value;
    }
}

To evaluate the performance and understand the details of these two different implementations, have a look at the user code given below:

public class UserCode {  
    public void initializeSomethingUsingConstants(int param) {
       int i = param;
    }
    public void initializeSomethingUsingEnumPattern(UsingEnumPattern param) {
        UsingEnumPattern i = UsingEnumPattern.CONST_1;
        int i = UsingEnumPattern.getValue();
    }
    public void callMethods(){  
        initializeSomethingUsingConstants(1111); // I can pass any integer here
        initializeSomethingUsingEnumPattern(UsingEnumPattern.CONST_1) // only defined enums can be passed.
    }
}

Now, We’ll deduce the following two things from this example:

a) The first example, UsingConstants, has defnitely got faster execution time as it has got only few bytecode instructions to execute.

    0:   aload_0
    1:   invokespecial   #16; //Method java/lang/Object."<init>":()V
    4:   aload_0
    5:   iload_1
    6:   putfield        #19; //Field value:I
       9:   return

where as the second example, UsingEnumPattern has about 16 instructions to execute. 16 to create statics and 6 for initialization.

    static {};
      0:   new     #1; //class com/nds/epg/network/IPConfigErrorCodeA
      3:   dup
      4:   sipush  1234
      7:   invokespecial   #14; //Method "<init>":(I)V
      10:  putstatic       #18; //Field CONST_1:LUsingEnumPattern;
      13:  new     #1; //class UsingEnumPattern
      16:  dup
      17:  iconst_1
      18:  invokespecial   #14; //Method "<init>":(I)V
      21:  putstatic       #20; //Field CONST_2:LUsingEnumPattern;
      24:  new     #1; //class UsingEnumPattern
      27:  dup
      28:  iconst_1
      29:  invokespecial   #14; //Method "<init>":(I)V
      32:  putstatic       #22; //Field CONST_3:LUsingEnumPattern;
      35:  return
 
      0:   aload_0
      1:   invokespecial   #26; //Method java/lang/Object."<init>":()V
      4:   aload_0
      5:   iload_1
      6:   putfield        #28; //Field value:I
      9:   return

and as per user code, constant evaluation will bve faster as it will using the ’sipush’ instruction as compared to ‘getstatic’ instruction in case of enum pattern.

   /*
   public void initializeSomethingUsingConstants();
      0:   sipush  1234
      3:   istore_1
      4:   return
 
   public void initializeSomethingUsingEnumPattern();
      0:   getstatic       #18; //Field UsingEnumPattern.CONST_1:LUsingEnumPattern;
      3:   astore_1
      4:   return
*/

So, to summarize, if you are very much worried just about performance then definitely, using constants makes it a perfect sense.

b) Now, lets look at the problem of using constants. get a bit paranoid and think that people are just waiting to break your code. it is easily possible as while using constants, any integer value can be passed to the user method instead of the constant values, which is enough to break your code. Now, to protect this, you’ll have to write conditions for every possible value the program expects and handles the correct error conditions for every incorrect value. Now, won’t this increase your code size resulting in a lot of execution overhead.

Whereas, if you use second example, incorrect values cannot be passed at all and your code will be safe from attackers. and you need not write any extra guard conditions resulting in keeping your code size to minimum.

Alright!! By now, most of you would be thinking that how this post relate to bytecode reverse engineering but then, I just needed a starting point to explain a problem before getting into injecting malicious content in your bytecode to break what you consider secure.

In my next post, i’ll evaluate these bytecodes more and then, later on, we’ll talk about contaminating bytecodes to make the code malfunction. All my posts will consider the aspect of code performance vs. code safety amd I am not sure whether these thoughts of mine will make any sense but I do need a place to vent out.

© Safer Code | Using Enum Pattern in Java < 1.5

Related posts

• And So It Begins… (0)
• All Input is Evil (3)
• Validating Untrusted Integer Inputs (6)
• Predicting the rand() and using Cryptographic Random Numbers (7)
• Tainted Object Propagation (5)

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

Basically, Tainted Object Propagation is the term defined for using incorrect or invalid inputs to get more than required information from the system and in some cases, taking control of the system. Although this technique is much widely used to misuse web applications and database oriented applications, but this holds true for any API publisher who exposes his API’s to third party application writers.

Again, just like previous post, Let’s start with an example.

Consider that a web page or an application takes an input “userName” and the application executes the following query to find that particular user.

HttpServletRequest request = ...;
String userName = request.getParameter("name");
Connection con = ...
String query = "SELECT * FROM Users " + " WHERE name = ’" + userName + "’";
con.execute(query);

Now, this is the usual code written by programmers to get the particular from the database. Now, if an attacker gets the control of the userName field, he can set it to ‘OR 1=1; This query allows the user to circumvent user name check and returns all the users from the database. In this case, the input variable “userName” is considered as Tainted Object.

Lets take another example,

<input type="hidden" name="total_price" value="25.00">

A web form contains hidden fields to pass some information to the server which is not visible to the user. Now, HTTP pages are stateless. Unlike regular fields, hidden fields cannot be modified directly by typing values into an HTML form. However, since the hidden field is part of the page source, saving the HTML page, editing the hidden field value, and reloading the page will cause the Web application to receive the newly updated value of the hidden field.

Following is the classification of various attacks:

Now, I’ll describe how to “UnTaint” your objects.

In order to track tainted inputs, we must specify following three things:

To track the taintedness of strings, we associated a taint flag with every string. This taint flag is set when a string is returned by a source method. We propagate this taint flag to strings that are derived from tainted strings through operations such as concatenation, case conversion etc.

To “Untaint”, we need to have mechanism in place which will subject every input for taint verification and then, untaint it. For example: a tainted string that is passed through a regular expression match, or been tested for the presence of a particular character is not tainted anymore. Note that, here we need to trust the programmer to have performed a meaningful check that accounts for all cases that might be exploitable in an attack. It is entirely possible that the programmer wrote a faulty input validation routine that lets through user-input strings with malicious content in them.

If we find any tainted object using these algorithms, then two things can be done. Either raise a TaintException or Abandon that particular taint session. The weakest option is to let tainted data be used as an argument to a sink, but make a full log of the arguments, the sink, and the path the tainted data took from source to sink. This seems insecure, but is useful when auditing, doing penetration testing, debugging, or if used in a honeypot.

The best way to find most of the taint problems and the code vulnerablity is use of static analyzer tools. These tools identify the possibility of any input field being maliciously utilized and raise a warning to fix that error. The algorithms by which most of these static analyzer tools work use the above mentioned methodology. Some of the java static analyzer tools work on the bytecode level to prevent bytecode contamination also.

But even after this, you may find some taint issues coming your way. In this case, no one can defeat the strictest of code reviews. More strict the code review and reviewer, less the code is prone to attackers.

There is a lot of information available on the net about Taint object problem. I have used the resources available on the net itself to make myself aware of the gory details and if you are interested, search details on the net . By going through the details, even you should be able to build you own static analyzer tool.

© Safer Code | Tainted Object Propagation

Related posts

• Using Enum Pattern in Java < 1.5 (1)
• And So It Begins… (0)
• Validating Untrusted Integer Inputs (6)
• Predicting the rand() and using Cryptographic Random Numbers (7)
• int main() vs void main() (22)