Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


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

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:

size_tinput_size = getchar();
char* buf = malloc(input_size);
gets(buf); // if more than input_size bytes is available for input, heap overflow occurs

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:

let inputSize : Int32 = getchar()
let buf = UnsafePointer<Int8>.alloc(Int(inputSize))
gets(buf) // if more than input_size bytes is available for input, heap overflow occurs * /

Stack overflow is also possible through this C-compatibility mechanism. Here we demonstrate changing the value of a local constant via pointer manipulation:

func addrExt(p:UnsafePointer<Int>) ->UnsafePointer<Int> {
	return p
var a = 222
let b = 333
let pa : UnsafePointer<Int> = addrExt(&a)
println(b) // Prints 444

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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

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.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.