Apple certainly does test them to some extent. But one of the things it does *not* do is return the developer the results of the testing. Mostly a simple “no” or “yes”. It's more of a backlog of applications waiting to get the rubber stamp than extensive security auditing (which would see them return you an extensive documentation of vulnerabilities found, if any).
In fact one could make the case that if they were so very concerned about security they would hail the likes of Java (and to a lesser extent Flash) as a Good Thing. After all, it is much harder to write a Java application that crashes the underlying OS due to the fact that any half decent underlying VM takes away many of the common attack vectors for arbitrary code execution (buffer over/under-runs, stack smashing, and generally everything to do with unmanaged pointers and references). C++ & libraries is a much less secure `platform' than Flash is. Let's entertain the following scenario:
You write an application that handles transactions of some nature and thus has to do with sensitive data from a user account. You are not an experienced coder; in fact your natural inclination would be to write your application in Flash. You can't because Jobs doesn't like it; so instead you write an application in C++. How hard can it be? Now you don't like it when people have to sign on every time: you want your application to remember their authentication details for them. You are not stupid: you know that saving a password in plaintext is not a good idea, generally speaking. Assuming that the server where you authenticate with your credentials expects both user name and password to be encrypted with SHA-256 hashes you cook up the following text file format:
Code:
url = http://www.auth-domain.com/path/to/app?query=string¶ms=values
name= sha-256-of-account-name
pass = sha-256-of-account-pass
What would an attacker have to do but overwrite the URL field, conditionally, disguised in a silly game? But more subtly: is your application prepared for a malformed sha-256 that is *not* 256 bits long? If you read that as binary data and you attempt to read a byte buffer of exactly 64 bytes from name where there was only "hook-line-and-sinker" what will hapen? You will read: "hook-line-and-sinker\x0Apass = "+58 characters of pass.
This type of attack, incidentally is not as uncommon as you might hope. It can happen to *any* application that uses the scanf() family of functions to interpret a line as a formatted string and extract the formatted data from it. The typical result would be a segfault.
Bookmarks