Reviewing 3rd Party code for security issues

Question

I've been asked to oversee reviewing some 3rd party code (Freeware C# Sharepoint webpart in this case) before its inclusion on a internal corporate network. The big concerns are malicious code hidden in the webpart that will steal data/send information back to the webpart creator/etc, with a secondary concern being it will cause performance issues.

We have the source code, and in this case there is less than 2000 lines of code so it's not hard to manually run through it all and make sure everything is OK. For a larger work what sort of approach is needed to audit code to make sure, as much as possible that is it safe? We'll need to do this for larger codebases in the future.

Answer 1

Break it up into modules and examine them in isolation.

Look over every method to make sure that it performs as-advertised. Start at the lowest-level methods that only make API calls - once you've verified that those do what they say on the tin, you can then verify the methods that call them without worrying about exactly what they do.

One way of going about it would be to look at the method "blind", write down what you think it does, and then compare that to what it says in the documentation.

Answer 2

i wrote an article on this subject for IEEE Security & Privacy http://blogs.msdn.com/michael_howard/archive/2006/08/01/686029.aspx

Answer 3

So, you don't care if the code is insecure and you get hacked by the Chinese? Usually when people do code reviews they are concerned with being attacked by outsiders and the majority of commercial tools reflect this. Keep in mind that hackers regularly exploit MANY different types of vulnerabilities without access to the source code. The best commercial static analysis tool for C# is Fortify. Unfortunately if someone is writing a backdoor it could look like anything and even a manual code review will likely miss the issue.

In the case of hijacking information I recommend creating a build validation test that looks at network traffic. Having build validation tests is important to maintaining a stable code base during development. Though the coarse of testing the application you want to see if there is network traffic being set to an unknown server. You could even run this build validation for days/months/years to see if the application behaves in an unexpected way. Needless to say this particular game of cat and mouse is rather tricky and I don't believe there can be a bullet proof solution.

Answer 4

If you honestly believe there is even a remote possibility of an evil backdoor, you shouldn't use the code. This is the kind of corporate assignment that just baffles me. Even if it's free, it could never be worth the risk.

That being said, code from a reputable source is likely more secure than your own because it is tested (hopefully) across a larger and more diverse set of users. If the review is simply to appease management and the code runs on a VM, guard yourself with the runtime's security features:

• .NET Code Access Security
• Java Security Architecture

If the code compiles natively or is interpreted, things get trickier. Look for library inclusions that don't make sense: TCP in a library that has nothing to do with a network, file IO where it doesn't belong... Again, I personally wouldn't touch it if I didn't have 100% faith in it.

As for performance, treat it like any other part of the application. Don't optimize until you know there's a problem. If you see performance issues and your tracing leads you to the 3rd party code, trace further in and find the problem. If the problem appears to be significant and grotesque, don't use the code. It's likely an indication of other bad things lurking about.