Getting users to grant permission for just about anything is pretty easy.

Not dialing. If the user is presented with a dialog in the middle of an app run asking to dial some number they have no idea about, very few people will agree to that... context is very important.

Similarly just running some to-do list app and out of the blue it asks to use the camera? Not that many people would agree to do so, even those who are pretty naive.

The researchers wrote a fairly in-depth paper on the attack which can be read here..In the case of tweets, they make use of "private API's" to avoid notifying the user:.

Which does not work in iOS6, as mentioned by the article itself (it notes that attack only works in iOS5)

I attempted to get the dialing code as presenting working in iOS6. It segfaulted (and yes I did include the CoreTelephony framework, and used the -all_load linker flag). Since that's a bust how much other stuff in the paper does not work as claimed either?

Their POC app apparently performs the exact malicious tasks they indicate all without user notification.

They CLAIM it does, this is what requires proof. The paper is just providing some means how it might be done, not showing that it works.

Real proof would be a buildable, runnable project that did all of the things they claim. Since they are already providing source code in the paper why would they mind releasing a project... well where is it?

Oh really? So how about those millions upon millions of IPhone 3 / 3G and IPad 1?

Very few, in any kind of access logs or app statistics from analytic libraries those devices fall way below 1% of devices.

Not everyone in this world is a wealthy American that would throw away a perfectly fine three year old phone or tablet

I didn't throw mine out. It just has more limited use than the newer devices. No way would I buy new apps to run on it, it just runs some apps that I bought for it a while ago, or works for browsing (or a photo frame).

If Microsoft behaved the way Apple does wrt. updates

Which they do - didn't you know?

Posting tweets, I know for a fact is the same as SMS and Email in that it's a sheet operated by the system, you can't touch it from the app.

The worst possible thing I thought, would be if it could actually dial out without the user giving permission. So I embedded the code they gave in the paper in a sample app, with the CoreTelephony framework (and a number of other frameworks/libraries for good measure) added:

      void* h = dlopen("CoreTelephony", 1);
      void (*CTCallDial)(NSString*)=dlsym(h, "CTCallDial");
        CTCallDial(@"A Valid Phone Number here");

Segfault, no dialing. So THAT does't work either.

I didn't test some of the other things but I really wonder how much they ACTUALLY tested on iOS6. What a shame that it's so easy to fool so many people like yourself just by throwing around terms like "private API" and some semi-plausable looking code...

I'm sure some of it would still work on iSO6, but it seems none of the really dangerous ones does. So my stance is still that they didn't really break out of the sandbox, they are just building some nice looking castles and pretending they are real.

Is it TOO MUCH TO ASK that some independent verification take place on fantastic claims like these?

Don't bother, SuperKendall is a Benghazi truther.

Truther is a term used for some idiot who believes 9/11 was the result of aliens, bad diarrhea or a massive government conspiracy by a government so stupid it sent machine huns to mexican drug lords just to see what would happen.

With Benghazi, it was obvious it was a terrorist attack from the start but the government blamed a video for scores of deaths and embassy attacks. Every reporter on earth along with the public now knows it was a terrorist attack, and that the state department knew it was at the time. Most people now know also they let people die there because they didn't want any hiccups in the undergoing operation to ship 400 Libyan missiles to Syria... but that's a story for another day.

It says much that your weak attempt at spin comes not from anyone real, but a nameless AC who tries to pretend something that everyone knew long ago was discredited... and as I said the guy is out of jail so it's pretty obvious he was just in jail when it was handy. Which he says himself...

Post away AC. But your attempt to deflect real truth with a weak protest that the most obvious thing is not true, holds little weight among people who can think and/or read.

Story about the arrest.

Note they claim his video ignited muslim protests, when in fact it was a coordinated attack on embassies including Benghazi...

His video had nothing to do with it, but he made a great scapegoat for the embarrassed state department. Now that we know it was terrorists and not a protest, he's out of prison. How odd.

The U.K. thinks it can join the fascism club just because it smashes a computer or two?

The U.S. arrested a filmmaker a year ago just for making a movie. Are those reporters in jail? Don't think so. You're going to have the step up the game U.K. to join the big boys.

Bonus points for all the cameras though.

Good point. I guess that this never happened

Not in iOS6 it didn't. Apple started taking user security much more seriously in iOS6, anticipating a potential for such attacks. I always thought prior to that it was kind of nuts you could access the address book without permission - now you cannot.

Ah, the old "That vulnerability is completely theoretical" defense.

And yet it turns out to be true. The vulnerability is not real, only a theoretical possibility that relies on breaking the sandbox, which they have not done (using private API calls is not breaking out of the sandbox). You don't need to do anything sneaky in an app to do private API calls, but it remains true the sandbox is pretty secure and stops most REAL attacks.

You are crazy if you are more worried about a possible attack via an unknown hole in the sandbox, vs. very real attacks that are happening every day on Android...

There was a time you could jailbreak via pdf or just visiting a webpage.

The only reason THAT worked is because the Safari javascript engine has native code JIT that an app cannot use. And now you know why...

So still true that you cannot jailbreak out of an arbitrary app, only ever from system apps that have elevated privileges, and then only once years ago...

Im not saying such an attack will never exist, it's just exceedingly unlikely and far more unlikely inside of an app you deploy to the store.

Private API calls are not breaking the sandbox.

Pretty much none of what they did that they consider an attack is possible in IOS 6., much less iOS7 which is on the eve of release - and some 95% of active devices are running iOS6 now.

I can break into Windos95 pretty easy too. But who cares and why would it warrant an article? The whole paper really boils down to "sometimes the app reviewers do not run an app for long" which is news to pretty much no-one.

I looked for the paper but could not find the link. Thanks for the extra info.

As I thought, they did not break the sandbox at all. Attacks that don't work in iOS6 are irrelevant at this point...

It's totally sensationalized. It remains true there's no way a real app can "wreak havoc" even if you inject code later.

You can't attack other apps?
So how does jailbreaking work?

Jailbreaking works by attacking the device over USB, generally the update mechanism - not something you can do through an app.

I can totally see getting an app through the submission process that does something a bit sneaky. Sometimes the app reviewers hardly look at a thing (though sometimes they look very carefully, it just depends on the reviewer).

But the claim the app could "wreak havoc" needs some proof. They said:

a Jekyll-based app can successfully perform many malicious tasks, such as posting tweets, taking photos, sending email and SMS, and even attacking other apps â" all without the users knowledge

Every single one of those, requires permission from the user to do - posting tweets an app cannot do directly, it brings up a sheet. Same thing for email/SMS. Taking photos requires an OK from the user to access the camera. You cannot "attack other apps" because of the sandbox.

Extraordinary claims, like a complete breaking of the sandbox, require more proof than they have presented. I would bet they are saying they THEORETICALLY could break out of the sandbox but have absolutely no actual working exploits that go outside of existing user permissions and the sandbox...

For a napkin calculation you can probably keep a 100 mph average with a 150-200 mph train, so around 300 miles starts being the threshold where you'd rather fly than go by train. New York - Washington DC and LA to San Francisco seem like reasonable HSR distances

Taking a train to Amsterdam from Berlin was significantly slower than flying, even dealing with airport security. It's 406 miles...

The thing you are not factoring in is other stops. Even in an express train you may have a few stops, or points the train has to slow.

It is a bit more comfortable, I'll grant that! I myself will tend to drive anywhere within about 500 miles rather than fly, even though it's a lot slower.

Again though, even if it's comparable the thing about the hyper-loop is that it could blow both plane and train out of the water in terms of convenience and time. The things we would learn from building it could have enormous value.

When I first read about it I just figured it was a stupid wacky idea. But serving short runs as he says, that has a lot of value and beats out trains in every metric including cost! No way a train is going to get finished anyway, so why not just switch to the hyperloop?

Other than up to $5,000-$10,000 in federal and state tax credits

The point is the Telsa is the first electric car that does not NEED to subsidies to sell, not that they do not exist - people would still be buying the car without those credits.