The iPhone SMS Hack Explained
GhostX9 writes "Tom's Hardware just interviewed Charlie Miller, the man behind the iPhone remote exploit hack and winner of Pwn2Own 2009. He explains the (now patched) bug in the iPhone which allowed him to remotely exploit the iPhone in detail, explaining how the string concatenation code was flawed. The most surprising thing was that the bug could be traced back to several previous generations of the iPhone OS (he stopped testing at version 2.2). He also talks about the failures of other devices, such as crashing HTC's Touch by sending a SMS with '%n' in the text."
Though it hasn't been so directly argued for a while, there is still the belief that OSS is somehow unique and better than closed source software because it engages the lone hacker sitting in his basement writing code in his spare time. What I found interesting was Charlie Miller's take on unpaid effort.
Financial incentive is, despite the feeble arguments to the contrary, still the thing that gets code written (and bugs found). Without paying the developers, Linux never would have gotten to the stage it is now. Yes, the source code is open, but it is primarily because there is a team of developers getting paid to write the OS source code that we have such a great system today.
The hobbyist is still just a user. The real developers do it as their job.
Makes you wonder how many iPhone owners who have jailbreaked (-broken?) their devices are still vulnerable to this hack. It isn't exactly fun to have to jailbreak every time an update gets released.
-FB
Take that, HTC-fanboys!
DoS or gain root to a celltower?:
"Just as the software in the iPhone should be able to handle any type of input it receives, the cell towers should too."
except Charlie just proved this to be false
"I think if I fuzzed the phone using the carrier network, I probably would have crashed something. Even though it would be unintended, I could see them throwing me in jail for that, and that's one place I don't want to visit!"
The carrier should be paying you six figures for revealing the hack to them benignly, rather than with malintention
look, carriers: if there is a hack out there, someone will exploit it one day. your choices are:
1. have no idea who is doing what until something awful happens to your network and your customers and you need to pay big bucks to fix it, not to mention the financial hit from the hit to your reputation
2. offer up front a cash reward to anyone who discovers a bug (scaled to severity), and you will paying great rewards and still be paying 1/10th or 1/100th of what you would pay if you found the hack out the hard way
and instead, people like Charlie are under threat of jail for doing what they do in good faith, to your benefit
talk about shortsighted
you catch more flies with honey than with vinegar
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Almost as never ending as the flow of programmers that don't bother to learn the intricacies of their language.
``OK, so ten out of ten for style, but minus several million for good thinking, yeah?''
From the end of TFA where they are talking about jail broken phones crashing cell toweres
Charlie: This is complete BS. You can diff a jailbroken kernel with a standard iPhone kernel and there are very few places that are changed. In particular, it doesn't mess with anything that has to do with the communication with the carrier. Even if it did do something crazy, which it doesn't, I would hope that the towers are robust enough to handle it. Just as the software in the iPhone should be able to handle any type of input it receives, the cell towers should too. I hope the carriers adequately test their equipment. If not, they can always give me a call, I'd be happy to help. In other words, if all it takes for a terrorist to take down cellular communication in this country is have a jailbroken iPhone, we're in trouble.
He starts of by asserting that it is BS, but then goes on to invoke an awful lot of belief in unicorns and pixie dust to support his statement. And even applies the same logic to the iPhone, even though the entire FA is all about how the real world isn't so magical.
It sort of leaves me wondering about the quality of his off-the-cuff statements about things that he hasn't tested (which I suppose is a bit ad-hominem-ish, but it does come across as wishful thinking)
I am Slashdot. Are you Slashdot as well?
The HTC bug, however, looks like it's caused by improper use of string formatting. That sort of problem can occur with any language, as seen with the host of sites (most of them written in high-level languages) that have had SQL injection vulnerabilities in the past.
It's true that some languages and constructs are more dangerous than others, but at some level, programmers just have to bear in mind what they're doing and how they're using their data.
and how you would implement a garbage collected language? somewhere between the language and the hardware, there will be some pointer juggling.
also don't pretend that parsing problems don't happen on managed platform:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5333
I think Charlie and the interviewer(Alan) misunderstood Apple's comments on jailbreaking. The point they were making is that jailbreaking could allow people to crash the cell towers by installing malicious software on the phones, not that jailbreaking itself would cause problems. And technically this could be true depending on how crappy the cell tower software is.
He didn't prove anything, he was just guessing that sending 500 malformed SMS messages *could* affect the towers negatively and the carriers probably wouldn't like that.
Look at COBOL. It's essentially a dead language, but look at how much live COBOL code is still out there. There's a hell of a lot more C out there than COBOL. If you wanted to replace all the C code that's out there, it would be many more billions than the total caused by bugs in C. And nobody is going to want to make that investment.
Miller mentions using AT commands to the GSM modem to send all the bogus SMS messages. That's nice. Did you know you could do that with any Motorola phone and a serial cable long before the iPhone was a clever idea in someone's head? You can even buy bare GSM modem modules for control and security systems, telemetry, etc... insert your SIM and go.
Could you cause cell network mayhem and/or go to jail for what you're able to do with AT commands? Probably. Look at all the phreaky fun you could (can still?) have with the POTS network and a modem. But it has nothing to do with the iPhone or jailbreaking in particular. Jailbreaking is just opening up the iPhone's OS to user code. Once you've done that, you could get into the other parts of the phone, such as the baseband processor. That's where you unlock the phone or... well, I suppose if you were clever enough to load custom firmware into the baseband, you could do really nasty stuff at the RF packet level to the towers. But again, every model of phone has a baseband, and they're all reprogrammable (that's how carriers lock phones in the first place)
I am uncertain of any problems with the Treo (SMS) does anyone have any insight with the Treo as to what kind of vulnerabilities it might have, I am curious.
Pretty much all USB 3G dongles work like this. They present a USB interface that takes AT commands.. exactly the same ones that Apple are so scared will being down civilisation as we know it.
How much does a cellphone cost? Now ask how much it would take to get an RF transmitter capable of speaking cellphone well enough to hack a tower. Getting access to transmitters is not a major barrier. I want to know why towers are not running heavily validated code given their importance as communications systems.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
hmmm....dongle.
that is a really funny word.
dongle
dongle
dongle
dongle
Sorry, going a couple days without sleep makes you kind of screwy. but still...
Dongle.
who prays for Satan? Who in 18 centuries has had the humanity to pray for the 1 sinner that needed it most? ~Mark Twain
Look at COBOL. It's essentially a dead language
COBOL is pretty much anything but dead. There are still new versions of the language being released and still developers being paid to work with legacy systems running it. COBOL may be a language many developers wish was dead, but so long as companies use it, other companies like Micro Focus and IBM will work on new standards and tool sets.
And when it comes to the grandparent's comments about C, how many other low level languages are there out there that would even be considered as a suitable substitute without any of the same issues? We can't just abstract away from the hardware without that abstraction layer being written in something.
Translation: I don't understand these things, so they must be problematic.
What this really says is how crappy some programmers are. A good programmer knows that he can't pass arbitrary user-generated strings right into printf. And validating user input isn't limited to C.. What about a java app that interfaces with SQL, or a web app that has to generate HTML based on a user form? They would have to have some degree of care about where there strings come from too.
Maybe the HTC thing has something to do with the fact that HTC is a Taiwanese company. In my experience a lot of these fly-by-night Asian companies don't give a shit about security, they just want to code something up quick that's cool. Could say the same thing about Apple, also, actually -- they don't have the best security track record, and it's probably a result of their priorities.
and how you would implement a garbage collected language? somewhere between the language and the hardware, there will be some pointer juggling.
Exactly. Someone, somewhere will be responsible for preventing this kind of stuff. Of course, with using JAVA or other similar language, you then must trust that the language developers do not have this kind of bug, that you then don't have the ability to patch out.
Write your representatives! Repeal the 2nd Law of Thermodynamics!
Are you the guy who pushes the system drivers be written in Python?
Alan: Apple and AT&T have claimed that "Jailbreaking" could cause problems with the ECID? Based upon your knowledge of the iPhone, do you believe this to be true?
Charlie: No, this is AT&T trying to make sure they make as much money as possible. Absolute FUD.
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
Here unsafe is an unvalidated string. The printf() function is variadic which means that it will use some macros which walk up the stack reading the next n bytes as some variable of a type specified by the callee. There is no validation performed anywhere that this is not just walking into the next function's locals. If unsafe is "%s" then the function will read a word from beyond the call arguments as being a pointer. It will then dereference this and read from there until it encounters a NULL byte.
Compare this to something like Erlang, Lisp, Haskell, Smalltalk, Java, and so on, which do not support variadic functions in this way. In these languages, the equivalent would be a function that takes a string and an array or list as arguments. The equivalent in Erlang, for example, would be:
If Unsafe contains escape sequences, you get a run-time exception caused by trying to access the first element in an empty list. The same is true of any language which has either bounds-checked arrays or lists as a core data type. In both cases, the correct thing to do is usually something like:
Only the C case accesses memory at a random address if you do it wrong though.
I am TheRaven on Soylent News
Unless, of course, you use a real computer.
I am TheRaven on Soylent News
is that you, APK?
Did you read what was written in that article? Macs do not fully support ASLR, therefore they're less secure, which is a ridiculous statement.
Besides, Snow Leopard *will* support ASLR.
Non impediti ratione cogitationus.
The problem is very few programmers can master C. And the masters can occasionally make an error that may cost millions in the process. Why not move to another programming language that is safer?
Yes and no. The way you work around string formatting bugs (aside from not passing a user-supplied string to the format parameter of printf, which is simply a bonehead mistake) is to verify the number of parameters before outputting anything. You can actually do this in C, but most C libraries don't seem to bother - they assume that however many parameters the format string calls for are there, and will happily work their way down the stack until the format string ends or they try to read/write somewhere impossible and get a memory violation. Most higher-level languages do in fact check for this, and will throw an exception if the format string and number of parameters don't match.
You can also take the MS libc approach, and disable %n (the only extremely dangerous, and coincidentally very rarely used, format token) by default. If you want to use it, there's a compiler option to re-enable it, but by default you're... less unsafe than, for example, glibc.
There's no place I could be, since I've found Serenity...