Posted
by
timothy
on Monday August 10, 2009 @08:12AM
from the en-percent dept.

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.

This SMS stuff is a good example. Between us, Collin and I found one bug in iPhone, Android, and Windows Mobile. Then we stopped testing. We had enough for our talk, what motivation did we have to keep looking? This is really an unpaid hobby for us, so we do the minimum level of work possible to get results good enough for conference presentations.

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.

How is it related with open source at all? A good software need a dedicated coder(s) and in order to motivate them for a long time money is a good tool. What you say is a generic thing, and nobody said since code will be open, people will work for free software like slaves to make applications good enough. Free software concept is much more than good software.

Your argument is valid for everything, if you need to build something good you need dedication. And this dedication is only possible with a motivation that is what money is used these days. But believe me there are better motivators than money still today.

Yes there are better motivators than money, but unless your basic needs are met (food, shelter, clothing etc) then all the other motivation in the world won't help you. The only solution in that case is you better hope that the dedication to a cause is more addictive than crack.

You're forgetting that there are (still) some people and communities out there that do without money just fine. They grow their own food and/or barter for stuff they can't make or do. There's bound to be a few programmers there, too.

No, "real developers" do as much as they can to meet a deadline. No more... but often quite a bit less. There is no motivation to go "above and beyond" for "professional" work. Why bother? You've met the specs, and you almost certainly don't have the time.

On the contrary, with free software, the people who use the software make the software. This is not someone tinkering out of some kind of bored interest. These are people who have a need, and work on code until that need is met. They are out there.

No, "real developers" do as much as they can to meet a deadline. No more... but often quite a bit less....Unlike a "professional" who will stop as soon as possible and get the hell out, because there is no reason for any more, and usually reason for less.

Bullshit.

I don't know what cube farm you met these "real developers" of yours at but in my business "professionals" do what it takes to make the customer happy.

Having shipped dozens of commercial products in somewhat niche markets I can tell you that if you want to eat you do a great job and keep doing it, working directly with key customers if necessary to craft tools that will help them do their jobs better/faster/easier.

And being part of a small company means my income is directly based on those of my users, and in this economy it means working my ass off on as many projects as possible to keep the fridge full and shoes on my kids' feet, and each and every one of them has to be near-perfect at V1.0. There is no "fix these known things in a patch after we release."

I've seen more than my share of open source projects where your "non-real programmers" got tired and stopped at the horribly designed config file, or documentation, or at the "well it works good enough for me" part and people should be *glad* to sift through the code to figure out how it works.

*Professional* programmers have to go that extra 20% at the end, which usually takes 90% of the time, to make the software into a polished, finished, product, and we have to do it in such a way to minimize idiot user questions, which *will* happen, so we don't waste all our money dealing with tech support. Your open-source guys can just say "read the source" if you don't understand something.

Risking Karma here, but I have to agree. OSS as a rule simply doesn't have the polish that P2P software typically does (yes this is a generalization). It might run better, lighter, smaller footprint, etc, but as a whole product/pkg, it typically just doesn't have that sparkle that lets it compete with P2P.

Take Gimp for example. It mimics almost everything in Photoshop and it does a great job generally, but there are many things that are just downright glitchy. Things that would never fly in a pay product, but I suspect for OSS, they were categorized as 'good enough' and lowered in priority for other bug fixes. Things like having to sometimes click on a tool 2 or 3 times before it registers or you end up applying the wrong tool. I haven't been using gimp for oh..say more than 2 years give or take, but the problem still exists. Don't get me wrong. I love OSS. Without it I think the quality of P2P software would be poor at best. OSS keeps them on their toes in a way that other P2P software can't. Get it right, or lose out. It doesn't take much to push someone away from a product when you combine cost and poor quality.

OO.o tends to follow in MS's footsteps (scary thought). Although it might excel in some areas like ODF, it simply plays catch-up for the larger product. I think another part of the problem is we the user. I've caught myself far too many times saying "hey, it's free..why complain?".

It's important to note that a lot of OSS projects start out as ways to fill an unfilled (or poorly filled) gap in functionality. They're often labors of love started by one (maybe two) people with no real project management. There are, of course, high-profile exceptions, but they are indeed the exceptions.

Furthermore, I suspect that there's very little in the way of usability testing with most OSS. Many users of lower-profile OSS are enthusiasts. They don't mind adapting to the computer. Commercial sof

Take Gimp for example. It mimics almost everything in Photoshop and it does a great job generally, but there are many things that are just downright glitchy. Things that would never fly in a pay product, but I suspect for OSS, they were categorized as 'good enough' and lowered in priority for other bug fixes. Things like having to sometimes click on a tool 2 or 3 times before it registers or you end up applying the wrong tool. I haven't been using gimp for oh..say more than 2 years give or take, but the problem still exists.

Really? I've been using GIMP for over 2 years and I've never had that problem and I don't really understand how you know the bug still exists when you haven't used it for 2 years

I just tried Gimp 2.6 on windows XP SP3 and it worked perfectly fine, so I would be hard-pressed to believe that it still exists. If you can find a bug report or something similar that documents that behavior, then that would be different.

Just because you may not experience the bug doesn't mean it does not exist. I have seen it on Windows XP, Vista, and Mac 10.5.x across multiple machines on both platforms.

That's what's causing the bug. The Gimp is designed for a "focus-follows-mouse" environment, so in a "click-to-focus" environment, you need to click twice to select a tool: the first click brings the toolbox to the front, and the second click activates a tool. Three clicks is probably caused by clicking too fast: the first two are interp

That bug sounds like the issue with click-to-focus window managers like the one in Apple's X11 which don't properly track palettes. On these systems, the first click on the button gives the palette focus, the second click is delivered to the button. This is a bug with the window manager, not the GIMP, and the only place I've seen it in a widely-used window manager is OS X (where the WM is developed by a for-profit company).

Photoshop is glitchy as hell. In CS3, when you saved a web image it would wash out the colours due to using the wrong colour profile. This was a joke for such a major program. Fixed in CS4. CS4 crashes on me at least once a week, so much that now I expect it to crash anytime, and keep all my stuff saved.

I daresay there aren't as many open source software that are really polished compared to commercial software.Most OSS developers are happy enough to get things to the point of "mostly works" or more infamously: "WorksForMe".

Of course, the extra polishing or effort rarely goes to security, since real security rarely sells, you can get away with just _claiming_ bullshit like "Unbreakable" (like Oracle did).

But really, with commercial software, you're more likely (though still not common) to have some annoying

Actually I tinker out of some kind of bored interest. My need seemed to be that I wanted something to tinker with when I got bored. I stop whenever I feel like it. I use and make the software. You obviously don't know that much about what motivates OSS programmers.

OSS doesn't mean "nobody gets paid" it means "a product you are free to modify is superior to a product which is locked-down. Modifications which can be freely shared or incorporated back into the upstream are superior to modifications which are constantly repeated"

With "proprietary" software, the person who does the initial development is often the same as with OSS. But OSS can get those people and whoever else wants to scratch an itch.

It annoys the crap out of me that I can't, for example, write improvements to the software on my set-top box. People essentially turning away free labor because hardware manufacturers can't decide what it is they're selling.

Open Source Software != Free software. This concept you adamantly describe is not about what you get paid. Its that when you purchase/acquire a program you get the whole program source code and all. This allows you to build on that software or ensure the software is safe from security holes. If the developer wants money then that is his choice and can be enforced, look at redhat. The GNU, for instance, makes specific references to ensure that it is possible.

It is unique because while one guy might act this way (finding a bug and stopping), there are potentially millions of others still looking for bugs. For commercial software, the few guys who might be looking for bugs will find them, get busy fixing them, then have to move on with adding features or something to keep the commercial product viable.

.

So actually, the point that you are implying (commercial software is better than OSS) is pretty far off the mark.

The problem is not OSS versus closed software, the problem is that inherently unsafe programming languages are still in use and that developers don't know enough or don't care enough about rigid input validation. I guess it's a bit unpopular to say this, but the world would be a better and safer place if the use of C and C++ was prohibited by law and halfway sound languages like Ada, Eiffel, Scheme, or Haskell were used instead.

This last update wasn't an issue, considering you can update then re-patch using the same software as teh previous version used, using a copy of the previous firmware to pull relevant files. I'm new to the iPhone scene, so have yet to see how bad the update/jailbreak process really feels.

This is strictly my opinion, but jailbreaking the 3.0.x iteration of the firmware on the 2G and 3G has been the easiest to jailbreak yet. A heck of a lot easier than trying to jailbreak firmware from the 1.0.x days.

Ever since the release of the iPhone, I've been quite astounded at what people think of the jailbreak process. Yes, it's great that people can do stuff with their phone that Apple didn't intend. But... The existence of this means that your phone has a security hole.

I seem to recall that the original jailbreak technique was a specially-crafted TIFF image that caused remote code execution. So you'd just go to a website in Safari that had the image, and it would essentially root your phone.

No, that's not what he means. If you're causing memory corruption because of unsanitised inputs, it's only a matter of time before a method is discovered to inject something malicious into that memory space.

Out of curiosity, do you know what the bug is? It's pretty obvious - %n is a printf format symbol that says "treat the next parameter as int*, and write the number of characters printed thus far to that location." Because of the way most C libraries work, this will work even if there *is* no next parameter. The next thing on the stack (or in the next argument register, depending on platform and calling convention) might be something highly valuable, like the function's stored return address. Even if it's no

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.

Not exactly. This is a problem in some languages, but a trivial one. The problem comes from the way variadic functions work in C. Consider something like:

printf(unsafe);

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

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 im

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.

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.

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 substitut

Since the flow of problems coming from C pointers and arrays seems never ending...

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

Alan: What about the claim that a jailbroken iPhone could crash cell phone towers--has anyone ever looked at the security of the software running cell phone towers?

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.

As an aside, that was another reason I liked the injection method of testing SMS messages locally. 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!

"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

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.

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?) hav

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.

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,

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.