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.
I believe they're about to do this: https://www.theverge.com/2019/8/8/20756629/apple-iphone-secu...
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.
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.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.
Yes, same old buffer C/C++ overflow problem. We have mainstream alternatives now. C#. Go. Rust. It's time to move on.
If they haven't kept up with the changes in their current language, what makes one think that they would "move on" to the alternatives, two of which aren't even alternatives?
Before they switch to Rust it would be much faster and more efficient to use smart pointers, std::array, std::vector and stop using memcpy.
To me it's that this extremely trivial bug (the heap overflow, let's ignore the rest for now) passed through code review, security review, security audits, fuzzing... Or that Apple didn't have these in place at all. Not sure which option is worse.
To me, this strongly suggests that the problem is in fact memory-unsafe languages, and not general engineering practices.
Apple, by the way, has all the things you're talking about in place, and in spades.
Safe languages are the only way forward to drastically reduce the problem. It can’t be guaranteed to be eliminated 100% obviously because there are still escape hatches available, but it will be significantly improved because you can limit the surface area where such bugs can live.
Thankfully, Apple is starting to hire Rust developers as well as AWS.
The tide is changing, one day we will see some Rust code in iOS/macOS so that these issues are a thing of the past.
It seems much more likely that they will use Swift in some form.
There's so much low-hanging fruit to pick in that code and switching to Rust is like saying that we should go to Mars to pick fruit instead.
https://en.m.wikipedia.org/wiki/Singularity_(operating_syste...
I agree rust is probably better suited. Or Apple could make their own memory safe language. They’re clearly capable.
Go: GC again, so no go.
Rust: most sane of the examples you've given.
Apple has already started migrating to Swift which is a memory safe language.
However the real reasons Rust and Go aren't feasible is that they're both essentially all-or-nothing, and neither offers even the most basic semblance of ABI compatibility. Their only nod to ABI stability is "use FFI to C" which means your APIs remain unsafe, and doesn't work for non-C languages without all your system APIs having other languages layered on top.
Swift at least lets you replace individual objc classes one at a time, and is ABI stable, but has no C++ interaction.
The basic trick for backwards compatibility is that all arrays have sizes, but you get to specify the expression which represents the size and associate it with the array. So you don't need array descriptors and can keep many existing representations.
Also, if you have slices, you rarely need pointer arithmetic. Slices are pointer arithmetic with sane semantics.
I'm tired of seeing decade after decade of C/C++ buffer overflows. It speaks badly of software engineering as a profession.
[1] http://www.animats.com/papers/languages/safearraysforc43.pdf
Apple sits on this giant stack of unused money [1]. Why don’t they get the best security researchers in the world, pay each of them north of $1M / year in salary and create the ultimate red team where their only task is to try to hack Apple devices.
If they get a team of 1000(!) people, each with $1M(!) in salary that would be less than 0.5%(!) of their revenue in 2019 [2].
Wouldn’t that be worth it?
[1] https://fortune.com/2018/01/18/apple-overseas-cash-repatriat...
[2] https://www.statista.com/statistics/265125/total-net-sales-o...
I am just surprised because there are so many problems in tech where throwing money at it is not going to improve things.
However in this case, shouldn’t they be able to attract the best in the world just by turning the money gauge up?
If you are one of the most highly specialised vulnerability researchers in the world, would you seriously reject a $10m / year offer from Apple where you’d be able to spend all your time doing what you love with the only condition being that you report findings to Apple?
Do you have any reason to think that Apple could stiff people that submit vulnerabilities to them?
My understanding of game theory says that Apple’s incentives are to try to act with integrity and to pay their bounties. There may be corner cases where confusion reigns, and where Apple mistake someone for a fraud, but I would presume they need to be very rare – otherwise Apple’s reputation as a buyer would suffer and people would sell to other buyers who cared for their reputation better (and every vulnerability sold to a third party has a high expected cost to Apple. Edit: on second thoughts maybe the cost to Apple is fairly low - certainly the maximum bounty size says that).
Edit: I agree that Apple stating a maximum payout is hardly helpful. I presume third party buyers indicate a minimum value they will pay depending on the value of the vulnerability to them. There is a market here, and it isn’t clear that Apple is willing to pay market prices, perhaps because too many people/teams give their vulnerabilities to Apple for $0 (e.g. projectzero!)
It would be far more beneficial for them to just use the tried-and-true techniques that have already been deployed for decades in high-reliability/high-security systems. In the event that such things are too onerous, they could run development methodology tests to remove the elements that provide the least security ROI to produce lesser, but still good, systems at a reduced cost. This would be far more likely to produce a good outcome than taking the standard high development velocity commercial methodology that has failed to produce meaningful security despite decades of attempts and enhancing it to be a high security process. At least in the former you can be reasonably confident you get good security, though possibly at a higher cost than desired. In the latter, although the cost may be less, the security is a complete unknown since you are using a new process invented by people who have never used, let alone made, a high security process before and it is a class of strategy that has literally never succeeded over multiple decades of attempts. Not to say it could not happen, it took hundreds or possibly even thousands of years of failed attempts before heaver-than-air flight was cracked, but they would probably be better served just using the existing techniques that are known to solve the problem.
This finding is not about this single bug, it's just that someone bothered to scrape the surface.
(Note that 99% of the effort went into crafting the demo exploit once the vulnerability was found, which is basically wasted effort in the context of eliminating vulnerabilities - the vulnerability finding was easy)
My theory is: people that are quite tech savvy (like the HN crowd) would look at such an effort quite favourably and these folks are often micro-influencers when it comes to buying decisions of their direct peers.
Just an anecdote, but my entire family uses Apple devices, because I am the go-to computer guy in that circle and I advised them to buy Apple. The company that I co-founded used Apple hardware and so on.
Maybe that is just wishful thinking and it is hard to quantify, but I’d like to believe that increasing your reputation with developers (who in itself are a niche) helps you grow revenue in the long-term nevertheless.
> Using two MacOS laptops and enabling AirDrop on both of them I used a kernel debugger to edit the SyncTree TLV sent by one of the laptops, which caused the other one to kernel panic due to an out-of-bounds memmove.
How did this even pass the _smell_ test? How did it get through code reviews and auditing? You're allocating from an untrusted source. It's like memory management 101. I mean, my goodness, it's from a wireless source, at that.
† In this specific scenario, namely the list of `IO80211AWDLPeer`s.
Because attackers only have to find one place that was unlucky in implementation, and hence defenders are burdened with eliminting every last one of them.
This is why implementing your network protocols in unsafe languages is bad. Testing can just find some bugs, not ensure absence of bugs.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
Now I know it's deeply comforting to think if you just had "safety" you could write all the code you want with abandon and the computer would tell you if you did it wrong, but this is a sophomoric attitude that you will either abandon when you have the right experiences, or you will go into management where the abject truth in this statement will be used to keep programmer salaries in the gutter, and piss-poor managers in a job. Meanwhile, these "safe" languages will give you nothing but shadows you'll mistake for your own limitations.
My suggestion is just learn how to write secure code in C. It's an unknown-unknown for you at the moment, so you're going to have to learn how to tackle that sort of thing, but the good news is that (with the right strategy) many unknown-unknowns can be attacked using the same tricks. That means if you do learn how to write secure code in C, then the skills you develop will be transferable to other languages and other domains, and if you still like management, those skills will even be useful there.
This is why researchers like the OP exist. They find exploits and report them to the manufacturer (hopefully) before they can be used. The fact that this is an effective way of protecting us is also why major software companies offer bug/exploit bounties to researchers.
To demand that all possible exploits of this nature never find their way into production builds is to demand perfection from humans. There is too much to know and think about, and definitely too many unknowns about the future, to make such a fantasy possible while still meeting release deadlines. We software developers often have a hard enough time just meeting feature and documentation deadlines, and adding more people just makes organizing your efforts more complex and difficult which then requires even more people until you reach the point that the scope of organizing your development teams is financially impossible.
> The data structure holding the peers is in fact much more complex than a linked list, it's more like a priority queue with some interesting behaviours when the queue is modified and a distinct lack of safe unlinking and the like.
I amended my post for clarification, I'm sure Apple uses linked lists all the time :)
And then just, well, practice. A lot of practice. Mostly driven by curiosity about how things work - bugs will then just start to pop up and you are free to investigate whatever piques your interest. The more likely you are to just open up a debugger when a piece of software annoys you and try to binary patch it, the closer you are to being a security researcher :).
There's not much books/courses on this, low-level hacking is something that you kind of just learn as you go. But, for instance, if you never touched gdb/lldb, or never looked at assembly code, or never wrote C - you should investigate that first as base skills.
You can also do the challenges using IDA/Ghidra instead of looking at the source for a proper challenge and I recommend doing this initially for each challenge.
Checkout https://ctftime.org/ for a list of ctfs. There are also intro ctfs like https://picoctf.org/
Do play CTFs. Just pick the fun challenges. pwnable.kr used to have some good stuff if you want to level up.
I wonder if the daily HN article about Apple failing to be secure is a result of 1 OS, 1 phone. Where as no one is going to put the effort to find an exploit on a phone with 1% market share.
Similar question for desktops.
The main difference between the two I have seen is ios users get an update that fixes the issue often after their device has stopped getting feature updates while many android users are on kernels that haven't received an update in the last few years.
It was fantastic; I got a whole year of not being able to see work emails after I went home, and then they let us opt out of the invasive MDM software that they wanted to put on Android phones to let them access corporate email. All for a bug that my phone wasn't even vulnerable to.
By the time I left, I had gone 4 years without ever responding to unexpected evening emails. And now that I know it's possible, I'm never going back! :)
Although none of those are recent like daily security flaws we see on HN.
And a second: https://googleprojectzero.blogspot.com/2020/09/attacking-qua...
Wow, so Apple was ahead of Amazon's Sidewalk with AWDL. Can you disable this?
Not exactly. The wording in the article implies that AWDL forms some kind of multi-hop network topology, but it doesn’t - it just enables nearby devices to communicate with each other directly at Wi-Fi speeds without the burden of pairing (like Wi-Fi Direct) or being associated with the same Wi-Fi network.
This is used not just in AirDrop but also in the Multipeer Connectivity Framework, AirPlay 2 and the Continuity framework. The standard discovery mechanism for these services is mDNS over AWDL, so for a device to browse for or advertise these services, it needs to be aware of other nearby AWDL neighbours first. (For example, you can browse for and discover other nearby AirDrop devices even if you don’t allow incoming AirDrop enabled yourself.)
It’s also worth noting that Apple devices very strictly do not send or receive AWDL traffic when they are locked/asleep, and will often even stop listening on the AWDL social channels when there are no services being advertised or in use.
> All iOS devices are constantly receiving and processing BLE advertisement frames like this. In the case of these AirDrop advertisements, when the device is in the default "Contacts Only" mode, sharingd (which parses BLE advertisements) checks whether this unsalted, truncated hash matches the truncated hashes of any emails or phone numbers in the device's address book.
Then follows the section on brute-forcing 2 bytes (only) of a SHA256 hash.
Spray noise on channels 6 and 44?
If you turn AirDrop/Bluetooth off, you may well disable this.
On my phone:
- If you disable Bluetooth in the notification tray, then it goes to Bluetooth "Not Connected", but not Off. - If you disable Bluetooth in settings, AirDrop automatically goes into "Receiving Off". - If you then enable AirDrop, it'll automatically turn Bluetooth on.
So I don't think it's true that you can't disable it - unless the UI is misleading about Off.
Apparently Apple failed in their hiring process to get those mythical developers that never write such kind of errors in production C or C++ code. /s
> Vulnerability discovery remains a fairly linear function of time invested. Defeating mitigations remains a matter of building a sufficiently powerful weird machine. Concretely, Pointer Authentication Codes (PAC) meant I could no longer take the popular direct shortcut to a very powerful weird machine via trivial program counter control and ROP or JOP. Instead I built a remote arbitrary memory read and write primitive which in practise is just as powerful and something which the current implementation of PAC, which focuses almost exclusively on restricting control-flow, wasn't designed to mitigate.
Signed pointers are just a mitigation. With enough time to find other primitives/constructs (from less severe but more common bugs) you will work around them.
I'm reminded of ye olde Gumstix BlueSniper rifle. Back in the early 2000's there were a series of exploits against bluetooth stacks. The standard response by the industry was that they attacks weren't practically exploitable due to the low power of typical bluetooth devices.
The BlueSniper was a cantenna + gumstix SBC specifically constructed for the purpose of demonstrating the low cost of the threat.
Think about it, an ocean of electrons in the copper WiFi antenna bump along with a certain guiding EM wave and in so doing, they inadvertently cause the information moving electrons in the silicon crystal to disconnect from the electrons being pushed out of the Li-ion battery.
This amplitude fluctuation in principal could have been broadcast by motions of stars in the universe, as astronomy does peer into the deep with these frequencies [0].
In the future, one could imagine a bad actor with control over a global network of low orbit satellites spewing out this code for decades preventing the such devices from being turned on long enough to receive updates, deactivating billions of dollars of human capital.
[0]: http://www.astrosurf.com/luxorion/radioastro-frequencieslist...
[1] https://github.com/apple/llvm-project/blob/73ea7cb9eba3196ae...
Holy shit.
