Those who fix the bug and those who issue payment are likely in two different groups with two different sets of motivators. Not excusing but explaining.
A company sufficiently large enough for such an amount to not be a big deal will have a money disbursal process nobody understands enough to make a one time transaction of that size in a reasonable amount of time.
Maybe a company so large it can’t track its own finances is too large to be responsible for its obligations and should be held to standards at least as strict as its less capable business and human peers. And I’m an Apple fan to be clear. But their wealth is the opposite of an excuse.
It isn’t that finances aren’t tracked. They are tracked and audited and the audits are audited and there are many safeguards in place so that money doesn’t leak out and the knowledge for that operation is specialized, so much so that entire departments handle only part of the process and can’t just talk to one another due to the “segregation of duties” the auditors want. A company that decided to incentivize bug bounty like Google got support for the program on high and all the wheels of the org went to work to create policy, procedure, forms, auditor review, SARBOX compliance, etc and payouts will move like any other invoice. A company where some mid rank sees a need for such a program but doesn’t get full organizational alignment will be stuck with a pre-broken unreliable process.
That's still an organization that's too large or mismanaged to be trusted. We trust people who are capricious with their personal finances far less. A large organization with wealth impossible to humans but systems failing them and everyone else who depends on it... is a large corporation with wealth that has no excuse for not solving it.
You state this confidently but I don't see why it's true a priori. I don't see a strong correlation between Apple's cash on hand, assets or market cap and the severity of a zero day in Mail.app.
The better comparison is active users, weighted according to how many apply automatic updates. The vulnerability half-life probably isn't as devastating as you might think it is since Apple has centralized control to push out updates, limited only by users deliberately not installing them.
I would consider a vulnerability in OpenSSH to be far more economically devastating, and there isn't even a company with a market cap behind that software.
Then I'm sure you can easily see why Apple having money matters. openssh users may be damaged and yet there isn't an apparatus in place to reward those who can provide value. What a shame, but who is confused?
Who is wondering why Patreon and a blog post isn't sufficient to facilitate value transfer in metaphorical openssh scenarios?
With the Mail.app pegging their CPU to 100%, those three people are unlikely to notice. Frankly, it's unlikely for the attacker to be able to do anything either, aside from force-terminating Mail.app.
(Disclaimer: I want to like Mail.app, but I don't need another fan in my office.)
I'm using Mail.app since 2007 when i switched to Mac and never had issues other than a couple of times around 2009-10 when it had sync problems with Gmail. ¯\_(ツ)_/¯
Wow, Mail.app has more market share than Outlook. I'm pleasantly surprised. Ditto for GMail only having ~30%.
Although,
> Since determining the client in which an email is opened requires images to be displayed, the data for some email clients and mobile devices might be over- or under-represented due to automatic image blocking.
Outlook doesn't display external images by default, while Mail.app does, so....
Also, I assume there's a different demographic that uses Mail vs Outlook. Those different demographics will receive different types of email, which may or may not be represented differently by companies who use Litmus tracking which is how this data is being collected.
It does. I even provided a citation several weeks ago in another thread, though a quick Google search seems to bring up ample support of its own.
Like me you may have disabled it and forgotten. Whenever I get a new laptop at work I tend to go through and change all the defaults, such as reverting to plaintext composition, and habitually disable external image loading as part of the process.
The iPhone Mail app may have saner defaults, however, but I don't have an iPhone and have never used its e-mail client.
I'm surprised how high the iPhone share is. Specifically in light of it usually being stated in any thread discussing apple and regulation that Apple do not have anything close to a controlling share of the market
Things may have changed, but to my knowledge iDevices have traditionally been disproportionately represented in many metrics due to getting heavier usage from their owners. Android wins by far in sheer units sold and in use, but iOS users use their devices so much more heavily and frequently that the average iOS user has a larger usage footprint than their Android counterpart.
The feature accretion and default layout redesigns have increasingly become a headache, but Mail.app still seems like the spiritual successor to Eudora, which may have remained the most popular desktop e-mail GUI if Microsoft hadn't leveraged their monopoly in the business workstation and LAN markets to push the adoption of Outlook. I use mutt for personal e-mail, but prefer Mail.app for work.
What’s right with it? I tried it a few times and always returned to web-based clients (on desktop) and third-party apps (outlook, gmail, protonmail) on iOS.
What web-based client will allow you to read email without an Internet connection in Safari?
What marginal advantage does a third-party iOS client provide, that outweighs the risks of installing another app that is going to spy on me, have weaker integration with the OS and force me to relearn every new UI design language they come up with that in no way resembles the rest of the OS or its function and behavior?
That’s not what the original question was. It was:
> what’s right with [Mail for iOS]
So me implying that reading mail offline is one thing that’s right with it is not invalidated by the fact that it’s not a universally demanded feature (and yes, it has helped me many times, even recently).
Do you really need to remove that feature to build a “better” email client? What exactly is the tradeoff you see?
I have an issue where it always thinks a couple of accounts are offline. I have to click the squiggle for it to download those accounts. Every restart I have to do the same thing.
That’s really annoying. I self host my email so haven’t seen something like that for a while. Last time I did it was I think related to some sort of contradiction between my port number selection and the encryption type for either the incoming or outgoing server but I can’t quite remember.
I tried it for a year for a Gmail-backed account. My complaints are:
1. Searches in Mail are slower and less accurate than web-client searches.
2. No access to Gmail filters.
I don’t blame Mail for this, but it is a reason I returned to the web client.
3. Applying labels is harder in Mail. Maybe I missed it, but it wasn’t as easy to apply multiple labels or to apply a label to a draft email.
4. I couldn’t find a Send and Archive feature in Mail.
Basically, I like the Gmail experience. I hate Google, and I’d love to move away from them. I have for search, maps, mobile OS. For calendars, contacts, and mail, Google has the features I like.
Agree with your points. My use case doesn’t involve gmail so can see how that complicated things especially from a UX perspective. I wish IMAP/standards had more of a say in email like they did (sort of) for web.
Thunderbird would be hot garbage even if it didn't constantly phone-home. I'd like an IMAP client that connects to my IMAP server and nothing else (connecting to outside web servers is okay if there are URLs in email and fetching remote resources is enabled).
A new Mac comes with something like 30 apps in the bar. I clicked and disabled every single one of them except Finder and used Safari to download another browser. If it was any other manufacturer, this mess would be quickly denounced by reviewers as crapware. But because it is by Apple, it is not a problem at all.
I am not expecting this to fix by itself. Maybe some major review blogs should first not parrot how magical the whole thing is and change the tone as such things are not only annoying, but also a security risk even if you don't actively use the app. I am not an expert on development for MacOS, but I would be surprised if there is no way to trigger the mail app from another app or a link. I just hope the bug is not exportable this way.
I assume you mean the Dock? I am with you there, on a new install of macOS I drag pretty much all their apps out of it (to be fair, I do the same thing on a new Ubuntu desktop install too...). Of course in a sense the Dock is an anachronism, I find it useful once in the while to drag a file onto an app there, but generally for launching apps I prefer Spotlight (actually Alfred).
Yes. The term dock came out of my mind, thanks. And yes, I emptied the dock. But obviously taking stuff off the dock is the minor inconvenience, but the idea that all this was preinstalled. Package managers and app stores should be where almost all of this belongs.
They lure you into using services you wouldn't use otherwise. I don't see how having FaceTime or TV is any different than when Google was bundling Google+ in Android.
I switched to it with the first release of OS X and have been pretty happy with it.
Amazingly I have a handful of messages from the late 70s (a couple of jokes and a couple of personal messages from friends who passed away young) that have survived the file format transitions since then but I couldn't imagine could appear in something like google or yahoo mail. TBH I haven't made that many transitions: EMACS (BABYL) on ITS, then TOPS-20; Interlisp and Smalltalk clients to Grapevine back end; Lispm to TOPS-20 back end; GNU Emacs (rmail?) to IMAP; and then Apple Mail (macOS and iOS) -> IMAP. Emacs is the most powerful but these days still hard to put in your pocket.
In general a web browser seems like the worst interface to most services and activities as the UI can't be dedicated to the task at hand; instead you have system UI, Browser UI and only then the application UI. And a lot of mouse activity is expected.
> Factoring is a financial transaction and a type of debtor finance in which a business sells its accounts receivable (i.e., invoices) to a third party (called a factor) at a discount.[1][2][3] A business will sometimes factor its receivable assets to meet its present and immediate cash needs.[4][5] Forfaiting is a factoring arrangement used in international trade finance by exporters who wish to sell their receivables to a forfaiter.[6] Factoring is commonly referred to as accounts receivable factoring, invoice factoring, and sometimes accounts receivable financing. Accounts receivable financing is a term more accurately used to describe a form of asset based lending against accounts receivable. The Commercial Finance Association is the leading trade association of the asset-based lending and factoring industries.[7]
This sounds like discounting a Bill of Exchange. Although the Bill of Exchange is drawn only against the delivery of a physical good, so this may be the difference between the two.
For example, let's say I own a sheep farm. I hire people to trim the sheep, and they produce a bunch of cotton. Without the Bill of Exchange, if I want to pay the people I've hired then I will need to ship this cotton to the spinner, who then ships the spun cotton to the weaver, who then ships the woven cotton to the clothier, who then makes clothes and sells it to a consumer. Only after this has happened can I pay my employees with the money of the paying consumer.
With the Bill of Exchange, a bill is created when I deliver cotton to the spinner. This bill will require the spinner to pay me for the cotton delivered in e.g. three months. I can then take this bill to someone who trusts that the spinner will pay me in three months and ask them to buy the bill at a discount, such that they are paid in three months (when the bill expires). I can then use the proceeds from the sale of the bill to pay my employees immediately. And the buyer of the bill earns a bit of interest because he pays less for the bill than he is paid at maturity.
Then Apple gets a reputation for refusing to pay, less folks look for and responsibly disclose vulns in Apple products, and their security posture as as whole suffers.
I think they're talking about the implication that if Apple don't pay, then the vulnerability is published.
I agree with you on a moral basis: what difference does it make if I get payed not to publish it vs. If I just publish it without even asking to get paid. But I'm not sure the law would agree with us.
I think, like in many legal matters, precedent and intent is key. Without ill intent there is no 'mens rea', or "guilty mind".
In this case you aren't just a vigilante targetting apple, there is established practice stretching decades.
There is also a duty on you as a security proffeshional, and there is a significant public interest in knowing about the vulnerability. So , most likely, it will be you doing your job.
All blackmail involves exposing something that someone doesn't want exposed - usually because the "something" is illegal. And yet, blackmail itself is illegal.
Most countries have a culture against whistleblowers, starting from childhood ("don't be a tattletale", "don't be a rat").
Can you explain it more?
What can make it a black-mail and why?
If there is no intent to abuse the bug when not paied then there is no additional threat there from simply notifying the company that some threat is already present. How it can become a black-mail?
So every report about discovered bug can be considered as black-mail?
If one discovers a bug, reports it to the company and says that after 3 months it will be public it's a black-mail too?
Or the payment request makes it different? And if person doesn't threat to publish the bug then it's ok?
Definition: Blackmail involves a threat to do something that would cause a person to suffer embarrassment or financial loss, unless that person meets certain demands. [0]
The longer a bug goes without being reported, the greater the potential impact. So not reporting a bug could be considered a form of abusing the bug. There's probably a moral obligation to report bugs promptly. Bug bounty programs that companies have are ultimately a reward for being a nice person, as opposed to being a payment for services rendered.
It's only blackmail if the threat is to do something you are not otherwise legally allowed to do. It is legal to, say, announce a zero-day on Twitter. Or to sell the zero-day to the NSA, or some grey hat broker like Zerodium.
Ok, you got me. But there must be more to the definition of blackmail than simply, pay me or else. If that were the definition, then everyone would be a blackmailer by virtue of "pay me for this or else I'll sell it to someone else," which is a "threat" we all implicitly make every day.
In the US, blackmail has a very specific meaning: it is a threat to inform law enforcement of a violation of federal law under demand of a thing of value. This would actually be extortion, which is defined in 18 USC 875(d):
Whoever, with intent to extort from any person, firm, association, or corporation, any money or other thing of value, transmits in interstate or foreign commerce any communication containing any threat to injure the property or reputation of the addressee or of another or the reputation of a deceased person or any threat to accuse the addressee or any other person of a crime, shall be fined under this title or imprisoned not more than two years, or both.
Bug bounty doesn't mean that the reporter is selling the bug they find for a reward. It's a gesture of gratitude from the company. This whole conversation is coming from a place of entitlement.
- Apple is a $2T company, that we trust with our data. That valuation is in part based on that trust. It's entitled of Apple to produce a product that contains shitty exploitable symlink handling and continue to have no meaningful repercussions (which is true in the industry as a whole).
If this was a bug in a small, under-resourced FOSS email client, or the exploit required many highly skilled person-years to find, maybe I'd feel differently.
In all likelihood, Apple would just refuse to play ball and tell them to go ahead and sell it to someone else if they're so confident. Zerodium and other markets already exist, and I don't think people at Apple lose much sleep over it. And you better hope you close that deal before Google Project Zero finds it independently and tells Apple for free. Plus the mere mention that a vulnerability exists in a specific piece of software may lead Apple engineers to finding and patching it before you can sell it. Give away too many details and it's burned.
People tend to vastly overestimate the economic impact of an exploited security vulnerability. A vulnerability which can be patched in a centralized manner has a low value half-life: it rapidly decreases in value over time. I would guess over 90% of active daily users of macOS already have the patch for this bug due to automatic updates. New buyers are essentially guaranteed not to have the vulnerability at all. The vulnerability would have to be absolutely catastrophic to be worth something, and in that case it would probably be used for targeted exploitation and burned after a short period of time.
Contrast with something like heartbleed, which is still around. That is a vulnerability with serious half-life and significant economic impact. The pool of available victims who can be exploited by heartbleed is nontrivial and persistent years later. Criminals will actually pay for something like that.
Did he phone them to check? I get a lot of fake invoices in my junk mail. I also know someone who lost £50k paying an invoice with bank details that had been tampered with by hackers. I hate phoning people but I always phone about invoices.
It's hardly surprising, you can run into memory corruption bugs just using desktop mail.app the way it's intended (there's been a bug that corrupts the account list for probably a decade which just hasn't been fixed.)
V1: “This file we downloaded for your convenience is requesting access to [folder]. This may harm your computer or expose you to unknown security risk. Are you sure?”
V2: “This file unexpectedly tried to access [folder].”
The exact same mechanism Apple already used with GateKeeper and FS access for programs at runtime.
Why does it need to be more complicated than that?
I don't use mutt with IMAP, so the last of those CVE issues that could have an effect was in 2005. And most of the rest of code execution bugs are related to IMAP. Pretty good.
Though I certainly shouldn't trust mutt to be bug free, given that it processes data that someone can send me freely. Gladly TUI programs are fairly easy to isolate in their own UNIX user account.
Thats what I thought first too (I am the author). And your guess for the reason is right. AppleScripts need to be stored in ~/Library/Application Scripts/com.apple.mail directory which is outside of the sandbox.
Please don't use "zero" and "vulnerability" in the same sentence, unless you mean a zero-day one. The author could have said "no click vulnerability" with the same meaning. Almost caused me a concern with that title! :D :D
Sorry about that. But thats the term what is used by Apple to these type of bugs: https://developer.apple.com/security-bounty/ ( Zero-click unauthorized access to sensitive data )
Apple puts rather extreme security effort into preventing iOS jailbreaks. They are pretty serious about trying to prevent data exfiltration from locked iOS devices as well.
They aren’t perfect but I don’t think it’s fair to say they don’t try.
I wouldn't call it extreme when there was a known public website allowing one-click jailbreak for good few months (not sure if it was actually ever patched or just the iOS version got eol)
It's unsurprising that the main vector for iOS jailbreaks would be through the web engine. The FreeBSD-based PlayStation 4 was also jailbroken via it's browser.
If you have written a hardened, safe browser engine then you are free to share it to the world, otherwise I wouldn't downplay their efforts.
> Apple puts rather extreme security effort into preventing iOS jailbreaks.
Yes, IMO their business model is more accurately described as “gilded cages/jails” than just general “gilded/good-appearing stuff”. They deeply care about the strength of their DRM — including at the expense of end-user security, eg. you can’t access the internet through the Tor browser installed the normal macOS way without macOS broadcasting that you used Tor Project products to Apple’s DRM servers.¹
> They are pretty serious about trying to prevent data exfiltration from locked iOS devices as well.
They definitely care about the appearance of trying to prevent that exfiltrating (they don’t publicly appear to help the FBI do it), but they don’t try hard enough to actually prevent it (including in situations were preventing exfiltration seems to have been proven possible, see nearby comment https://news.ycombinator.com/item?id=26667141).
¹Edit: ocsp.apple.com, enabling targeting of the people who need or want security the most.
To the people downvoting: I’m trying to make an evidence based refutation of the less supported speculation/assertions in the parent post. If you have counter-evidence or any reason to downvote other than fanboyism, please explain it so we or I can learn.
You don’t provide much evidence. Your second point is just opinion, “they don’t try hard enough.”
Your first point is intended to refute the effort put into stopping jailbreaking in iOS. The example you give is about privacy on Mac OS.
Last, accusing folks of being fanboys is a particularly weak argument. It says, if you don’t agree with me then your blind allegiance to a corporation renders you incapable of critical thought. Basically, if you don’t agree with me, you’re dumb. There is no practical engagement with that thesis.
A big difference is that the software running on Apple devices is less complex. For example there is significantly less hardware support. iMessage only talks to other iMessage instances (eg no browser support). There is only one web browser engine. Third party apps can't do JIT code generation. Older APIs are actively removed, breaking existing apps (vs providing backwards compatibility).
In general less complexity is better, but it also constrains things. For example it took until recently for third party iOS to be able to do NFC. Android had it since ~2012.
I am guessing they already knew GPRS/UMTS and data plans were the future, hence they invested in iMessage. MMS already had an expiration date. Quite sure they only added it because of the PR disaster it had become.
MMS could've been (and still kindof is AFAIK) the only way to send rich text semi-anonymously for money with carrier billing ie not requiring platforms, app stores, and sign-up. Is was also blocked on Android due to the Stagefreight bug. MMS was used at lot for ringtones and wallpapers before the Smartphone era.
I think there has been a lack of interest in smartphone NFC because iOS has no support for it.
For example, I have set up a tag to automatically connect friends phones to my WiFi network. You can also stick tags on places to trigger specific actions/mode/app: office, meeting room, car, bedroom.
Also one thing that could have been great to share pictures/files/urls with your computer or other phones: Android beam [1]. Sadly Google is removing it.
Sharing what's currently on screen (be it either a picture, a webpage or mean entire app) by touching two phones (Android Beam) was really convenient and ahead of its time. It is now being replaced by Nearby Share though, which works similar to AirDrop.
I like the way (I think) the grugq described it: out of the box iPhones are great with security, but Android allows you to build / get better yourself. See the copperhead project for example https://copperhead.co/android/
As far as what is feasible, Apple does a very good job with their iPhone/iPad security. With both hardware and software. You can read about it how it all works in their platform security guide.
On the Android side, Google makes good software changes to Android, but ultimately the security is dependent on the handset maker (e.g. Samsung) and SoC maker (e.g. Qualcomm). Security will vary between Android phones. The bigger Android phone makers are more able to make security investments than the cheaper phone makers.
>While the police managed to crack into Wong’s iPhone, which was locked with a four-digit passcode, they did not manage to access the contents of Chow’s Google Pixel phone using the force’s existing digital forensics tools, according to the court filing. Chow says her phone is still in police possession.
There is literally no other detail than the phone model name. For all we know it could be an ancient iPhone with a severely outdated OS and a brand new Pixel phone.
4-digit passcode hasn't been the default passcode option in iOS for a long time.
>This is supported by a look at smartphone cracking company Cellebrite’s effectiveness at breaking into different phones. Cellebrite can easily open up any iPhone X or earlier iPhone, but the same software used on a Google Pixel 2 or Galaxy S9 extracts very little information, and nothing at all in the case of the Huawei P20 Pro.
>That’s not to say that these Android devices are unbreakable. It's just that it requires a different, more labor-intensive process to get the data requested.
>The sheer variety of Android hardware and customized software builds makes it hard for phone-crackers to build a universal tool to break into Android phones. Meanwhile, a "jailbreak" released late last year permanently bypasses the security functions of every iPhone model from the iPhone 4s to the iPhone X.
This perfectly squares with what I personally know from law enforcement friends but I'm just an internet stranger.
Android with syncing enabled does much better in real world tests. Notably in hong kong, they were able to crack the iPhones, but not the Pixels[0]
I'm pretty sure without iCloud and a long enough password (or fast enough self destruct mode) iPhones could be as secure, but I don't know anyone that uses an iPhone and does not use iCloud in any way.
If you turn on iCloud syncing, basically you're falling back to simple "in transit" and "at rest" encryption.
A lot of iPhone cracks involve just attacking your iCloud account, and then reading all of your messages from backups. This is not possible on Pixel which encrypt your device backups with on-device hardware encryption.
> Pixel which encrypt your device backups with on-device hardware encryption.
Can you set up a new android phone from an old phone’s backup? If so, how could this work?
This is a standard way to set up a new iPhone: “restore” from a backup of your previous phone. Especially handy when your old phone is no longer available (lost/broken)
For your backups - but once you use iCloud to sync devices in real time, they just use their service keys, and your iCloud credentials are enough to read your iMessage history.
Okay, so if I understand correctly, the data in those Apple products is not secured, but turning on iCloud on a device does not ruin encryption for other apps that take it seriously. So if I have an app that uses Keychain (end-to-end encrypted) and encrypts it's data properly, it is still secure.
Unless Apple is really bad and somehow collects my keys from keychain, or collects keys passed to CryptoKit, etc., straight out of RAM, and sends them to 3-letter agencies ... if I think that's happening, then I will look for new devices.
I'm not sure I understand your keychain point. With iMessage you can message others with just your iCloud credentials if you turn it on, and you have access to full conversation history - without needing any particular device keys.
iCloud has always been suspicious: Apple cancelled end-to-end encryption on iCloud after a certain three-letter agency filed a complaint, saying that it would disrupt investigations and have a considerable impact on the law enforcement capabilities of our country. Not to mention, Apple's behavior has been decreasingly auspicious in places like Russia and China, where they've started preinstalling state-sponsored apps and relocating servers to government-controlled provinces, respectively.
> Apple's behavior has been decreasingly auspicious in places like Russia and China, where they've started preinstalling state-sponsored apps and relocating servers to government-controlled provinces, respectively.
This is a legal requirement to operate the service in China. Apple’s choice is between offering iCloud in China or not offering it at all in China, not between offering it with local servers or with out-of-country servers.
It is indeed a legal requirement, and both Google and Microsoft have chosen not to provide services in those areas for this exact reason. Apple is the only major tech company that still operates in China, and has become pretty politically passive in the region. I only bring this up because Apple claims that "privacy is a human right", which I suppose is pretty conditional to what kind of human you are.
> Apple is the only major tech company that still operates in China
This is not even remotely true, even if you define "major tech company" to mean "major US tech company".
Both AWS and Azure have actual cloud regions in China (delivered with a local JV partner just like Apple's cloud services are).
Even Google operates there in various ways - they have four offices there, they manufacture hardware there, and they sell tons of ads to Chinese companies via their local subsidiaries (for display outside of China obviously).
Apple isn‘t simply running iCloud locally as the law may require. They have transferred the operations of their entire iCloud service to a government owned company, including all keys.
What Apple does in China is more than complying with local laws. They appear to be exceptionally proactive in staying in the regime‘s good graces.
Running cloud services in China requires establishing a JV with a local partner. Look at AWS China as another example of this, but there are many.
Can you provide a reference for Apple's JV partners being government owned? Any company in China of course has to do as the Party tells them to, so I guess the difference is largely academic, but I haven't seen it mentioned before that Apple's China partners are government-owned.
This is true of your primary worry is nation states. If your primary worry is criminals/domestic partners/employers, this isn't the case. You can't give security advice without considering what you're protecting against.
Edit: your linked article says nothing about icloud
The difficulty is so low that it does not really matter. If you go by their bug bounties [1][2], then it is only $1M to full remote zero-click persistent compromise in both systems. If you go by Zerodium, which is a 3rd party purchaser and thus establishes a third party commercial market price, [3] then it is only $2M for iOS and $2.5M for Android. If we were to divide that price for an iPhone exploit by the number of iPhones sold in a year [4], then that is a mere 1 cent per iPhone.
As you can see, the price is so low it hardly even matters if there is a difference. There are literally millions of people in the US alone who personally have the liquid net worth to purchase a remote wormable persistent compromise that you can use to mass infect any Android or iPhone. Essentially every business with more than maybe 10 employees has enough assets to purchase such a weapon on the market. Just today I read on HN that the US government inked a deal for $22B over 10 years for 120k AR headsets from Microsoft [5] which comes out to ~$183k/headset. So, a weapon you can use to fully compromise any phone you want is equal in cost to a mere 15(!) headsets. That contract alone would be enough to purchase 10,000(!) vulnerabilities at existing clearing prices and $22B is only ~1/200th of the yearly US government budget.
Frankly, the entire thing is like two people jumping and comparing who is closer to landing on the moon.
From what I've seen, the majority of it is theater. Does that mean it's more secure than Android devices? Not necessarily.
In any case, the biggest vulnerability in any system is the end user. No amount of idiot-proofing will stop people from being scammed on an iPhone, nor will it stop someone on Android. When these companies market their "Secure Enclave" or "Titan Security", they're really just dressing up otherwise expected or boring features. The T2 chip was basically a dedicated PRNG chip with basic encoding capabilities, yet Apple paraded it as a boon for device security and game-changer for the end user. In reality, it doesn't solve any practical issues with computer security.
I've tried about every OS on the planet, and I've used them on a decent handful of different devices. I won't tell you what to think or do, but Apple's devices are difficult to appraise and hurt my head when I try to consider their impact on my overall "security". I'd much rather just use a Linux system that's transparent about it's vulnerabilities. Much of that same reasoning is why I still use Android these days.
And your point being that Android gets more updates/fixes than Apple? Lol, only Apple has a proven track record of providing 5 year old devices with updates/fixes unlike anything from Android, unless you are comfortable flashing your own builds.
No, I specifically said in my original post, "Does that mean it's more secure than Android devices? Not necessarily."
My ultimate point is that the biggest liability is the user, and those "security updates" don't really matter when the biggest attack vectors don't even consider these exploits in the first place.
From the wikipedia page for Meltdown: "On 8 May 1995, a paper called "The Intel 80x86 Processor Architecture: Pitfalls for Secure Systems" published at the 1995 IEEE Symposium on Security and Privacy warned against a covert timing channel in the CPU cache and translation lookaside buffer (TLB). This analysis was performed under the auspices of the National Security Agency's Trusted Products Evaluation Program (TPEP)."
My understanding is that people at the time were aware of potential problems but no vulnerability had been identified. I found some discussion here: https://security.stackexchange.com/a/177256
NSA used to have an active effort on information assurance, under the philosophy that it defended the country to have good civilian security (same reason for the NSA’s modification to the DES S-box). This unfortunately has fallen by the wayside.
(NSA shortened the key as well so it wasn’t all bunnies and chocolate)
Is this referencing the slow turnaround time, or the lack of a bounty paid so far? If it's the latter, I think it's already well known that bug bounties pay far less than the "market" value of such exploits.
Well I didn't know, until now. I saw the bug bounty page at Apple before, was dazzled by the numbers, and didn't think twice about approaching them if I found a bug. Now after this article I know better than to trust them to pay.
Is there a way to verify whether Zerodium might be advertising large payouts (for attention) and then offering much smaller payouts for the actual bugs?
It's pretty risky for Zerodium. There's nothing stopping a researcher from collecting a payout and then reporting the bug to the vendor.
I think so, but would Zerodium etc be able to prove it was the same person in each case? An independent researcher might have submitted the same issue to Apple coincidentally shortly after, presented in a slightly different way.
I would guess it would have a Non Disclosure Agreement attached, along with the mercenary reputation damage one take on by breaking the contract. One would not be let back in the club.
Do you think it wise to break a contract (eg: steal from) a weapons dealer?
How has maintenance & bug fixing been? I'm OK with mature apps stabilizing and needing few updates, though since it is a single dev with somewhat infrequent changes I thought I'd ask (https://updates.mailmate-app.com/release_notes).
This is the same exact issue that used to plague Outlook back in the day with the automatic handling of attachments. You'd think Apple would have learned from others' mistakes.
I don't exactly have a dog in this, but I think this is a strange framing: this feels like exactly the kind of niche feature that was added by one engineer and then forgotten about. MS and Apple are both large companies that maintain individual pieces of software that are probably older than many of the engineers who currently work on them; the lessons here are more organizational than technical.
It's because Apple framed themselves as the company of "LOL Macs don't get viruses" and emphasize themselves to be more privacy focused than Android...
...and they made the same basic mistake of allowing one of the single most exploitable attack vectors ever. They kinda shoulda known better, honestly.
PDF has had a zillion vulnerabilities over the years. And Apple doesn’t guarantee in Safari that Preview.app is the default handler, so that expands the scope of potential vulnerabilities to Acrobat, which is notorious for its history of vulnerabilities.
Perhaps someone more knowledgeable could explain it to me, but uncompressing the files automatically doesn't seem like that big a deal to me. The much bigger sin appears to be allowing symlinks or a reference of any kind outside of a sandboxed directory.
Whilst we wait on someone knowledgeable I'll butt in, I once listened to a podcast on pentesting: other than zip bombs the issue I see is that other vulns can have code execution exploits against them if only the haxor can get the code on to the host. With automatic uncompression the code can be placed on a host by emailing a user -- no need to convince them to click anything.
Uncompressing files is a big complicated task with lots of fiddly little details. There are tons and tons of options, and that means tons and tons of attack surface. Besides symlinks, there could easily be all sorts of other errors that would produce a similar kind of exploit.
Conventional security wisdom says that there are three primary problems with decompressing arbitrary inputs:
* Most compression container formats support relative and absolute paths outside of the current directory, for semi-legitimate reasons (like decompressing an entire raw filesystem, or using an archive format as an ad-hoc installation system). Many high-level languages have bindings that are unsafe by default in this regard.
* Most compression formats can be manipulated to contribe pathological inputs that require massive amounts of memory or CPU time. This makes them good vectors for DoSes.
* Compression and compression container formats themselves are complicated, for historical reasons. Many also have reference implementations with colorful security histories with regards to memory safety.
I may be wrong, but I thought the symlinks have to be in the sandbox. The problem is that the sandbox includes config files, preferences, etc. that can affect the way the Mail application works.
The claim is not "there's no exploitable bugs". Secure by design usually means that certain mechanisms are present in the system that mitigate security issues. Sandbox is one of them.
For all those people who are complaining that Apple is taking its time paying out a bounty, and suggesting Zerodium:
The end result of selling 0-click RCE vectors like this to brokers is sliced up bodies in embassies. Do folks think where the money coming from, and who would pay? No, its an 'easy' pay day.
Some of us fix security bugs to keep people safe.
Some of us try to earn an honest living doing so.
Others try to earn a dishonest living with pain and death in their wake.
Are you using your skills to improve life on this rock, or are you trying to make it worse for a pay day?
I agree with and appreciate your position. I'm more annoyed with Apple than with the security researchers. Apple is preying on your desire to do good. They could easily afford to pay a reasonable amount and promptly.
“By signing the agreement, you will accept an exclusive sale of your research to ZERODIUM and transfer all related intellectual property rights to us, meaning that the research becomes the exclusive property of ZERODIUM and you are not allowed to re-sell, share, publish, or report the research to any other person or entity.”
Nice morals. In reality, people often take their morals with a side of cash.
Let's turn it around. In Russia, the average salary is around $600 per year. Would you turn down a $50k payout? That's 83 years of an average salary.
Consider that you may be in a privileged position if you can say no to that kind of money.
The solution to this is for vendors to match what the market is paying. If an RCE is worth $50k on Zerodium, perhaps it's worth something similar to Apple not to have headlines about so-and-so exploit being used for cutting up bodies in an embassy.
EDIT: Oops. Divide 83 by 12. But you'll find it hard to locate someone willing to say no to 7 years of salary for ~zero additional work.
$600 / month is the average salary per month (according to probably the same Google search you did). Presumably someone reporting security vulnerabilities makes well more than the average.
That said... if someone pays me one or multiple annual salaries for something perfectly legal that's slightly morally questionable and indirectly linked to nasty things... I wish I could confidently say I'd say no, but I'm making no guarantees.
Can you be a bit more clear on what you're implying? Genuinely curious. I thought Zerodium was selling to government agencies.. so I'm not sure what you mean by sliced up bodies in embassies. Perhaps I'm just not thinking creatively/pessimistically enough.
Very confusing; A Saudi national was assassinated in the Saudi embassy by agents of the Saudi government. Linking this to Zerodium makes Zero sense. You don't need to do any digging to find out when someone is at your doorstep
I think the real alternative here is that fewer folks will spend time looking at Apple products or not fully investigating weird behavior encountered normally that could be a security issue.
The author specifically said that they were looking based on bug bounty guidelines. The next person in the same shoes will look at some other company's products instead.
MacOS 10.9 was pretty much when Apple jumped the shark. That was the last version I ran before switching back to Linux, and I ran it pretty damn long in the tooth as well -- until ~2018ish.
I still have a few VM images with MacOS 10.9 that I spin up from time to time in order to run commercial software like Adobe Acrobat.
I use 10.9 because out of all the OS's I've ever used, I like 10.9 the most by far, and I consider that worth the security risks. I browse the web in an up-to-date version of Chromium[0], I keep my computer behind an up-to-date router, and I trust my local software. An experienced hacker who wants to spend a few days getting into my computer will succeed, but they'd probably succeed anyway, and that's why I take measures like keeping backups in cold storage.
This was the first time I've actually backported a security fix. Apple Mail is easily where I'm most vulnerable, because it's not merely an outdated app which opens untrusted content—it opens untrusted content which anyone can push to me!
I can't find any information on the following questions:
Are all past versions of OS X / Apple Mail affected?
For what OS X Version does Apple provide a security update regarding this issue?
Has anyone found a fix that prevents auto-uncompression (such as a "defaults write com.apple.mail xyz False" command)?
Due to several reasons, I am also on an older Version of OS X and this issue makes me a bit nervous.
268 comments
[ 4.3 ms ] story [ 258 ms ] thread> 2020–05–24: PoC done and reported to Apple
> 2020–06–04: Catalina 10.15.6 Beta 4 with [hotfix released]
> 2020–07–15: Catalina 10.15.6 Update with hotfix released
Work was done but not paid. Shitty business on Apple side...
The better comparison is active users, weighted according to how many apply automatic updates. The vulnerability half-life probably isn't as devastating as you might think it is since Apple has centralized control to push out updates, limited only by users deliberately not installing them.
I would consider a vulnerability in OpenSSH to be far more economically devastating, and there isn't even a company with a market cap behind that software.
Who is wondering why Patreon and a blog post isn't sufficient to facilitate value transfer in metaphorical openssh scenarios?
Guess how much Microsoft pays for breaking the Windows Secure Boot implementation? $9k.
(Disclaimer: I want to like Mail.app, but I don't need another fan in my office.)
https://emailclientmarketshare.com
Although,
> Since determining the client in which an email is opened requires images to be displayed, the data for some email clients and mobile devices might be over- or under-represented due to automatic image blocking.
Outlook doesn't display external images by default, while Mail.app does, so....
Like me you may have disabled it and forgotten. Whenever I get a new laptop at work I tend to go through and change all the defaults, such as reverting to plaintext composition, and habitually disable external image loading as part of the process.
The iPhone Mail app may have saner defaults, however, but I don't have an iPhone and have never used its e-mail client.
What marginal advantage does a third-party iOS client provide, that outweighs the risks of installing another app that is going to spy on me, have weaker integration with the OS and force me to relearn every new UI design language they come up with that in no way resembles the rest of the OS or its function and behavior?
I understand why it might be a deal breaker for you, but browsing email offline is not a use case everyone has.
Thanks for saying this - it’s important to understand that the way things were are not alway the way things are :)
That’s not what the original question was. It was:
> what’s right with [Mail for iOS]
So me implying that reading mail offline is one thing that’s right with it is not invalidated by the fact that it’s not a universally demanded feature (and yes, it has helped me many times, even recently).
Do you really need to remove that feature to build a “better” email client? What exactly is the tradeoff you see?
1. Searches in Mail are slower and less accurate than web-client searches.
2. No access to Gmail filters. I don’t blame Mail for this, but it is a reason I returned to the web client.
3. Applying labels is harder in Mail. Maybe I missed it, but it wasn’t as easy to apply multiple labels or to apply a label to a draft email.
4. I couldn’t find a Send and Archive feature in Mail.
Basically, I like the Gmail experience. I hate Google, and I’d love to move away from them. I have for search, maps, mobile OS. For calendars, contacts, and mail, Google has the features I like.
https://www.thunderbird.net/
Whats a good alternative for macos these days? I loved sparrow back in the day, before I got acquired and killed by google.
I am not expecting this to fix by itself. Maybe some major review blogs should first not parrot how magical the whole thing is and change the tone as such things are not only annoying, but also a security risk even if you don't actively use the app. I am not an expert on development for MacOS, but I would be surprised if there is no way to trigger the mail app from another app or a link. I just hope the bug is not exportable this way.
None are demos or trialware. Hell, I use all of them except for FaceTime, Podcasts, Pages, TV and Launchpad.
I do remove most of them from the dock since I use spotlight to launch things, but removing System Preferences from my dock hardly makes it crapware.
Amazingly I have a handful of messages from the late 70s (a couple of jokes and a couple of personal messages from friends who passed away young) that have survived the file format transitions since then but I couldn't imagine could appear in something like google or yahoo mail. TBH I haven't made that many transitions: EMACS (BABYL) on ITS, then TOPS-20; Interlisp and Smalltalk clients to Grapevine back end; Lispm to TOPS-20 back end; GNU Emacs (rmail?) to IMAP; and then Apple Mail (macOS and iOS) -> IMAP. Emacs is the most powerful but these days still hard to put in your pocket.
In general a web browser seems like the worst interface to most services and activities as the UI can't be dedicated to the task at hand; instead you have system UI, Browser UI and only then the application UI. And a lot of mouse activity is expected.
> That's gonna be devastating to the three people who use Mail.app
Multiply that by 100,000,000
Maybe a good business is bug escrow company.
From wikipedia:
> Factoring is a financial transaction and a type of debtor finance in which a business sells its accounts receivable (i.e., invoices) to a third party (called a factor) at a discount.[1][2][3] A business will sometimes factor its receivable assets to meet its present and immediate cash needs.[4][5] Forfaiting is a factoring arrangement used in international trade finance by exporters who wish to sell their receivables to a forfaiter.[6] Factoring is commonly referred to as accounts receivable factoring, invoice factoring, and sometimes accounts receivable financing. Accounts receivable financing is a term more accurately used to describe a form of asset based lending against accounts receivable. The Commercial Finance Association is the leading trade association of the asset-based lending and factoring industries.[7]
For example, let's say I own a sheep farm. I hire people to trim the sheep, and they produce a bunch of cotton. Without the Bill of Exchange, if I want to pay the people I've hired then I will need to ship this cotton to the spinner, who then ships the spun cotton to the weaver, who then ships the woven cotton to the clothier, who then makes clothes and sells it to a consumer. Only after this has happened can I pay my employees with the money of the paying consumer.
With the Bill of Exchange, a bill is created when I deliver cotton to the spinner. This bill will require the spinner to pay me for the cotton delivered in e.g. three months. I can then take this bill to someone who trusts that the spinner will pay me in three months and ask them to buy the bill at a discount, such that they are paid in three months (when the bill expires). I can then use the proceeds from the sale of the bill to pay my employees immediately. And the buyer of the bill earns a bit of interest because he pays less for the bill than he is paid at maturity.
[1] https://professorfekete.com/articles/AEFMonEcon101Lecture5.p...
[2] https://professorfekete.com/articles/AEFMonEcon101Lecture6.p...
1. Company verifies the bug
2. Assigns it a price according to impact
3. Keeps details hidden until Apple pays them, then reveals the bug. Thus Apple is forced to pay, but bad actors dont get access.
Different bug markets can compete to correctly price bugs.
An alternative is public offer when Apple promises to not release a fix without payment. If it's not a bug, no need for a fix.
I agree with you on a moral basis: what difference does it make if I get payed not to publish it vs. If I just publish it without even asking to get paid. But I'm not sure the law would agree with us.
In this case you aren't just a vigilante targetting apple, there is established practice stretching decades.
There is also a duty on you as a security proffeshional, and there is a significant public interest in knowing about the vulnerability. So , most likely, it will be you doing your job.
Most countries have a culture against whistleblowers, starting from childhood ("don't be a tattletale", "don't be a rat").
If there is no intent to abuse the bug when not paied then there is no additional threat there from simply notifying the company that some threat is already present. How it can become a black-mail?
So every report about discovered bug can be considered as black-mail? If one discovers a bug, reports it to the company and says that after 3 months it will be public it's a black-mail too?
Or the payment request makes it different? And if person doesn't threat to publish the bug then it's ok?
[0] https://www.justia.com/criminal/offenses/white-collar-crimes...
Whoever, with intent to extort from any person, firm, association, or corporation, any money or other thing of value, transmits in interstate or foreign commerce any communication containing any threat to injure the property or reputation of the addressee or of another or the reputation of a deceased person or any threat to accuse the addressee or any other person of a crime, shall be fined under this title or imprisoned not more than two years, or both.
https://uscode.house.gov/view.xhtml?path=/prelim@title18/par...
What is a bugs correct price? The price that a bad actor would pay for it?
- Apple is a $2T company, that we trust with our data. That valuation is in part based on that trust. It's entitled of Apple to produce a product that contains shitty exploitable symlink handling and continue to have no meaningful repercussions (which is true in the industry as a whole).
If this was a bug in a small, under-resourced FOSS email client, or the exploit required many highly skilled person-years to find, maybe I'd feel differently.
People tend to vastly overestimate the economic impact of an exploited security vulnerability. A vulnerability which can be patched in a centralized manner has a low value half-life: it rapidly decreases in value over time. I would guess over 90% of active daily users of macOS already have the patch for this bug due to automatic updates. New buyers are essentially guaranteed not to have the vulnerability at all. The vulnerability would have to be absolutely catastrophic to be worth something, and in that case it would probably be used for targeted exploitation and burned after a short period of time.
Contrast with something like heartbleed, which is still around. That is a vulnerability with serious half-life and significant economic impact. The pool of available victims who can be exploited by heartbleed is nontrivial and persistent years later. Criminals will actually pay for something like that.
Mutt may look old but at least it actually works.
This is a case of the application working as designed, but in unintended ways. A logic flaw.
I say this because I don't see a lot of effort being put into solving these types of security issues, compared to e.g. memory safety issues.
V2: “This file unexpectedly tried to access [folder].”
The exact same mechanism Apple already used with GateKeeper and FS access for programs at runtime.
Why does it need to be more complicated than that?
Though I certainly shouldn't trust mutt to be bug free, given that it processes data that someone can send me freely. Gladly TUI programs are fairly easy to isolate in their own UNIX user account.
Or maybe the script has to exist in some folder this vulnerability doesn't have access to?
Or is it just security theater ?
Security is usually the last priority for nearly every for profit entity because it doesn't drive revenue.
They aren’t perfect but I don’t think it’s fair to say they don’t try.
https://en.m.wikipedia.org/wiki/JailbreakMe
If you have written a hardened, safe browser engine then you are free to share it to the world, otherwise I wouldn't downplay their efforts.
Not OP, but I'll stop complaining when Apple lets me use other browser engines.
Yes, IMO their business model is more accurately described as “gilded cages/jails” than just general “gilded/good-appearing stuff”. They deeply care about the strength of their DRM — including at the expense of end-user security, eg. you can’t access the internet through the Tor browser installed the normal macOS way without macOS broadcasting that you used Tor Project products to Apple’s DRM servers.¹
> They are pretty serious about trying to prevent data exfiltration from locked iOS devices as well.
They definitely care about the appearance of trying to prevent that exfiltrating (they don’t publicly appear to help the FBI do it), but they don’t try hard enough to actually prevent it (including in situations were preventing exfiltration seems to have been proven possible, see nearby comment https://news.ycombinator.com/item?id=26667141).
¹Edit: ocsp.apple.com, enabling targeting of the people who need or want security the most.
To the people downvoting: I’m trying to make an evidence based refutation of the less supported speculation/assertions in the parent post. If you have counter-evidence or any reason to downvote other than fanboyism, please explain it so we or I can learn.
Your first point is intended to refute the effort put into stopping jailbreaking in iOS. The example you give is about privacy on Mac OS.
Last, accusing folks of being fanboys is a particularly weak argument. It says, if you don’t agree with me then your blind allegiance to a corporation renders you incapable of critical thought. Basically, if you don’t agree with me, you’re dumb. There is no practical engagement with that thesis.
In general less complexity is better, but it also constrains things. For example it took until recently for third party iOS to be able to do NFC. Android had it since ~2012.
I seriously wonder: what difference did it make? Was there any groundbreaking thing iOS users missed for 8 years?
Apple is just great in omitting things and keeping focus to deliver a great product and then expand on that basis.
Most famous example: First iPhones didn’t have MMS
Or cut and paste. ;-)
For example, I have set up a tag to automatically connect friends phones to my WiFi network. You can also stick tags on places to trigger specific actions/mode/app: office, meeting room, car, bedroom.
Also one thing that could have been great to share pictures/files/urls with your computer or other phones: Android beam [1]. Sadly Google is removing it.
[1]https://en.wikipedia.org/wiki/Android_Beam#Usage
On the Android side, Google makes good software changes to Android, but ultimately the security is dependent on the handset maker (e.g. Samsung) and SoC maker (e.g. Qualcomm). Security will vary between Android phones. The bigger Android phone makers are more able to make security investments than the cheaper phone makers.
https://qz.com/1844937/hong-kongs-mass-arrests-give-police-a...
4-digit passcode hasn't been the default passcode option in iOS for a long time.
>This is supported by a look at smartphone cracking company Cellebrite’s effectiveness at breaking into different phones. Cellebrite can easily open up any iPhone X or earlier iPhone, but the same software used on a Google Pixel 2 or Galaxy S9 extracts very little information, and nothing at all in the case of the Huawei P20 Pro.
>That’s not to say that these Android devices are unbreakable. It's just that it requires a different, more labor-intensive process to get the data requested.
>The sheer variety of Android hardware and customized software builds makes it hard for phone-crackers to build a universal tool to break into Android phones. Meanwhile, a "jailbreak" released late last year permanently bypasses the security functions of every iPhone model from the iPhone 4s to the iPhone X.
This perfectly squares with what I personally know from law enforcement friends but I'm just an internet stranger.
Android with syncing enabled does much better in real world tests. Notably in hong kong, they were able to crack the iPhones, but not the Pixels[0]
I'm pretty sure without iCloud and a long enough password (or fast enough self destruct mode) iPhones could be as secure, but I don't know anyone that uses an iPhone and does not use iCloud in any way.
[0]: https://qz.com/1844937/hong-kongs-mass-arrests-give-police-a...
The only things end to end encrypted are listed on this page: https://support.apple.com/en-us/HT202303
If you turn on iCloud syncing, basically you're falling back to simple "in transit" and "at rest" encryption.
A lot of iPhone cracks involve just attacking your iCloud account, and then reading all of your messages from backups. This is not possible on Pixel which encrypt your device backups with on-device hardware encryption.
Can you set up a new android phone from an old phone’s backup? If so, how could this work?
This is a standard way to set up a new iPhone: “restore” from a backup of your previous phone. Especially handy when your old phone is no longer available (lost/broken)
https://security.googleblog.com/2018/10/google-and-android-h...
Not that I fully understand how hard it is to circumvent.
Unless Apple is really bad and somehow collects my keys from keychain, or collects keys passed to CryptoKit, etc., straight out of RAM, and sends them to 3-letter agencies ... if I think that's happening, then I will look for new devices.
This is a legal requirement to operate the service in China. Apple’s choice is between offering iCloud in China or not offering it at all in China, not between offering it with local servers or with out-of-country servers.
This is not even remotely true, even if you define "major tech company" to mean "major US tech company".
Both AWS and Azure have actual cloud regions in China (delivered with a local JV partner just like Apple's cloud services are).
Even Google operates there in various ways - they have four offices there, they manufacture hardware there, and they sell tons of ads to Chinese companies via their local subsidiaries (for display outside of China obviously).
What Apple does in China is more than complying with local laws. They appear to be exceptionally proactive in staying in the regime‘s good graces.
Can you provide a reference for Apple's JV partners being government owned? Any company in China of course has to do as the Party tells them to, so I guess the difference is largely academic, but I haven't seen it mentioned before that Apple's China partners are government-owned.
https://techcrunch.com/2018/07/17/apples-icloud-user-data-in...
There are conflicting reports and vague language around how exactly the keys are handled.
Edit: your linked article says nothing about icloud
As you can see, the price is so low it hardly even matters if there is a difference. There are literally millions of people in the US alone who personally have the liquid net worth to purchase a remote wormable persistent compromise that you can use to mass infect any Android or iPhone. Essentially every business with more than maybe 10 employees has enough assets to purchase such a weapon on the market. Just today I read on HN that the US government inked a deal for $22B over 10 years for 120k AR headsets from Microsoft [5] which comes out to ~$183k/headset. So, a weapon you can use to fully compromise any phone you want is equal in cost to a mere 15(!) headsets. That contract alone would be enough to purchase 10,000(!) vulnerabilities at existing clearing prices and $22B is only ~1/200th of the yearly US government budget.
Frankly, the entire thing is like two people jumping and comparing who is closer to landing on the moon.
[1] https://www.google.com/about/appsecurity/android-rewards/
[2] https://developer.apple.com/security-bounty/
[3] https://zerodium.com/program.html See Mobiles payout.
[4] https://www.statista.com/statistics/276306/global-apple-ipho....
[5] https://techcrunch.com/2021/03/31/microsoft-wins-contract-wo...
In any case, the biggest vulnerability in any system is the end user. No amount of idiot-proofing will stop people from being scammed on an iPhone, nor will it stop someone on Android. When these companies market their "Secure Enclave" or "Titan Security", they're really just dressing up otherwise expected or boring features. The T2 chip was basically a dedicated PRNG chip with basic encoding capabilities, yet Apple paraded it as a boon for device security and game-changer for the end user. In reality, it doesn't solve any practical issues with computer security.
I've tried about every OS on the planet, and I've used them on a decent handful of different devices. I won't tell you what to think or do, but Apple's devices are difficult to appraise and hurt my head when I try to consider their impact on my overall "security". I'd much rather just use a Linux system that's transparent about it's vulnerabilities. Much of that same reasoning is why I still use Android these days.
My ultimate point is that the biggest liability is the user, and those "security updates" don't really matter when the biggest attack vectors don't even consider these exploits in the first place.
This is an extremely misleading description of the scope of T2’s duties.
From the wikipedia page for Meltdown: "On 8 May 1995, a paper called "The Intel 80x86 Processor Architecture: Pitfalls for Secure Systems" published at the 1995 IEEE Symposium on Security and Privacy warned against a covert timing channel in the CPU cache and translation lookaside buffer (TLB). This analysis was performed under the auspices of the National Security Agency's Trusted Products Evaluation Program (TPEP)."
i.e. did they know even in 1995?
(NSA shortened the key as well so it wasn’t all bunnies and chocolate)
Well I didn't know, until now. I saw the bug bounty page at Apple before, was dazzled by the numbers, and didn't think twice about approaching them if I found a bug. Now after this article I know better than to trust them to pay.
Is there a way to verify whether Zerodium might be advertising large payouts (for attention) and then offering much smaller payouts for the actual bugs?
It's pretty risky for Zerodium. There's nothing stopping a researcher from collecting a payout and then reporting the bug to the vendor.
Wouldn't the payout contract prohibit reporting to anyone else?
They might pay out over a long period of time for some guarantee that you'll play by their rules, though.
There should likely be a governing body that independently values an exploit and forces companies to pay
Like how the SEC’s whistleblower program works
Its completely broken to have corporations pinky promise not to sue you if you tell them and arbitrarily decide payouts if at all
and tbh, it's probably the same answer for most providers these days.
(Just guessing though.)
https://freron.com/
What could possibly go wrong? ;-/
Why would you think that?
...and they made the same basic mistake of allowing one of the single most exploitable attack vectors ever. They kinda shoulda known better, honestly.
* Most compression container formats support relative and absolute paths outside of the current directory, for semi-legitimate reasons (like decompressing an entire raw filesystem, or using an archive format as an ad-hoc installation system). Many high-level languages have bindings that are unsafe by default in this regard.
* Most compression formats can be manipulated to contribe pathological inputs that require massive amounts of memory or CPU time. This makes them good vectors for DoSes.
* Compression and compression container formats themselves are complicated, for historical reasons. Many also have reference implementations with colorful security histories with regards to memory safety.
They seem to have the same issues as everyone else.
[1] https://www.apple.com/business/docs/site/AAW_Platform_Securi...
The end result of selling 0-click RCE vectors like this to brokers is sliced up bodies in embassies. Do folks think where the money coming from, and who would pay? No, its an 'easy' pay day.
Some of us fix security bugs to keep people safe. Some of us try to earn an honest living doing so. Others try to earn a dishonest living with pain and death in their wake. Are you using your skills to improve life on this rock, or are you trying to make it worse for a pay day?
... based on?
“By signing the agreement, you will accept an exclusive sale of your research to ZERODIUM and transfer all related intellectual property rights to us, meaning that the research becomes the exclusive property of ZERODIUM and you are not allowed to re-sell, share, publish, or report the research to any other person or entity.”
Let's turn it around. In Russia, the average salary is around $600 per year. Would you turn down a $50k payout? That's 83 years of an average salary.
Consider that you may be in a privileged position if you can say no to that kind of money.
The solution to this is for vendors to match what the market is paying. If an RCE is worth $50k on Zerodium, perhaps it's worth something similar to Apple not to have headlines about so-and-so exploit being used for cutting up bodies in an embassy.
EDIT: Oops. Divide 83 by 12. But you'll find it hard to locate someone willing to say no to 7 years of salary for ~zero additional work.
7 years of salary is a lifechanging amount of money too, but I admit the thrust of the argument isn't quite as strong with a basic error. :)
A better comment is probably "We've tried the alternative, and it doesn't seem to work. It's better to pay market rate."
1- https://en.m.wikipedia.org/wiki/Jamal_Khashoggi
https://edition.cnn.com/2019/01/12/middleeast/khashoggi-phon...
https://edition.cnn.com/2019/01/12/middleeast/khashoggi-phon...
The author specifically said that they were looking based on bug bounty guidelines. The next person in the same shoes will look at some other company's products instead.
The core problem is that really dumb feature which auto-expands certain zip files. I need to turn that off.
MailWebAttachment.h contains a method:
I bet that if I Swizzle that to always return false, this "feature" will go away. I'll found out this weekend...Edit: Is the author's PoC available anywhere? Not that I really need it...
Do you follow all security-related announcements for Mac OS and do your own back ports and fixes?
How did you decide 10.9 is the right balance of risk for you?
MacOS 10.9 was pretty much when Apple jumped the shark. That was the last version I ran before switching back to Linux, and I ran it pretty damn long in the tooth as well -- until ~2018ish.
I still have a few VM images with MacOS 10.9 that I spin up from time to time in order to run commercial software like Adobe Acrobat.
This was the first time I've actually backported a security fix. Apple Mail is easily where I'm most vulnerable, because it's not merely an outdated app which opens untrusted content—it opens untrusted content which anyone can push to me!
0: https://github.com/blueboxd/chromium-legacy
Had to make `-(BOOL)isAutoArchivePart` in `MCMimePart` return false.
Makes we wonder how many applications on Windows and MacOS actually support the system sandbox.
Are all past versions of OS X / Apple Mail affected? For what OS X Version does Apple provide a security update regarding this issue? Has anyone found a fix that prevents auto-uncompression (such as a "defaults write com.apple.mail xyz False" command)?
Due to several reasons, I am also on an older Version of OS X and this issue makes me a bit nervous.
> Available for: macOS Mojave 10.14.6, macOS High Sierra 10.13.6, macOS Catalina 10.15.5
[0]: https://support.apple.com/en-us/HT211289
https://support.apple.com/en-us/HT211289