Because “we don’t need more vulnerabilities, the ones we’ve got are perfect” is good marketing for the ones you’ve got and are trying to sell?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Zerodium Temporarily Stops Purchasing iOS Exploits Due to High Number of Submissions
- Thread starter MacRumors
- Start date
- Sort by reaction score
The android vulnerabilities may be more money and worth it due to the potentially bigger payload due to market share.
When you say "poorer software quality", are you referring to questionable design decisions (the iOSification of macOS), lack of year-over-year improvements, or more numerous bugs?
Can someone tell me what all these vulnerabilities are? If there are that many you think we’d be constantly hearing stories about iPhone and iPad customers being compromised.
I don't think it's a matter of bidding. Exploit finders seek out Zerodium because they pay more than Apple's bounty. Apple would have to pay out larger bounties to attract the type of person who seeks out Zerodium.
I think this happens on all the mobile platforms. I don't think this is an iOS only issue.
Zerodium publishes their prices. All Apple needs to do is to offer higher prices for similar vulnerabilities.
Apple could easily fix this problem if they would allocate 1 billion dollars per year to the most important vulnerabilities. Try to outbid this Zerodium.
Well, if there are so many vulnerabilities in iOS that can be sold to law enforcement they shouldn't need to request that Apple provide a back door.
Considering how much their software quality has dropped in the last 12 months, this doesn't come as a big surprise. Their last big releases were an embarrassment.
Get you friggin act together, Apple!! You're squandering your technological treasure here.
Get you friggin act together, Apple!! You're squandering your technological treasure here.
Yes, taking my data and selling my data is the same because in both cases they have my data.
And no, Apple doesn’t do the same thing.
Everyone always pats apple on the back for the long updates they provide and don't even think of the reason for that. They have no choice because of the walled garden that has everything pretty much conjoined in the iOS. Security problem with mail update OS update. Security issue with safari, once again wait on an OS update. iMessage the same and the list goes on. Android is different in that even core apps can be update through the play store. Parts on the Android OS itself can be updated through the play store as well. It's a big reason why they don't have to push out updates all the time on android. That's why I laugh a lot when they parade this nonsense of update comparisons around.
And if you wanted to suppress the acquisition price of whatever you’re trading in, what would you do?
[automerge]1589499121[/automerge]
Sure, if they had competition on the resale side. But as it stands they have an established customer base and virtually no competition. So if they can suppress their acquisition costs, and have no pressure on resale price, PROFIT.
Also, this business model is just evil.
Last edited:
iOS is still the world's most advanced and secure operating system in the entire world. Nobody can convince me otherwise. We get always best-in-class security and privacy protection when we choose an Apple device.
For a company as deep pocketed as Apple, which claims security as a key USP, this is dropping the ball really bad. Indeed it’s almost as if they’d rather not know about the issues, so they don‘t have to fix them??
As an iOS user, and an Apple shareholder, I’m really not impressed at all!
The only good side of this story is that because the highest bidder has in effect stopped bidding, Apple might now see a few more of the vulns.
How many radars have you filed?
How many responses did you get?
How many problems were fixed?
[automerge]1589512841[/automerge]
A problem Apple could solve through sheer application of cash -- through bug bounties or hiring security engineers (and not rushing OS releases).
[automerge]1589513192[/automerge]
Qubes for the unironic response.
Last edited:
Unless if some Apple engineers with internal knowledge sell the security bugs via their friends to Zerodium, instead of reporting them internally or fixing them.
I've grown so weary of the never ending stream of "...possibly gain root access...execute arbitrary code... FIX: improve bounds checking" security issues/resolutions we see documented in security bulletins, changelogs, etc.
I've been in software development for 40+ years. Looking back to the earlier days [puts on dinosaur mask], I used systems such as HP3000 and Burroughs that had hardware stack architectures which enforced separation of code and data. Executing "arbitrary code" was virtually impossible. And, by default, the HLL compilers automatically interjected bounds checking code everywhere there was an array/buffer access. The hardware facilitated optimized execution of those bounds checks. Back then there was some discernible execution slowdown caused by the bounds checking but nobody questioned the need for it. Nowadays, with modern hardware, the impact of doing so would be absolutely negligible. But yet, for the most part, it isn't being done.
Furthermore, many of the elements of the modern OS and the apps running thereon revolve around interpretive operations such as parsing URL strings and acting upon them. That has to be done carefully and methodically with robust prerequisite checks to prevent unintended and/or risky operations. But typically those interpretive operations are done hastily and sloppily. I have had to analyze regular expression pattern matching strings found in code that were so long and complex that it was tough to maintain my sanity.
Back in the day, we learned a principle called KISS which I'm sure is still taught in school. But with today's aggressive software development schedules, overly ambitious feature sets, and usually poorly managed tech workforce, that principle has been largely forgotten. The reality is that complex problems can usually be solved elegantly with technically straightforward, durable, and maintainable approaches. To devise such an elegant approach requires a solid up-front analysis and design by senior level staff members and will consume (as it should) a substantial portion of the total time required to reach the deployment finish line. With agile development methodologies, I've found that the overall high level design never gets enough attention and is seldom refactored. So suboptimal, overcomplicated, and inherently deficient approaches remain in place until an inevitable rewrite, while a seemingly endless parade of tweaks and kludges is necessary to eventually result in a functional work product. Regardless of what QA processes are involved, that "functional" work product will remain insufficiently robust, overcomplicated, and suboptimally maintainable, as it will have been irreversibly hobbled by the poor design. And when additional staff is onboarded for that kind of project (during initial development or maintenance phases), it will take substantially more time to get them productive and fully embracing the design, such as it is, and to comprehend the cumulative effect of the parade of tweaks and kludges. While top tier developers should be able to embrace a solid, elegant design quickly and hit the ground running within a couple of weeks, it could take months of struggling for those same developers on projects which were started with a weak design and suffered a long history of agile remediation. To make matters worse, the fringes of projects are often worked on by lower tier developers who will struggle even more with all of the things that aren't intuitive (and they shouldn't be blamed for that). The confluence of these factors inevitably results in a jumble of code that only gets more jumbled over time, and this holds true even if the end result visible to the user seems to function properly -- perhaps with some set of bugs fixed -- and looks nice.
Even having come from the dinosaur era, I think C and C++ are rather primitive and arcane. They are fine for low level OS code and utilities but there needs to be something far better. I don't know what that something is. And for those with perl, php, ruby, javascript, etc. on their tool belts, I must add that not everything is a web page. And for those wearing Java on their tool belt, well, Java isn't the answer, either.
Compared to the primitive application software and operating systems of days past, modern offerings are much more interactive, well connected, and beautiful. But in many ways, the foundations are much weaker now than in the past. Furthermore, mid- and upper-level development managers are less competent now than in the distant past, at least based on what I have experienced.
I will end my rant now so I don't cause a buffer overflow and accidentally execute arbitrary code on a MacRumors web server.
I've been in software development for 40+ years. Looking back to the earlier days [puts on dinosaur mask], I used systems such as HP3000 and Burroughs that had hardware stack architectures which enforced separation of code and data. Executing "arbitrary code" was virtually impossible. And, by default, the HLL compilers automatically interjected bounds checking code everywhere there was an array/buffer access. The hardware facilitated optimized execution of those bounds checks. Back then there was some discernible execution slowdown caused by the bounds checking but nobody questioned the need for it. Nowadays, with modern hardware, the impact of doing so would be absolutely negligible. But yet, for the most part, it isn't being done.
Furthermore, many of the elements of the modern OS and the apps running thereon revolve around interpretive operations such as parsing URL strings and acting upon them. That has to be done carefully and methodically with robust prerequisite checks to prevent unintended and/or risky operations. But typically those interpretive operations are done hastily and sloppily. I have had to analyze regular expression pattern matching strings found in code that were so long and complex that it was tough to maintain my sanity.
Back in the day, we learned a principle called KISS which I'm sure is still taught in school. But with today's aggressive software development schedules, overly ambitious feature sets, and usually poorly managed tech workforce, that principle has been largely forgotten. The reality is that complex problems can usually be solved elegantly with technically straightforward, durable, and maintainable approaches. To devise such an elegant approach requires a solid up-front analysis and design by senior level staff members and will consume (as it should) a substantial portion of the total time required to reach the deployment finish line. With agile development methodologies, I've found that the overall high level design never gets enough attention and is seldom refactored. So suboptimal, overcomplicated, and inherently deficient approaches remain in place until an inevitable rewrite, while a seemingly endless parade of tweaks and kludges is necessary to eventually result in a functional work product. Regardless of what QA processes are involved, that "functional" work product will remain insufficiently robust, overcomplicated, and suboptimally maintainable, as it will have been irreversibly hobbled by the poor design. And when additional staff is onboarded for that kind of project (during initial development or maintenance phases), it will take substantially more time to get them productive and fully embracing the design, such as it is, and to comprehend the cumulative effect of the parade of tweaks and kludges. While top tier developers should be able to embrace a solid, elegant design quickly and hit the ground running within a couple of weeks, it could take months of struggling for those same developers on projects which were started with a weak design and suffered a long history of agile remediation. To make matters worse, the fringes of projects are often worked on by lower tier developers who will struggle even more with all of the things that aren't intuitive (and they shouldn't be blamed for that). The confluence of these factors inevitably results in a jumble of code that only gets more jumbled over time, and this holds true even if the end result visible to the user seems to function properly -- perhaps with some set of bugs fixed -- and looks nice.
Even having come from the dinosaur era, I think C and C++ are rather primitive and arcane. They are fine for low level OS code and utilities but there needs to be something far better. I don't know what that something is. And for those with perl, php, ruby, javascript, etc. on their tool belts, I must add that not everything is a web page. And for those wearing Java on their tool belt, well, Java isn't the answer, either.
Compared to the primitive application software and operating systems of days past, modern offerings are much more interactive, well connected, and beautiful. But in many ways, the foundations are much weaker now than in the past. Furthermore, mid- and upper-level development managers are less competent now than in the distant past, at least based on what I have experienced.
I will end my rant now so I don't cause a buffer overflow and accidentally execute arbitrary code on a MacRumors web server.
Last edited:
There will always be bad actors, not acknowledging that is naive. I rather have security by design. It's not for nothing that Federighi has upended the development proces for iOS after the version 13 debacles.
[automerge]1589524881[/automerge]
'quietly'? They are well-known, and advertise. They benefit from the spotlight, it's just a normal company. Don't act like this is some shady deep web thing all of a sudden. They just got an influx of materials now that people are bored.
I’d blame modern day DevOps environments for this happening in the first place. Automated testing, poor timelines, rapid deployment and development. It’s a frigging rush-the-code-our-the-door factory where security is an afterthought handled by software engineers that might not know a lot about infrastructure or security. Horrible!