Misplaced Trust

Misplaced Trust

When you're analyzing designs and code, it's often easy to find areas of vulnerability by asking two simple questions. Do I trust the data at this point? And what are the assumptions about the validity of the data? Let's take a buffer overrun example. Buffer overruns occur for the following reasons:

  • The data came from an untrusted source (an attacker!).

  • Too much trust was placed in the data format in this case, the buffer length.

  • A potentially hazardous event occurs in this case, the untrusted buffer is written into memory.

Take a look at this code. What's wrong with it?

void CopyData(char *szData) { char cDest[32]; strcpy(cDest,szData); // use cDest ... } 

Surprisingly, there may be nothing wrong with this code! It all depends on how CopyData is called and whether szData comes from a trusted source. For example, the following code is safe:

char *szNames[] = {"Michael","Cheryl","Blake"}; CopyData(szNames[1]);

The code is safe because the names are hard-coded and therefore each string does not exceed 32 characters in length; hence, the call to strcpy is always safe. However, if the sole argument to CopyData, szData, comes from an untrusted source such as a socket or a file with a weak access control list (ACL) then strcpy will copy the data until it hits a null character. And if the data is greater than 32 characters in length, the cDest buffer is overrun and any data above the buffer in memory is clobbered. Figure 10-1 shows the relationship between the call to strcpy and the three points I made earlier.

figure 10-1 the conditions for calling strcpy in an unsafe manner.

Figure 10-1. The conditions for calling strcpy in an unsafe manner.

Scrutinize this example and you'll notice that if you remove any of the conditions, the chance of a buffer overrun is zero. Remove the memory-copying nature of strcpy, and you cannot overflow a buffer, but that's not realistic because a non-memory-copying version is worthless! If the data always come from trusted source for example, from a highly trusted user or a well-ACL'd file you can assume the data is well-formed. Finally, if the code makes no assumptions about the data and validates it prior to copying it, then once again, the code is safe from buffer overruns. If you check the data validity prior to copying it, it doesn't matter whether the data came from a trusted source. Which leads to just one acceptable solution to make this code secure: first check that the data is valid, and do not trust it until the legality is verified.

The following code is less trusting and is therefore more secure:

void CopyData(char *szData, DWORD cbData) { const DWORD cbDest = 32; char cDest[cbDest]; if (szData != NULL && cbDest > cbData) strncpy(cDest,szData,min(cbDest,cbData)); //use cDest ... }

The code still copies the data (strncpy), but because the szData and cbData arguments are untrusted, the code limits the amount of data copied to cDest. You might think this is a little too much code to check the data validity, but it's not a little extra code can protect the application from serious attack. Besides, if the insecure code is attacked you'd need to make the fixes in the earlier example anyway, so get it right first time.

Earlier I mentioned that weak ACLs lead to untrusted data. Imagine a registry key that determines which file to update with log information and that has an ACL of Everyone (Full Control). How much trust can you assign to the data in that key? None! Because anyone can update the filename. For example, an attacker could change the filename to c:\boot.ini. The data in this key can be trusted more if the ACL is Administrator (Full Control) and Everyone (Read); in that case only an administrator can change the data, and administrators are trusted entities in the system. With proper ACLs, the concept of trust is transitive: because you trust the administrators and because only administrators can change the data, you trust the data.



Writing Secure Code
Writing Secure Code, Second Edition
ISBN: 0735617228
EAN: 2147483647
Year: 2001
Pages: 286

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