Spotting the Sin During Code Review

This one can be pretty fuzzy, because most systems dont have a well-defined notion of which data should be privileged and which data shouldnt. Ideally, you would have a sense of how every important piece of data can be used, and could trace that data through all uses in the code to see if it could ever flow to entities it shouldnt. Its definitely doable, but its generally a lot of hard work. This is best left to some sort of dynamic mechanism that can enforce the Bell-LaPadula model on the fly.

If you have such a model, you really only need to audit the relationships between privileges and the points of explicit declassification, to make sure that both of those elements are sound.

In practice, there will be a lot of scenarios where theres no Bell-LaPadula model being enforced, and were interested in detecting whether were leaking system data. We can identify candidate data we might be leaking, and then follow it through the program.

The first thing youll need to do is identify the functions that interface with the operating system that could yield data useful to an attacker. The list is large, we have to admit, but this is a good starting point.

Language

Key Words to Look For

C/C++ (*nix)

errno, getenv, strerror, perror, *printf

C/C++ (Windows)

GetLastError, SHGetFolderPath, SHGetFolderPathAndSubDir, SHGetSpecialFolderPath, GetEnvironmentStrings, GetEnvironmentVariable, *printf

C#, VB.NET, ASP.NET

Any exception, System.FileSystemInfo namespace, Environment class

Java

Any exception

PHP

Any exception (PHP5), getcwd , DirectoryIterator class, $GLOBALS, $_ENV

Once you have isolated any instances of these keywords, determine if the data is leaked to any output function that may find its way to an attacker.

If we want to find timing attacks, we start by identifying secret data, such as cryptographic keys. Then, we examine the operations on that secret data to see if the operations are in any way dependent on it. From there, we need to determine whether dependent operations run in varying time, based on the secret data. That can be difficult. Clearly if there are branches, there will almost certainly be timing variances. But, there are plenty of ways that arent obvious to introduce timing variances, as we discussed above. Crypto implementations should be suspect if theyre not explicitly hardened against timing attacks. While timing attacks on crypto code may or may not be practical remotely, they generally are practical to use locally. Particularly if you have local users, you may be better safe than sorry.

One thing that makes crypto timing attacks easier is when someone performing crypto operations includes a high-precision time stamp with their data. If you can skip the time stamp, do so. Otherwise, dont use all of the precision. Round to the nearest second, or the nearest tenth of a second.



19 Deadly Sins of Software Security. Programming Flaws and How to Fix Them
Writing Secure Code
ISBN: 71626751
EAN: 2147483647
Year: 2003
Pages: 239

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net