Computer Security: improve software, avoid blunder
Recently, a severe vulnerability has been made public about how Apple devices are wrongly handling encryption. This vulnerability rendered SSL/TLS protection useless, and permitted attackers checking out a wireless network to capture or modify data in encrypted sessions.
In other words, all confidential data like passwords, banking information, etc. could have been siphoned off by a targeted attack. While Apple has been quick in providing adequate security patches for iOS devices and Macs, it is an excellent example of how small mistakes can lead to big security holes. Here is the corresponding code from Apple’s Open Source repository. Can you spot the issue?
1 static OSStatus
2 SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen)
3 {
4 OSStatus err;
5 ...
6 if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
7 goto fail;
8 if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
9 goto fail;
10 goto fail;
11 if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
12 goto fail;
13 ...
14 fail:
15 SSLFreeBuffer(&signedHashes);
16 SSLFreeBuffer(&hashCtx);
17 return err;
18 }
There you are!
The bug was introduced in line 10 most likely due to one copy/paste too many. While the “goto” in line 9 is executed only if the “if”-statement of line 8 is true, the additional “goto” of line 10 bypasses the subsequent security checks and the SSL connection is unverified. Such bugs are also not uncommon at CERN!
Security is an integral part of software in the same way as availability, functionality, maintainability and usability. More secure code means fewer interventions to fix and patch problems, thus increasing availability and improving maintainability. More secure code also means better control of user interfaces and user input, thus enhancing usability and functionality. Therefore, we strongly encourage you to perform in-depth testing of your software prior to deployment. Simply enable your compiler’s warning (“gcc –Wall –Wextra -Werror” for C/C++ or “javac –Werror –Xlint:all” for Java) and check the settings of your favourite editor or development environment.
Do not hesitate to use several compilers on your code: “clang” is a good alternative to gcc that may help you to find problems, and has nicely coloured output. Compiler warnings can point you to suboptimal coding practices too. In addition, deploy one of our static code analysis tools. These tools are supposed to review your code quickly, looking for some common potential bugs and vulnerabilities (both security- and non-security-related), thus increasing the reliability and security of your programs. The same webpage also provides recommendations on how to keep “secrets” secret and how to secure web applications, as well as a “Security Checklist”.
In addition, do not hesitate to contact us at Computer.Security@cern.ch for consultancy or a dedicated full-scale security audit, or check out our dedicated training sessions on secure coding, scheduled for Spring/Summer 2014:
• Developing secure software (4 hours)
• Secure coding in C/C++ (1 day)
• Secure coding in Perl (1 day)
• Secure coding in Python (1 day)
• Securing Java Applications (1 day)
• Securing Java and Web Applications (1 day)
• Securing PHP Web Applications (1 day)
Check out our website for further information, answers to your questions and help, or e-mail Computer.Security@cern.ch.
If you want to learn more about computer security incidents and issues at CERN, just follow our Monthly Report.
Access the entire collection of Computer Security articles here.
