Browser-Based iOS 9.1/9.2 Jailbreak Wins $1M Bounty, Will Be Sold for Corporate and Government Use

[SirCheese]

No, because this is all just publicity stunt. They don't actually have the exploit.

Because you possibly have data to prove otherwise? No? Thought so.

 

[CalWizrd]

What gets me is when people can't understand english and jump to inaccurate conclusions. I don't blame Apple for break ins or car manufactures for theft. I do expect reality to live up to the marketing message. In both cases it does not.

When a car manufacturer sells me a car with a lock and said lock can be opened by almost anyone in a few seconds, then yes the manufacturer needs to catch some heat for thefts. Not be blamed, but they should catch the heat.

When a tech manufacturer sells me a secure product and said product is capable of being broken into just from visiting a web site, then they need to catch the heat. Not be blamed for the break in, but catch the heat.

So yes, I am happy that someone put a dent in Apple's marketing message, because without said dent causing a lot of heat Apple will not improve to the level that I expect.

It's pretty clear that there is much you don't understand about software.

First of all, it's absurd to even compare a "lock that can be opened by almost anyone in a few seconds" to a complex software hack that required a $1,000,000 bounty for a group of unknown size to accomplish in an unknown amount of time.

Additionally, as the total number of lines of code increase in any system, the subtlety of bugs/vulnerabilities becomes excruciatingly more difficult to isolate and fix. Take it from one who spent a lifetime developing software.

Sure, it would be great to be able to spend a ridiculous amount of time with any software release trying to track these things down, but then you'd never get new software.

Apple will find the issue and fix it. In the meantime, try to get your panties out of a wad.

 

[C DM]

What gets me is when people can't understand english and jump to inaccurate conclusions. I don't blame Apple for break ins or car manufactures for theft. I do expect reality to live up to the marketing message. In both cases it does not.

When a car manufacturer sells me a car with a lock and said lock can be opened by almost anyone in a few seconds, then yes the manufacturer needs to catch some heat for thefts. Not be blamed, but they should catch the heat.

When a tech manufacturer sells me a secure product and said product is capable of being broken into just from visiting a web site, then they need to catch the heat. Not be blamed for the break in, but catch the heat.

So yes, I am happy that someone put a dent in Apple's marketing message, because without said dent causing a lot of heat Apple will not improve to the level that I expect.

Car locks can be opened by pretty much anyone in just a few seconds?

 

[nt5672]

It's pretty clear that there is much you don't understand about software. . . . .

Just so wrong. Yes developers will all tell you that software has to have bugs, but that's just hype to meet marketing deadlines. Its about priorities, hiring smart people (not the cheap ones), and getting it right.

Just so you know about my understanding of software, the most sensitive software I was responsible for included in the failure analysis the deaths of 30 to 40,000 people and it was not military. No we did not take years to make changes, we constantly evolved the software with weekly or daily changes as needed. These changes were to support changing requirements (newly found information about the environment the software worked in) and we rarely found bugs because the process was built to eliminate bugs before deployment. Correct operation was considered important and the software was engineered that way.

I also have other software that operated for about 15 years before the first bug was found. It was not a logic bug, but a copy paste configuration bug for a rarely used option.

Ever wonder why we still see buffer overflow bugs in Apple software updates (if you bother to read the security release notes). The utilities to scan for and report buffer overflow bugs have existed for at least 15 years because they were a big topic during Y2K discussion. Now ask yourself why Apple has not applied these utilities to its own software or to the open source software they use? Answer, because it is not yet important to them. In fact there are firms that will audit your whole code base for these and other security problems. Wonder why Apple is not using them?

Bugs are not just a normal result of software development, they are only a result of software development processes which have been compromised for cost, for delivery date goals, and by poor management. Bug free software development is an attitude. That attitude starts with the fact that there are no excuses for bugs. Unfortunately, that attitude rarely exists.

 

[CalWizrd]

Just so wrong. Yes developers will all tell you that software has to have bugs, but that's just hype to meet marketing deadlines. Its about priorities, hiring smart people (not the cheap ones), and getting it right.

Just so you know about my understanding of software, the most sensitive software I was responsible for included in the failure analysis the deaths of 30 to 40,000 people and it was not military. No we did not take years to make changes, we constantly evolved the software with weekly or daily changes as needed. These changes were to support changing requirements (newly found information about the environment the software worked in) and we rarely found bugs because the process was built to eliminate bugs before deployment. Correct operation was considered important and the software was engineered that way.

I also have other software that operated for about 15 years before the first bug was found. It was not a logic bug, but a copy paste configuration bug for a rarely used option.

Ever wonder why we still see buffer overflow bugs in Apple software updates (if you bother to read the security release notes). The utilities to scan for and report buffer overflow bugs have existed for at least 15 years because they were a big topic during Y2K discussion. Now ask yourself why Apple has not applied these utilities to its own software or to the open source software they use? Answer, because it is not yet important to them. In fact there are firms that will audit your whole code base for these and other security problems. Wonder why Apple is not using them?

Bugs are not just a normal result of software development, they are only a result of software development processes which have been compromised for cost, for delivery date goals, and by poor management. Bug free software development is an attitude. That attitude starts with the fact that there are no excuses for bugs. Unfortunately, that attitude rarely exists.

OK, I read everything you stated. I'm not going to go into any detail about my own development experience... suffice it to say I have developed software for IBM, Apple, Citibank, UBS, ... in a multitude of low-level and high-level languages, over a 49 year career. Been there, done that.

My opinion on your essay...

It's pretty clear that there is much you don't understand about software.

 

[nt5672]

Car locks can be opened by pretty much anyone in just a few seconds?

Good catch. That should read " . . . anyone with about $500 and an internet browser."

I did some work a few years ago in the oil sector in Houston. We were given laptops and told very clearly that if we left the laptops in the car trunk while we were in a restaurant that the chances of the laptop being stolen were so high that the company would require reimbursement for any loss. IIRC they told us that 100s of laptops were stolen in the previous 12 months. It happened to some of the project team members previous to my arrival.

In the security briefing they showed us a video. The thief would walk up to the trunk with apparently a device in their pocket, the trunk would pop open, they would remove a briefcases, close the trunk, and walk away. It looked just like they were the auto owners. The people that got had, did not even know until they reached their hotel.

To me this means that the cars basic functionality is comprised and the car manufacturer should not be blamed for the specific theft, but surely take the fallout for poor design and selling a car that does not meet the buyers expectation.

 

[C DM]

Good catch. That should read " . . . anyone with about $500 and an internet browser."

I did some work a few years ago in the oil sector in Houston. We were given laptops and told very clearly that if we left the laptops in the car trunk while we were in a restaurant that the chances of the laptop being stolen were so high that the company would require reimbursement for any loss. IIRC they told us that 100s of laptops were stolen in the previous 12 months. It happened to some of the project team members previous to my arrival.

In the security briefing they showed us a video. The thief would walk up to the trunk with apparently a device in their pocket, the trunk would pop open, they would remove a briefcases, close the trunk, and walk away. It looked just like they were the auto owners. The people that got had, did not even know until they reached their hotel.

To me this means that the cars basic functionality is comprised and the car manufacturer should not be blamed for the specific theft, but surely take the fallout for poor design and selling a car that does not meet the buyers expectation.

So is that actually happening and decently often enough too, or it was a dramatization to basically make people carry their stuff with them because, for example, many just run in somewhere and don't lock their cars and someone gets their stuff that way or they leave their stuff in plain sight and someone breaks in and gets it?

 

[nt5672]

. . . .
It's pretty clear that there is much you don't understand about software.

Its not about understanding, it is about expectation. If you expect the software to have bugs, then it will have bugs. Bugs happen because the development team does not understand the problem space well enough. So yes, there can be bugs because the code's real use was not well anticipated. With regard to security bugs, that is now or should be a well understood environment if the correct people are involved.

 

[CalWizrd]

Its not about understanding, it is about expectation. If you expect the software to have bugs, then it will have bugs. Bugs happen because the development team does not understand the problem space well enough. So yes, there can be bugs because the code's real use was not well anticipated. With regard to security bugs, that is now or should be a well understood environment if the correct people are involved.

I'll tell you what...

If you randomly select any piece of software, any, that consists of more than 100,000 lines of code, I'll bet any amount you care to name that it contains some logic path that was never tested that will lead to an incorrect result or crash. I don't care if it's from the NSA, or the space program, or the NYSE, or ...

My expectation when developing software was to deliver the most efficient, thoroughly tested, user friendly system humanly possible. To think for a moment that it would be totally free of any logic errors or vulnerabilities is simply naive, not pessimistic.

 

[nt5672]

I'll tell you what...

If you randomly select any piece of software, any, that consists of more than 100,000 lines of code, I'll bet any amount you care to name that it contains some logic path that was never tested that will lead to an incorrect result or crash. I don't care if it's from the NSA, or the space program, or the NYSE, or ...

This we agree on.

My expectation when developing software was to deliver the most efficient, thoroughly tested, user friendly system humanly possible. To think for a moment that it would be totally free of any logic errors or vulnerabilities is simply naive, not pessimistic.

And you make my point perfectly, no where in that paragraph did you say "bug free." You don't test for "bug free", you design for it. You have to question everything in order to get bug free. And your right, most teams consider that being a pest and get that person off the team because in their mind it is not efficient, which was your first listed priority.

 

[C DM]

This we agree on.



And you make my point perfectly, no where in that paragraph did you say "bug free." You don't test for "bug free", you design for it. You have to question everything in order to get bug free. And your right, most teams consider that being a pest and get that person off the team because in their mind it is not efficient, which was your first listed priority.

Even if you design for it and have it as your priority and only have that mindset it still won't change the reality that more often than not there will still be some flaw somewhere.

 

[CalWizrd]

Of course you design for bug free. If you think your intellect and skills are such that you can achieve that goal, in any project of large magnitude, you're in for a rude awakening down the road.

Good luck in your quest!

 

[Eraserhead]

This we agree on.



And you make my point perfectly, no where in that paragraph did you say "bug free." You don't test for "bug free", you design for it. You have to question everything in order to get bug free. And your right, most teams consider that being a pest and get that person off the team because in their mind it is not efficient, which was your first listed priority.

Should we get software companies to follow OWASP? Yes.

Will we fix all security problems in code? No.