Security

Security Issues in Swift: What the New Language Did Not Fix

By Denis Krivitski, August 19, 2014

The security issues that existed in Objective-C have been only partially addressed in Swift. What to watch out for?

Swift is a new language developed by Apple for iOS and OS X development. Introduced at Apple's developer conference WWDC 2014, the language is designed to eventually replace Objective-C and provide several important benefits, one of which is greater resilience against erroneous code.

In this article, I assess how Swift compares with Objective-C from the security perspective. My team based our comparison on Apple's Secure Coding Guide document, examining the various security vulnerabilities stated in the document and checking if they can be exploited in Swift. It is important to mention that we explored only loopholes that exist in Objective-C, not new ones that might exist in Swift.

In each case, we use the typical classification for defects, which include the category, the severity, and the likelihood that the vulnerability might be exploited.

Integer Overflow

Severity: High
Likelihood of Exploit: Medium

The Integer Overflow vulnerability can be exploited when user-supplied input is used in calculating the amount of memory that is to be allocated. When the user input is not validated, there is the potential for a malicious user to enter a number that is too large for the integer data type, which can cause program crashes among other problems.

In two's-complement arithmetic, a negative number is represented by inverting all the bits of the binary number and adding 1. When the digit in the most-significant bit is 1, it indicates a negative number. Therefore, in Objective-C:

int a = 2147483647;
a += 1; // a == -2147483648

If a malicious user specifies a negative number when an unsigned number is expected, it might be interpreted as a very large number. Your program may then attempt to allocate a buffer of that size, leading to a heap overflow if allocation errors were not properly handled. In earlier versions of the Safari Web browser, for example, storing objects into a JavaScript array allocated with negative size could overwrite memory.

In Swift, integer overflow cannot be used for security exploitation. In contrast with Objective-C's behavior, an overflow causes a runtime error in Swift, making it impossible for the attacker to exploit this vulnerability. For example, in Swift:

var a : CInt = 2147483647
a += 1 // Runtime error

In sum, Swift shows across-the-board improvement and is immune to the Integer Overflow vulnerability, unlike the older Objective-C.

Buffer Overflow

Severity: Very High
Likelihood of Exploit: High to Very High

A buffer overflow occurs when an application attempts to write data past the end of a buffer. These overflows can cause applications to crash, compromise data, and provide an attack vector for further privilege escalation. Books on software security invariably mention buffer overflows as a major source of vulnerabilities. Approximately 26 percent of the exploits published by United States Computer Emergency Readiness Team (US-CERT) for 2012 involved buffer overflows.

In Objective-C, a buffer overflow may be caused by incorrect pointer manipulations, by incorrectly allocating heap memory, or by incorrect C-string manipulation. For example:

The surprising fact is that the same kind of heap overflow can be reproduced in Swift. Although Swift does not have pointers, which are the cause of buffer overflow bugs, it has a capability to call C functions. To make this C function calling possible, Swift provides some pointer-like constructs, such as UnsafePointer. By using these constructs, it is eventually possible to reproduce the exact same heap overflow:

In sum, the risk of buffer overflows in Swift is lower than in Objective-C due to the lack of pointers, although it is still possible to mistakenly create a loophole. Fortunately, Swift's term, UnsafePointer, is a reminder of the dangers of this feature.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!