"This research resulted in 4 0day bugs (CVE-2021-30861, CVE-2021-30975, and two without CVEs), 2 of which were used in the camera hack. I reported this chain to Apple and was awarded $100,500 as a bounty."
Writing a secure browser for today's web appears to be a technological challenge comparable to a level 5 self-driving car. It has not been shown to be feasible. So such cars are not permitted to be deployed on the world's roads. Today's web sites and browsers should similarly not be deployed on the world's infobahns.
To be fair level 5 self driving car failing is much more catastrophic than a browser being hijacked. But I generally agree with your sentiment.
Unfortunately the only way to find these modes of failure is to have them actually fail. It's impossible to design and release an error free system without real world usage from real people.
It doesn't mean we should just give up and go back to HTML1 though. It just means exploits should be fixed as soon as possible to minimize damage.
And tbh, our browsers today are remarkably secure compared to before. It used to be just common advice to never open weird emails or click weird links, not because they would try to trick you in to handing over info, but because it was realistic that simply clicking the link or opening the email would immediately rootkit your computer. These days unless you are a government most wanted or using a very old system, you are pretty safe.
We used to have school kids coming up with highly privileged attacks on systems to it becoming something the top minds spend months on and get paid 6 figures per discovery for.
There is no need to fall back to HTML1. Before HTML5 and even before HTML4, there was a web markup language that was much more powerful than HTML1, was widely deployed and used, did everything we needed, and worked fine. It was called HTML3 and it was great. That is where we should be right now.
The old web I remember had exploits from flash, java applets, active-x, shockwave, other sketchy plugins people willingly downloaded to access sites, and poorly sandboxed javascript that could take control of your browser window to resize, move, and spam as many popups as it wanted among other worse things. And downloaded "toolbars", https being rarely used, etc.
Even ad blockers and other "power user" extensions (if your browser even offered that) were extremely primitive. etc.
There were websites that could execute user land code through exploits just by visiting a website depending on your browser. And that wasn't uncommon.
It would be completely insane if that was still the case today. But we fixed those issues and evolved.
OP's post shows a major issue obviously. But I would absolutely turn off the entire api with a forced update until it was fixed if I had the power to.
But these sorts of exploits happened back in the day to a worse degree with HTML3 + 4 (can't speak for 1 or 2 though, maybe someone can chime in).
Viewing the bigger picture, the web is way more secure now than back then. And exploits like these are much more rare now.
Maybe if vendors were more open to allowing third-party applications on their platform, people wouldn't be so motivated to increasing the capabilities of the web. Instead, app distribution has turned into a living nightmare, so it's unsurprising to see the web evolved into the monster it is today.
I think what you have said is in many ways very true, a modern web browser is in many ways comparable to an operating system and even more so with Chrome's push into new APIs that do things like access local file systems for example.
It seems that we need a better story for when code inevitably can escape the sandboxing that browsers provide because right now it's a straight up disaster scenario. That means you are going to have to rethink the OS underlying it and none of today's options were built with that kind of a threat model in mind.
There is Fuchsia on the horizon which sounds like a MAJOR leap forward but that also seems like it is several years away from ever reaching a desktop for example and it's also really unclear what kind of attacks are going to be possible in the real world against it either.
How does the economy of bug bounty programs work for the company? $100,500 is probably not much for Apple but it's still some engineer's salary. Do the responsible engineer get a pay cut for this bug? Or this kind of 0day bugs are not bugs, but secret features left open from the beginning?
This time, the bug gives the attacker full access to every website ever visited by the victim. That means in addition to turning on your camera, my bug can also hack your iCloud, PayPal, Facebook, Gmail, etc. accounts too.
Agreed, of all the places you could have sold that information the official channel by FAR pays the worst (Apple in particular being a notoriously terrible company to deal with for security problems but by no means are the only ones) which is a huge problem that people should be making a lot more noise about.
I kind of shudder to think of how many of these bugs have been out there for years and only ever ended up in the hands of governments and shady groups like NSO.
I found a bug in Cash App that exposes SSNs, but their max bug bounty is $8000, so fuck 'em. The other option for people finding bugs is to sell it to "the other side" if they pay more money.
No. Fuck-em would be actually selling it, not throwing a hissy fit and publicly outing yourself as potential source of the discovery. They DGAF about that bug, their only concern is very low probability of negative consequences in case of data leak with full attribution, but bugcrowd presence gives CISO full ass coverage.
I have not heard of companies who operate bug bounties punishing engineers. Apple certainly does not do this either. Most companies do the math and decide that it's cheaper for them to deal with paying a research than it is to deal with the possible fallout of an in-the-wild exploit or researchers just dumping zero days on twitter.
A bounty incentivizes people — bad actors included — to responsibly disclose critical bugs. It has the side effect of luring in good actors to find them, but the cost remains negligible compared to the damage they might cause otherwise.
This is overhead; cost of doing business. Finding out you have a bug so you can fix it is much cheaper than not finding out until your customers have been attacked. Trying to get those customers back or get new customers is much much more expensive.
There are certainly much worse bugs than $100k. Think of if Apple itself had been hacked due to a bug. The remediation costs would be very high.
A bug in Knight Capital's stock trader lost $460M in 45 minutes.
A bug in the Ariane 5 rocket caused it to crash, a loss of $370M.
A bug in the Therac-25 radiation machine killed 3 people.
secret features left open from the beginning?
Are you saying Apple engineers are inserting backdoors? What's the motivation? Security bugs are very easy to accidentally introduce when you have complex interacting systems (in this case a browser, a complicated URL parsing syntax, some ancient barely-known file types, and a file sharing application). Occam's razor (and Hanlon's) says it's an accident.
The frustrating thing is that we know how to write absolutely secure browsers (or other executors/renderers/etc. of untrusted data) using formal methods. Unfortunately, because most of the negative externality falls on users who don't know any better, the economics don't really work out.
You can prove a TLS implementation correct up to defined assumptions (e.g. clock consistency). There are already some projects working on this, eg https://project-everest.github.io/
Unlikely... these bugs are all logic bugs. They won't be mitigated by using formal methods, because most of these bugs adhere to pre-defined specs. The problem with browses is that these specs are often in conflict with each other for new and/or obscure features.
"Writing a web browser for today's web appears to be a technological challenge comparable to a level 5 self-driving car."
Only when the "constraints" are that the browser must support all "standards" produced by some committee where most if not all memebers are employees of the few browser vendors or other "tech" companies heavily invested in the web. Perhaps that is what is meant by "today's web".
I use a netcat and similar TCP clients and a text-only browser on today's web and this works quite well for mine own purposes. Non-commercial use. Basic tasks like sending GET and POST requests, downloading pages and other resources and reading them. Using the web as an information source. I would be willing to bet these programs are "more secure" than the "modern web browser". They are certainly less complex.
I use a netcat and similar TCP clients and a text-only browser on today's web and this works quite well for mine own purposes.
For 99% of what I do I use Firefox + NoScript and I think I'm relatively secure. My solution probably provides more functionality than yours, but it's still a hassle to use some sites. Other sites simply don't exist w/o JavaScript. The situation isn't getting better.
Any chance could disclose the ones that "simply don't exist w/o Javascript". (Assuming they are information sources, not online games or otherwise purely interactive.) I have had reasonably consistent success finding workarounds for sites that gratuitously use Javascript to present information.
And of course Google really really wants JS to make it easier for them to spy on you. Youtube isn't useful w/o JS (but IIRC it used to at least somewhat function): https://www.youtube.com/ Fortunately search still works.
Twitter are twats and broke all functionality w/o JS, but nitter.net is a workaround! Just replace twitter.com with nitter.net to see the tweet.
Fortunately many sites that start out blank are quite functional w/o JS, just need to View -> Page Style -> No Styles. E.g. this one: https://www.politico.com/ ugly but readable.
However when I checked archive.org I noticed their archived page was different. It appeared to require Javascript.
YouTube
I use YouTube without any JS.^1 I search from the command line using a tiny shell script. I download from the command line using a tiny shell script. With few exceptions I do not use youtube-dl.^1
1. Only exceptions are videos with a dynamic sig value in their googlevideo.com URL. Most videos I watch have static sig values in their googlevideo.com URL. Alternatively, I can use a "modern browser" to get the googlevideo.com URLs to download these videos, with all the tracking and other non-essential URLs blocked (no ads), instead of youtube-dl.
Twitter
I read Twitter without any JS. It currently works fine for me using links(1). I have a tiny shell script to download an entire feed if I need to find some historical tweet. Twitter does make changes from time to time. Previously I had to use the GraphQL API. Not anymore.
I agree 100% that the web of gratuitous JS sucks, but even with TCP clients and a text-only browser that do not run Javascript, I encounter few problems reading the textual information and/or downloading the binary files (resources) that websites provide.
For example, of the 43 open working groups at W3C, "Google LLC" has representatives participating in 36 out of the 43. Of the 89 closed former working groups at W3C, "Google LLC" has had representatives formerly particpating in 54 out of the 89. Source: https://www.w3.org/groups/wg/
This is such an unreasonable and paranoid set of trade offs.
You could have gotten basically the same (I would even argue better) level of security with a virtual machine and an otherwise full browsing experience.
I do not use this method for security. I use it for speed, reliability and aesthetics. The complexity fetish of too many software developers has driven me to appreciate minimalism.
Also, the computers I use are often older, underpowered and/or have limited resources. Running VMs is usually not an option. You cannot assume that everyone has the free overhead available to run VMs.
The large, graphical browsers controlled by corporations are slow, unwieldy and overkill for making simple HTTP requests. The "full browsing experience" is highly unsatisfactory for me. I am not "trading off" anything. I like fast, text-only information retrieval.
That said, the statement I made still stands. Using TCP clients and a text-only HTML reader is probably "more secure" than using one of the corporate graphical browsers that allow users to do more dangerous things. A side benefit.
Comments
Writing a secure browser for today's web appears to be a technological challenge comparable to a level 5 self-driving car. It has not been shown to be feasible. So such cars are not permitted to be deployed on the world's roads. Today's web sites and browsers should similarly not be deployed on the world's infobahns.
To be fair level 5 self driving car failing is much more catastrophic than a browser being hijacked. But I generally agree with your sentiment.
Unfortunately the only way to find these modes of failure is to have them actually fail. It's impossible to design and release an error free system without real world usage from real people.
It doesn't mean we should just give up and go back to HTML1 though. It just means exploits should be fixed as soon as possible to minimize damage.
And tbh, our browsers today are remarkably secure compared to before. It used to be just common advice to never open weird emails or click weird links, not because they would try to trick you in to handing over info, but because it was realistic that simply clicking the link or opening the email would immediately rootkit your computer. These days unless you are a government most wanted or using a very old system, you are pretty safe.
We used to have school kids coming up with highly privileged attacks on systems to it becoming something the top minds spend months on and get paid 6 figures per discovery for.
Excellent perspective, thanks for the positive and factual viewpoint
There is no need to fall back to HTML1. Before HTML5 and even before HTML4, there was a web markup language that was much more powerful than HTML1, was widely deployed and used, did everything we needed, and worked fine. It was called HTML3 and it was great. That is where we should be right now.
You might be wearing rose colored glasses here...
The old web I remember had exploits from flash, java applets, active-x, shockwave, other sketchy plugins people willingly downloaded to access sites, and poorly sandboxed javascript that could take control of your browser window to resize, move, and spam as many popups as it wanted among other worse things. And downloaded "toolbars", https being rarely used, etc.
Even ad blockers and other "power user" extensions (if your browser even offered that) were extremely primitive. etc.
There were websites that could execute user land code through exploits just by visiting a website depending on your browser. And that wasn't uncommon.
It would be completely insane if that was still the case today. But we fixed those issues and evolved.
OP's post shows a major issue obviously. But I would absolutely turn off the entire api with a forced update until it was fixed if I had the power to.
But these sorts of exploits happened back in the day to a worse degree with HTML3 + 4 (can't speak for 1 or 2 though, maybe someone can chime in).
Viewing the bigger picture, the web is way more secure now than back then. And exploits like these are much more rare now.
Maybe if vendors were more open to allowing third-party applications on their platform, people wouldn't be so motivated to increasing the capabilities of the web. Instead, app distribution has turned into a living nightmare, so it's unsurprising to see the web evolved into the monster it is today.
I think what you have said is in many ways very true, a modern web browser is in many ways comparable to an operating system and even more so with Chrome's push into new APIs that do things like access local file systems for example.
It seems that we need a better story for when code inevitably can escape the sandboxing that browsers provide because right now it's a straight up disaster scenario. That means you are going to have to rethink the OS underlying it and none of today's options were built with that kind of a threat model in mind.
There is Fuchsia on the horizon which sounds like a MAJOR leap forward but that also seems like it is several years away from ever reaching a desktop for example and it's also really unclear what kind of attacks are going to be possible in the real world against it either.
How does the economy of bug bounty programs work for the company? $100,500 is probably not much for Apple but it's still some engineer's salary. Do the responsible engineer get a pay cut for this bug? Or this kind of 0day bugs are not bugs, but secret features left open from the beginning?
Honestly, $100,000 for this is too low.
Agreed, of all the places you could have sold that information the official channel by FAR pays the worst (Apple in particular being a notoriously terrible company to deal with for security problems but by no means are the only ones) which is a huge problem that people should be making a lot more noise about.
I kind of shudder to think of how many of these bugs have been out there for years and only ever ended up in the hands of governments and shady groups like NSO.
I found a bug in Cash App that exposes SSNs, but their max bug bounty is $8000, so fuck 'em. The other option for people finding bugs is to sell it to "the other side" if they pay more money.
https://bugcrowd.com/cashapp
No. Fuck-em would be actually selling it, not throwing a hissy fit and publicly outing yourself as potential source of the discovery. They DGAF about that bug, their only concern is very low probability of negative consequences in case of data leak with full attribution, but bugcrowd presence gives CISO full ass coverage.
This bug would, in the wrong hands, let someone steal a lot more than $100k.
It should be at least 10x higher, this bug affects a billion users
I have not heard of companies who operate bug bounties punishing engineers. Apple certainly does not do this either. Most companies do the math and decide that it's cheaper for them to deal with paying a research than it is to deal with the possible fallout of an in-the-wild exploit or researchers just dumping zero days on twitter.
A bounty incentivizes people — bad actors included — to responsibly disclose critical bugs. It has the side effect of luring in good actors to find them, but the cost remains negligible compared to the damage they might cause otherwise.
This is overhead; cost of doing business. Finding out you have a bug so you can fix it is much cheaper than not finding out until your customers have been attacked. Trying to get those customers back or get new customers is much much more expensive.
There are certainly much worse bugs than $100k. Think of if Apple itself had been hacked due to a bug. The remediation costs would be very high.
A bug in Knight Capital's stock trader lost $460M in 45 minutes.
A bug in the Ariane 5 rocket caused it to crash, a loss of $370M.
A bug in the Therac-25 radiation machine killed 3 people.
Are you saying Apple engineers are inserting backdoors? What's the motivation? Security bugs are very easy to accidentally introduce when you have complex interacting systems (in this case a browser, a complicated URL parsing syntax, some ancient barely-known file types, and a file sharing application). Occam's razor (and Hanlon's) says it's an accident.
Apple’s Q4 2022 net profit was 20 billion US dollars.
They can afford the bounty.
The frustrating thing is that we know how to write absolutely secure browsers (or other executors/renderers/etc. of untrusted data) using formal methods. Unfortunately, because most of the negative externality falls on users who don't know any better, the economics don't really work out.
I'm not sure you can actually prove a TLS implementation is correct. It depends on the system clock being right, OCSP server being online, etc.
Even the encryption has to be free of side channels like timing attacks which are left out of what most people think of as a proof.
You can prove a TLS implementation correct up to defined assumptions (e.g. clock consistency). There are already some projects working on this, eg https://project-everest.github.io/
Unlikely... these bugs are all logic bugs. They won't be mitigated by using formal methods, because most of these bugs adhere to pre-defined specs. The problem with browses is that these specs are often in conflict with each other for new and/or obscure features.
Logic bugs are the primary category of bugs targeted by heavyweight formal methods.
Most JS features don't even have a formal spec which is part of the problem.
"Writing a web browser for today's web appears to be a technological challenge comparable to a level 5 self-driving car."
Only when the "constraints" are that the browser must support all "standards" produced by some committee where most if not all memebers are employees of the few browser vendors or other "tech" companies heavily invested in the web. Perhaps that is what is meant by "today's web".
I use a netcat and similar TCP clients and a text-only browser on today's web and this works quite well for mine own purposes. Non-commercial use. Basic tasks like sending GET and POST requests, downloading pages and other resources and reading them. Using the web as an information source. I would be willing to bet these programs are "more secure" than the "modern web browser". They are certainly less complex.
I use a netcat and similar TCP clients and a text-only browser on today's web and this works quite well for mine own purposes.
For 99% of what I do I use Firefox + NoScript and I think I'm relatively secure. My solution probably provides more functionality than yours, but it's still a hassle to use some sites. Other sites simply don't exist w/o JavaScript. The situation isn't getting better.
Any chance could disclose the ones that "simply don't exist w/o Javascript". (Assuming they are information sources, not online games or otherwise purely interactive.) I have had reasonably consistent success finding workarounds for sites that gratuitously use Javascript to present information.
So many sites.
For example much of MSN is totally non-functional w/o Javascript. E.g. this brings up a totally blank page: https://www.msn.com/en-us/news/us/they-had-covid-19-once-the...
And of course Google really really wants JS to make it easier for them to spy on you. Youtube isn't useful w/o JS (but IIRC it used to at least somewhat function): https://www.youtube.com/ Fortunately search still works.
Twitter are twats and broke all functionality w/o JS, but nitter.net is a workaround! Just replace twitter.com with nitter.net to see the tweet.
Fortunately many sites that start out blank are quite functional w/o JS, just need to View -> Page Style -> No Styles. E.g. this one: https://www.politico.com/ ugly but readable.
MSN
Hmmm, I got the full text of the article, immediately readable with links(1), no problem using netcat or, e.g., curl.
NB. Unless required, I never send a user-agent header. Here, as is the case with 99% of the sites I visit, it was not required.
To watch the video, I used ffmpeg to save to an MP4 file:
However when I checked archive.org I noticed their archived page was different. It appeared to require Javascript.YouTube
I use YouTube without any JS.^1 I search from the command line using a tiny shell script. I download from the command line using a tiny shell script. With few exceptions I do not use youtube-dl.^1
1. Only exceptions are videos with a dynamic sig value in their googlevideo.com URL. Most videos I watch have static sig values in their googlevideo.com URL. Alternatively, I can use a "modern browser" to get the googlevideo.com URLs to download these videos, with all the tracking and other non-essential URLs blocked (no ads), instead of youtube-dl.
Twitter
I read Twitter without any JS. It currently works fine for me using links(1). I have a tiny shell script to download an entire feed if I need to find some historical tweet. Twitter does make changes from time to time. Previously I had to use the GraphQL API. Not anymore.
I agree 100% that the web of gratuitous JS sucks, but even with TCP clients and a text-only browser that do not run Javascript, I encounter few problems reading the textual information and/or downloading the binary files (resources) that websites provide.
For example, of the 43 open working groups at W3C, "Google LLC" has representatives participating in 36 out of the 43. Of the 89 closed former working groups at W3C, "Google LLC" has had representatives formerly particpating in 54 out of the 89. Source: https://www.w3.org/groups/wg/
This is such an unreasonable and paranoid set of trade offs.
You could have gotten basically the same (I would even argue better) level of security with a virtual machine and an otherwise full browsing experience.
You have assumed wrong.
I do not use this method for security. I use it for speed, reliability and aesthetics. The complexity fetish of too many software developers has driven me to appreciate minimalism.
Also, the computers I use are often older, underpowered and/or have limited resources. Running VMs is usually not an option. You cannot assume that everyone has the free overhead available to run VMs.
The large, graphical browsers controlled by corporations are slow, unwieldy and overkill for making simple HTTP requests. The "full browsing experience" is highly unsatisfactory for me. I am not "trading off" anything. I like fast, text-only information retrieval.
That said, the statement I made still stands. Using TCP clients and a text-only HTML reader is probably "more secure" than using one of the corporate graphical browsers that allow users to do more dangerous things. A side benefit.
To each their own.