Short of rewriting the whole of iOS in a memory safe language I'm not sure how they could even solve this problem. Assigning a researcher to search for 6 months only to find one bug is financially prohibitive.
> One of the most time-consuming tasks of this whole project was the painstaking process of reverse engineering the types and meanings of a huge number of the fields in these objects. Each IO80211AWDLPeer object is almost 6KB; that's a lot of potential fields. Having structure layout information would probably have saved months.
> Six years ago I had hoped Project Zero would be able to get legitimate access to data sources like this. Six years later and I am still spending months reversing structure layouts and naming variables.
But, if you actually stop and think about it for a moment... isn't this situation completely bizarre? Apple Silicon Macs explicitly support booting alternate OSs, because Apple went out of their way to add a `permissive-security` option to the boot-loader. They know Linux is important—the initial Apple Silicon reveal included a Linux VM demonstration—and now a well-known and talented developer is planning to do a native Linux port, at no cost to Apple, and we all fully expect that Apple won't make any documentation available or answer any questions? And, we're probably right?
The more I consider it, the more crazy it all seems. Why is Apple so private about the internals of their products? It won't affect marketing—normal consumers don't care—and I can't think of a plausible scenario where this type of information could help a competitor.
Is Apple using source code stolen from Oracle? Are they scared someone will discover an internal library written in COBOL and make fun of them? Are they worried their documentation could revive Steve Jobs as a vengeful ghost? I just don't get it.
Because they don't care. The extent they care is directly linked to the amount of money they will make from caring. They won't sell more macs if macs can run Linux better; but they will sell more Apple Music subscriptions if macs keep running macOS.
> They know Linux is important
No, they know Linux is a pain in the ass. The bootloader option assuages the executives' conscience enough to be able to talk to a journalist and keep a straight face when asked about "openness" or being "hacker-friendly", stuff those 1980s-style Linux hobbyists keep talking about and nobody else gives a shit about.
Apple makes money by selling iDevices to consumers and selling Macs to enough developers to build apps for iDevices. Everything else is a bonus, and not worth spending much time on. They do the minimum and leave it as that. There is no inconsistency or secret motive. They just don't care. When they cared, in the early '00s, they did a bit more; now they do less. The attitude is the same.
For now. They haven't made any "I have to buy this right fucking now!" worthy revolutionary improvements in the iDevices lineup recently, the Western market for smartphones is near saturation - and with Corona tanking the US economy for wide masses, people don't have the hundreds of dollars just lying around to shell off for the latest iteration.
I believe that both the last (horribly expensive at that, and still people kept buying it) Mac Pro and the new M1 lineup is a sign that Apple wants to shift back attention to the non-mobile sector - because the competition there is asleep on the wheels. Everyone uses Intel who has managed to fuck up its lineup for many years now, Microsoft has thoroughly pissed off the privacy-conscious folks with Win10 and (judging by a random walk through a Mediamarkt) build quality in Windows laptops still hovers barely above "acceptable" - cheap plastics, tiny touchpads and abysmal screens are the norm, whereas Apple is only robust aluminium cases, giant touchpads and crystal clear, bright screens.
What I'm really excited for is when Apple decides to put an Mx chip into an iMac, paired with a decent AMD GPU. The thermals and energy profile should be allowing a lot more leeway for resource usage than a Macbook...
The type of person who buys an Apple Silicon Mac to run Linux is not going to buy an Apple Silicon Mac to run macOS. However...
> They won't sell more macs if macs can run Linux better.
They would sell some more Macs. Possibly hundreds of thousands more. A drop in the bucket for Apple, but still money—and all they have to do to get it is answer some questions.
Even when it doesn't rely on anything Apple-specific, it can be unclear how to build it.
I noticed that if I ctrl-z dc, then resume it, it silently exits. I grabbed the source to see if I could build it, and then perhaps debug this.
The source is part of bc. When you extract it there is a directory containing a bc dir, a patches dir, a bc sources tarball, and a Makefile. The bc directory is the contents of the tarball with the patches from the patches directory applied.
Optimistically typing "make" does not work. It runs configure somewhere (in the bc directory, I think), decides that gcc is /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc, and decides that this cannot create executables and exits.
Maybe just going into the bc directory and running configure and make there will do the trick? ./configure works and builds a makefile. Trying to compile with that gets fatal errors, apparently due to missing <string.h> in some C files.
OK, I don't actually care about bc, so how about just trying to build dc, which lives in a subdirectory under the bc directory.
That gets a fatal error due to a conflict between "#define ptrdiff_t size_t" in the config.h that configure made, and "typedef __darwin_size_t size_t" from somewhere. Based on the comments in config.h, apparently it should only be defining that if it is not defined by the system. Commenting it out in config.h and trying again...and all the compiling steps for dc actually finish!
Alas...it then fails because it needs ../lib/libbc.a, which presumably would have been built before building dc if the bc build had worked.
Maybe if I go to ../lib and type make? Nope. In fact, the errors are identical to when I typed make for bc, because it turns out that making libbc.a is the first thing the bc make tries to do.
Tossing in "#include <string.h>" in lib/getopt.c and lib/number.c makes everything build, finally giving me a locally built dc.
Is it too much to ask that when I download the source from Apple to their version of a simple command line knows-nothing-about-MacOS utility like this, I should just be able to type "make" somewhere and have it build? Or at least have a README in the tarball that tells me what I need to do?
$ CC="clang -Wno-implicit-function-declaration" ./configure
$ makeBecause it makes it easier for attackers to find vulns. That's why they do it. The high payouts on these platforms are evidence that it isn't as simplistic as "only defenders would look at this why won't they release it!?"
I certainly understand the frustration for legitimate researchers, and there's plenty to be said about having the source code available to make auditing easier but in itself it seems that making a black hat take 6 months instead of 1 to create an exploit raise the skill/patience level needed and busy them for while where they are not working on the next exploit.
I believe they're about to do this: https://www.theverge.com/2019/8/8/20756629/apple-iphone-secu...
https://twitter.com/benhawkes/status/1286021329246801921
> It looks like we won't be able to use the Apple "Security Research Device" due to the vulnerability disclosure restrictions, which seem specifically designed to exclude Project Zero and other researchers who use a 90 day policy.
For some reason this ridiculous restriction reminds me when Apple sued Samsung because their phones had round corners.
Rounded corners are the after-the-strategic-decision legal justification.
This is no longer possible on any phone, tablet, or computer Apple sells: all require online activation with device-specific info. There is no way to put the device back into a known state offline or without Apple having an opportunity to tamper with it (or be forced to tamper with it).
It is still possible on all of their computers, just not their phones or tablets. Intel Macs (which are still being sold in large numbers) can always be wiped and restored from USB without an internet connection, and Apple Silicon Macs can do it if you set the boot-loader to "Reduced Security" mode.
I would love to be wrong about this.
This is the case even if you have a full offline boot/restore USB.
I have a post coming out today about just this, and how it renders all current macs unsuitable for long term offline/airgap applications.
No sources or structure layout or symbols, so you're still stuck waddling through megabytes of compiled code to reverse-engineer everything from scratch.
It's Apple drumming up absolutely nothing, and from my point of view it's mostly a PR stunt.
Well, I don't think it's quite "nothing". Newer phones don't have access to checkm8, and getting a private jailbreak or exploit working can be non-trivial. And in some cases, researchers may need to avoid reporting that exploit to Apple in order to keep using it.
It's a good step. It's just not sufficient, especially given all the other restrictions.
And this will continue to happen until Apple just starts selling the damn things to anyone who wants them, instead of trying to gatekeep them to people who are playing by their ridiculous security disclosure rules.
Sure, some crazy people who aren't security researchers will probably buy them too and use them as daily drivers (I'd probably be one of them). So what? I don't understand why Apple feels the need to hold this stuff so close to their chest. Everyone in this scenario knows exactly what they're buying.
Oh, that's a shame. The slide in the referenced tweet says, "advanced debug capabilities", so I'd assumed that's what it meant. I wonder what else that could mean?
Wordpress is a mess, but being OSS does not inherently make something less secure.
No need to dig so much if you just want to fix the problem.
But he wanted to prove something. That is a different thing.
By 'wanting to prove something', he showed the shortcomings of multiple security mitigations, all defeated by simple bugs.
By 'wanting to prove something', he also discovered two other exploitable 0days, that wouldn't have been discovered otherwise. Those 0days were likely already in the hands of bad actors, too.
Finally, the reason he even discovered the original bug is because Apple accidentally once or twice forgot to strip function names from a binary. If this didn't happen, that bug very likely would still be out there in the wild.
I'm not sure you understand how security research works.
Note that memory safe languages won't solve security. They only eliminate a class of security bugs, which would be amazing progress, but not all of them.
(yes I know I'm talking about macOS but the vulnerability was found in iOS, but there's a lot of shared code between them, especially on levels this low)
Do you have a source for this?
https://www.spiegel.de/international/world/catalog-reveals-n...
Also a good idea to DDG Phineas Phisher. You should turn up an interesting read on pastebin iirc.
Edit: found it on exploit-db
There are of corse Yacy and other more independent options, but they aren't ready for most people.
https://www.haaretz.com/middle-east-news/.premium-with-israe...
https://podcasts.apple.com/us/podcast/darknet-diaries/id1296...
I believe they described their toolbox as metasploit on steroids. Some other episodes of darknet diaries also interview former and current government hackers.
The average small business loan is more than that at $633,000 [1]. Hell, a single McDonalds restaurant [2] costs more than that to setup. In fact, it is not even out of the reach of vast numbers of individuals. Using the net worth percentiles in the US [3], $500,000 is only the 80th percentile of household net worth. That means in the US alone, which has 129 million households, there are literally 25.8 million households with the resources to bankroll such an effort (assuming they were willing to liquidate their net worth). You need to increase the cost by 1,000x to 10,000x before you get a point where it is out of reach for anybody except for large governments and you need to increase the cost by 100,000x to 1,000,000x before it actually becomes infeasible for any government to bankroll such attacks.
tl;dr It is way worse than you say. Every government can fund such an effort. Every Fortune 500 company can fund such an effort. Every multinational can fund such an effort. Probably ~50% of small businesses can fund such an effort. ~20% of people in the US can fund such an effort. The costs of these attacks aren't rookie numbers, they are baby numbers.
[1] https://www.fundera.com/business-loans/guides/average-small-...
[2] https://www.mcdonalds.com/us/en-us/about-us/franchising/new-...
[3] https://dqydj.com/average-median-top-net-worth-percentiles/
There are also paranoid people in positions of power, and bureaucracies that can justify spying on employees. One of the interesting things about this lockdown was finding out that many companies put spyware on their employee-issued computers to monitor their usage.