Privacy Considerations for C Language Applications
Privacy has become one of the most important considerations in computing security mainly because of the growth of social media applications and services. Despite the prevalence of “next-generation” services ranging from social-networking websites to online banking, some users, administrators, and developers don’t yet have a full understanding of what kind of privacy to expect when using or developing a service.
Privacy is an aspect of security—just as you don’t want strangers looking in the windows of your home, you also don’t want the person next to you reading your private communications from a public place. When messaging companies don’t use SSL, anyone can monitor your activity. Incredible as it may sound, prior to the advanced persistent threat from China toward Google, SSL was still an optional feature; now, even after that experience, there are some social networking websites that still do not use SSL.
Of course SSL does not mean you are automatically secure. The advanced persistent threat from China involved Internet Explorer 6 and targeted Windows XP Service Pack 2, which does not benefit from security mechanisms such as Address Space Layout Randomization (ASLR), introduced by Microsoft in Windows Vista to deter attacks. To increase security, Microsoft Security Response Center (MSRC) regularly publishes security patches and encourages users to update their systems to help stay safe.
In January 2010, Facebook founder Mark Zuckerberg told a live audience that the age of privacy is over. Privacy is not only a matter of design but also of leadership; if your project leader does not believe in privacy, do not expect to see it prioritized.
Clearly, recent attacks indicate that neither users nor administrators are vigilant enough about security updates and patches. And, while from a developer point of view, privacy is certainly an aspect of security, developers have not been cautious enough about writing code that is both bug-free and that enhances security. In fact, developers tend to think more about unusual or unexpected cases than about writing code that avoids vulnerabilities from the very beginning.
It’s been several years since functions such as memcpy() have been considered deprecated and unsafe. But C-language developers are still using it instead of using memcpy_s() introduced in Microsoft Visual Studio C++ 2005. This is probably what encouraged the Visual Studio C++ 2010 team to automatically overload standard function names dealing with memory bugs like memcpy() by memcpy_s(). (You can learn more about the standard names memory flag in the blog article by Michael Howard, author of the Writing Secure Code series of books.)
Overflows are the most well-known bug; they exist in both user mode and kernel mode. Microsoft implemented some security mechanisms to make exploitations more difficult. However, while more difficult, exploitation is still not impossible. That’s why developers still need to be focused on the code they write.
If you have something like:
strcpy(name, familyname, strlen(familyname));
Do you expect to see your application working fine after such programming logics? What if the user name of your customer is more than 10 characters?
strcpy_s(name, sizeof(name) * (sizeof(name)), familyname, strlen(familyname));
Is the safer way to perform a memory copy:
unsigned int total_price;
unsigned int producta_quantity, productb_quantity;
if ((producta_quantity != 0) || (productb_quantity != 0))
total_product = producta_quantity + productb_quantity;
total_price = total_product * 256;
Another common security vulnerability is called integer overflow. Let’s say you have a customer ordering two different products with a value of $256.
Imagine if producta_quantity = 4 294 967 295 (0xFFFFFFFF) and productb_quantity = 1. You know what will happen? The total_product integer will be equal to 0 because these variables are 32-bit variables.
Now, let’s imagine the total_product = 16777216. (0x1000000). Can you guess the value of total_price? Yes… it’s 0. This is why Reiner Fink from Microsoft came up with safe int functions, which were introduced by Michael Howard in 2006 on his blog.
(SUCCEEDED(UIntAdd(producta_quantity, productb_quantity, &total_product))
SUCCEEDED(UIntMult(total_product, 256, &total_price)))
With this function, you can avoid mistakes mentioned above.
It’s worth noting is that the difference between unsigned and signed integers can also be the source of vulnerabilities. Trickier security and privacy issues and vulnerabilities exist.
For example, imagine you are developing an application that requests a password from the user. If you do not fill the buffer containing the plain-text password with null bytes, the password will remain in memory in plain text. And it can easily be retrieved using a full memory acquisition product like the free windd product I created.
In 2004, Microsoft developed a process model called the Security
Development Lifecycle (SDL) to help reduce security-related design and coding vulnerabilities
and to minimize the severity of any remaining vulnerabilities. Now fully
embraced by Microsoft, SDL helps developers write more stable and secure
software. In February 2010, the SDL team presented
several great additions to SDL resources, including a white paper called Simplified Implementation of the
Microsoft SDL, the release of the new version of Microsoft Solutions
Framework (MSF) for Agile Software Development, and free related software. The SDL blog regularly publishes valuable information
and is a good resource for developers.
Matthieu Suiche is a security researcher who focuses on reverse code engineering and volatile memory analysis. His research and utilities to date have included Windows hibernation files, Windows physical memory acquisition (Win32dd/Win64dd), and Mac OS X physical memory analysis.
Matthieu has been a speaker during various security conferences such as PacSec, BlackHat USA, EUROPOL High Tech Crime Meeting, and Shakacon. Prior to founding MoonSols, a computer security and kernel code consulting and software company, in 2010, Matthieu worked for companies such as E.A.D.S. (European Aeronautic Defence and Space Company) and the Netherlands Forensics Institute of the Dutch Ministry of Justice.