Avoiding Buffer Overflows and Underflows

Buffer overflows, both on the stack and on the heap, are a major source of security vulnerabilities in C, Objective-C, and C++ code. This chapter discusses coding practices that will avoid buffer overflow and underflow problems, lists tools you can use to detect buffer overflows, and provides samples illustrating safe code.

Every time your program solicits input (whether from a user, from a file, over a network, or by some other means), there is a potential to receive inappropriate data. For example, the input data might be longer than what you have reserved room for in memory.

When the input data is longer than will fit in the reserved space, if you do not truncate it, that data will overwrite other data in memory. When this happens, it is called a buffer overflow. If the memory overwritten contained data essential to the operation of the program, this overflow causes a bug that, being intermittent, might be very hard to find. If the overwritten data includes the address of other code to be executed and the user has done this deliberately, the user can point to malicious code that your program will then execute.

Similarly, when the input data is or appears to be shorter than the reserved space (due to erroneous assumptions, incorrect length values, or copying raw data as a C string), this is called a buffer underflow. This can cause any number of problems from incorrect behavior to leaking data that is currently on the stack or heap.

Although most programming languages check input against storage to prevent buffer overflows and underflows, C, Objective-C, and C++ do not. Because many programs link to C libraries, vulnerabilities in standard libraries can cause vulnerabilities even in programs written in “safe” languages. For this reason, even if you are confident that your code is free of buffer overflow problems, you should limit exposure by running with the least privileges possible. See“Elevating Privileges Safely” for more information on this topic.

Keep in mind that obvious forms of input, such as strings entered through dialog boxes, are not the only potential source of malicious input. For example:

1. Buffer overflows in one operating system’s help system could be caused by maliciously prepared embedded images.
2. A commonly-used media player failed to validate a specific type of audio files, allowing an attacker to execute arbitrary code by causing a buffer overflow with a carefully crafted audio file.
   [¹CVE-2006-1591 ²CVE-2006-1370]

There are two basic categories of overflow: stack overflows and heap overflows. These are described in more detail in the sections that follow. More Detail

Courtesy: https://developer.apple.com/library/mac/#documentation/security/conceptual/SecureCodingGuide/Articles/BufferOverflows.html

Who calls the main function of you app during the app launch cycle?

During app launching, the system creates a main thread for the app and calls the app’s main function on that main thread. The Xcode project's default main function hands over control to the UIKit framework, which takes care of initializing the app before it is run.

Exception handling in Objective C

Exception Handling

The Objective-C language has an exception-handling syntax similar to that of Java and C++. By using this syntax with the NSException, NSError, or custom classes, you can add robust error-handling to your programs. This chapter provides a summary of exception syntax and handling; 

Enabling Exception-Handling

Using GNU Compiler Collection (GCC) version 3.3 and later, Objective-C provides language-level support for exception handling. To turn on support for these features, use the -fobjc-exceptions switch of the GNU Compiler Collection (GCC) version 3.3 and later. (Note that this switch renders the application runnable only in OS X v10.3 and later because runtime support for exception handling and synchronization is not present in earlier versions of the software.)

Exception Handling

An exception is a special condition that interrupts the normal flow of program execution. There are a variety of reasons why an exception may be generated (exceptions are typically said to be raised or thrown), by hardware as well as software. Examples include arithmetical errors such as division by zero, underflow or overflow, calling undefined instructions (such as attempting to invoke an unimplemented method), and attempting to access a collection element out of bounds.

Objective-C exception support involves four compiler directives: @try, @catch, @throw, and @finally:

• Code that can potentially throw an exception is enclosed in a @try{} block.
• A @catch{} block contains exception-handling logic for exceptions thrown in a @try{} block. You can have multiple @catch{} blocks to catch different types of exception. (For a code example, see “Catching Different Types of Exception.”)
• You use the @throw directive to throw an exception, which is essentially an Objective-C object. You typically use an NSException object, but you are not required to.
• A @finally{} block contains code that must be executed whether an exception is thrown or not.

This example depicts a simple exception-handling algorithm:

Cup *cup = [[Cup alloc] init];

@try {

[cup fill];

}

@catch (NSException *exception) {

NSLog(@"main: Caught %@: %@", [exception name], [exception reason]);

}

@finally {

[cup release];

}

Catching Different Types of Exception

To catch an exception thrown in a @try{} block, use one or more @catch{}blocks following the @try{} block. The @catch{} blocks should be ordered from most-specific to least-specific. That way you can tailor the processing of exceptions as groups, as shown in Listing 10-1.

Listing 10-1  An exception handler

@try {

...

}

@catch (CustomException *ce) { // 1

...

}

@catch (NSException *ne) { // 2

// Perform processing necessary at this level.

...

}

@catch (id ue) {

...

}

@finally { // 3

// Perform processing necessary whether an exception occurred or not.

...

}

The following list describes the numbered code lines:

1. Catches the most specific exception type.
2. Catches a more general exception type.
3. Performs any clean-up processing that must always be performed, whether exceptions were thrown or not.

Throwing Exceptions

To throw an exception, you must instantiate an object with the appropriate information, such as the exception name and the reason it was thrown.

NSException *exception = [NSException exceptionWithName: @"HotTeaException"

reason: @"The tea is too hot"

userInfo: nil];

@throw exception;

Important: In many environments, use of exceptions is fairly commonplace. For example, you might throw an exception to signal that a routine could not execute normally—such as when a file is missing or data could not be parsed correctly. Exceptions are resource-intensive in Objective-C. You should not use exceptions for general flow-control, or simply to signify errors. Instead you should use the return value of a method or function to indicate that an error has occurred, and provide information about the problem in an error object. 

Inside a @catch{} block, you can rethrow the caught exception using the @throw directive without providing an argument. Leaving out the argument in this case can help make your code more readable.

You are not limited to throwing NSException objects. You can throw any Objective-C object as an exception object. The NSException class provides methods that help in exception processing, but you can implement your own if you so desire. You can also subclass NSException to implement specialized types of exceptions, such as file-system exceptions or communications exceptions.

Courtesy:http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/Exceptions/Tasks/HandlingExceptions.html#//apple_ref/doc/uid/20000059-SW1

Macbook : How do I stop speech man

 Command+f5
It is also in System Preferences under Universal Access
Turn off VoiceOver

Recovering Memory You Have Abandoned

The Allocations trace template measures heap memory usage by tracking allocations, including specific object allocations by class. It also records virtual memory statistics by region. It consists of the Allocations and the VM Tracker instruments.

Avoid abandoned memory by ensuring that the heap does not continue to grow when the same set of operations are continuously repeated. For example, opening a window then immediately closing it, or setting a preference then immediately unsetting it are operations that conceptually return the app to a previous and stable memory state. Cycling through such operations many times should not result in unbounded heap growth. To ensure that none of your code abandons memory, repeat user scenarios and use the Mark Heap feature after each iteration. After the first few iterations (where caches may be warmed), the persistent memory of these iterations should fall to zero. If persistent memory is still accumulating, select the focus arrow to see a call tree of the memory. There you can identify the code paths responsible for abandoning the memory. Ensure that your scenarios exercise all your code that allocates memory.

Courtesy: https://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/MemoryManagementforYouriOSApp/MemoryManagementforYouriOSApp.html