
Disclosure: Another macOS privacy protections bypass - sillysaurusx
https://lapcatsoftware.com/articles/disclosure2.html
======
aboringusername
> I'm not interested in waiting years for a bounty. I can't speak for anyone
> else, but my personal experience is that the Apple Security Bounty Program
> has been a disappointment, and I don't plan to participate again in the
> future.

Yeah...Hint to Apple: When somebody discloses something, responsibly, you
react to that with a proper process and understand you get 90 days in most
cases as is industry standard (that's typically how Google Project Zero
operates).

Otherwise don't be surprised when exploits end up sold for much more on a
black market because nobody wants to cooperate with you.

Think we need a few more 0-days that cost Apple a few bad PR spins (as well as
others like Valve) to make them wake up and actually have a proper process.

~~~
rydre
I can confirm this! Back in 2017, I was 17 and found a flaw that affected the
privacy of all browsers and required a web standards change. Google/Chromium
(Andrew R. Whalley) paid me a good bounty for that, but Apple (mac, ios,
iphone, watch) didn't pay. I didn't expect Mozilla to pay obviously since they
were non profit.

~~~
3pt14159
What was the exploit? I've been sitting on one that's essentially as old as
the web but I figured it was pointless to try to alert browers about it
because too much functionality rests on it.

~~~
XCabbage
Don't tease us - what was _your_ exploit? Just from the description, I'm happy
taking a guess that this is going to involve somehow exploiting the browser
cache (e.g. via timing how long it takes to request an image from another
domain that may or may not have previously been cached) to determine whether
the user has visited a page. That was first written up by academics decades
ago, and has since been independently invented by several people (me
included), but wasn't fixed as of whenever I last checked a couple of years
ago.

Is my wild guess right? :)

~~~
3pt14159
No, though that is a good one.

------
sillysaurusx
_My sample exploit uploads some of your private data (your Top Sites, for
example) to a server that I control, because that 's an easy thing to do when
I can run any JavaScript I want. Note that I'm not really collecting any data,
as [http://lapcatsoftware.com/test/](http://lapcatsoftware.com/test/) is a
dead link. I used http so that you can see the private data being sent in a
packet trace._

Please don't do this when reproducing exploits. Yes, it's just source code,
and yes, the url is dead. But it's still source code that, when compiled, will
grab your real safari data and attempt to upload to a url that could be
switched on.

There's a difference between repro'ing an exploit and weaponizing an exploit.
alert(1) is generally the best thing to aim for, or even alert(some user data)
to illustrate the point. Whereas upload(some user data, my server) is a bit
too close to the moral equivalent of `rm -rf $HOME/*`: all of these illustrate
the point, but rm'ing a homedir is generally not a great thing to have in your
repro; ditto for uploading real user data.

exmaple.com was explicitly reserved for scenarios like this, which would
accomplish the same thing safely.

It may seem like a pedantic point, but it was something I was taught as a
pentester: don't weaponize exploits; simply reproduce them. So my instincts
kicked in, and it's impossible not to mention it. (That said, I don't mean to
make a fuss – it's not a big deal in this case.)

By the way, I found this post via the author's twitter:
[https://twitter.com/lapcatsoftware](https://twitter.com/lapcatsoftware) I've
been following them for about a year now, and their tweets on Mac programming
have been quite informative.

~~~
aidos
No expert, but even example.com isn't totally safe, right? According to the
RFC
([https://tools.ietf.org/html/rfc6761](https://tools.ietf.org/html/rfc6761)),
while these domains are reserved, nothing should treat them specially, so
there's nothing to stop people having them routed somewhere else at the DNS
level.

~~~
gruez
AFAIK the domain is controlled by the IANA, so it's probably not too big of a
security risk. If you really want to be paranoid you can set the site to be
0.0.0.0 or attacker.invalid.

~~~
marcan_42
0.0.0.0 is localhost, which is a great way to allow other software running on
your computer to take the data and send it elsewhere. It's not a great IP
address to use for "invalid".

Yes, 0.0.0.0 really resolves to 127.0.0.1 on Linux at least. Try it.

~~~
oefrha
Not saying 0.0.0.0 should be used in this case, but if you have data sniffing
software listening on port 80 or 443 without your knowledge (or really any
port at all, but especially a privileged port), you probably have much bigger
things to worry about than some ad hoc PoC sending data there.

------
floatingatoll
> _my goal is to show that Apple 's debilitating lockdown of the Mac is not
> justified by alleged privacy and security benefits. In that respect, I think
> I've proved my point_

If every attempt to improve something were disproven by the presence of flaws,
it would disprove all attempts to do anything with software ever. I get that
people don't like the macOS privacy protection efforts, but that's no reason
to construct a logical fallacy.

~~~
lapcatsoftware
It's interesting that you chose to omit "over and over again" from the end of
the quote. I would also mention to this:

> There are two fundamental flaws in TCC that make this exploit possible

We know that TCC is a major burden for legitimate Mac apps. But is it a major
burden for malware? That's the question, and it seems to me the answer is no.
There are so many holes in this system, it only stops the good developers who
wouldn't stoop to using the countless hacks readily available to malware
developers.

~~~
Wowfunhappy
> We know that TCC is a major burden for legitimate Mac apps.

It's a burden for _me_ as a _user!_

My home theater setup is basically just a Mac connected to a projector. Every
button on my Harmony remote runs an Applescript. Many of them start with lines
like:

    
    
        tell application (path to frontmost application) to
    

Every single time a new application is in front when I run a new script,
Mojave and newer pop up a dialog asking if I want to allow _my own script_ to
control the front app, which means I need to get up off my chair and grab a
mouse to click the button. When I edit a script, it usually resets all of the
approvals.

I make very heavy use of Applescript for all sorts of things on my computer.
It's one of the things that has kept me on Mac over the years, because there
is no broadly-supported equivalent on Windows.

I get the sense that no one at Apple uses Applescript much, though, because if
they did, they wouldn't have added an impossible-to-disable feature which
renders it effectively useless.

~~~
tpmoney
No guarantee this will work and I don’t have a machine to test in front of me
but does that still occur if you add your script to either (in order of
likelihood) the Automation, Developer Tools or Accessibility groups in the
Security & Privacy -> Privacy preferences?

~~~
Wowfunhappy
Automation and Accessibility, no. Automation is indeed the relevant panel, but
the white-list is per-app being controlled. There's no way I can tell macOS to
let my script control _any_ app in the automation panel, nor can I even
approve apps ahead of time.

Is Developer Tools new in Catalina, or do I need to install XCode or some such
in order for it to appear? Never saw it in Mojave.

Fwiw, at one point I had a 250 rep bounty on this StackExchange question, and
got nothing. :(

[https://apple.stackexchange.com/questions/339509/edit-tcc-
db...](https://apple.stackexchange.com/questions/339509/edit-tcc-db-to-bypass-
foo-app-wants-access-to-control-bar-app-on-own-machi)

------
cytzol
I commented this on the Big Sur thread last week:

> I was really hoping they'd take some time to address Catalina's glaring
> issues — its slowness, bugginess, just general sloppiness — and instead they
> did the opposite.

I didn't include "security exploits" in that list because _of course_ they're
going to fix security exploits, right? Especially one that they're already
aware of, and can reproduce — they wouldn't just sit on it in favour of making
the UI glossier, right?

Apple have just been getting _so much wrong_ lately. This pretty much dashes
any hopes I had of ever upgrading, because even if this particular flaw gets
fixed by the time Big Sur comes out, there are almost certainly others that
they've ignored. I expected to eventually have to grit my teeth and upgrade so
I wasn't behind on security updates, but I guess that's not the case. Ugh, now
I have to figure out how to mute that annoying (1) in System Preferences. I've
heard they keep making it come back now.

~~~
Wowfunhappy
I shared your concerns prior to trying Big Sur, but in practice I'm somewhat
shocked by how much I like it. Big Sur is _very_ snappy on my aging 2015
Macbook Air, and I've encountered far fewer bugs than I'd expect in an initial
developer preview, which bodes well for the final release.

I like the visuals too, at least compared to Yosemite-era; Leopard-era still
wins out overall. Using the OS has made me feel much better about the Mac as a
platform, although I'm certainly still nervous.

~~~
unicornfinder
Out of curiosity, would you say it's an improvement coming from Catalina? My
confidence in the Mac was really shaken by Catalina but I'm genuinely ready to
be impressed by Big Sur.

~~~
Wowfunhappy
> My confidence in the Mac was really shaken by Catalina.

Same! However, I've never actually used Catalina for a significant period of
time, so I can't compare them directly. I downgraded back to High Sierra after
just using _Mojave_ for a few weeks, partly because I was frustrated with TCC
breaking my scripts, but also because I'd noticed Mojave was slower and
buggier than High Sierra. When Catalina came out and the problem reports
started rolling in, I resolved not to touch it with a ten-foot pole.

I only installed Big Sur because I wanted to try out the new design. I was
fully expecting a dumpster-fire, and I wouldn't have even blamed Apple for it,
given that Big Sur is currently an early developer preview (I was only able to
download it by hacking Apple's catalog URLs). I did _not_ expect to actually
like the Big Sur.

There are a couple of odd bugs that I expect to get ironed out by the fall—for
example, the menu bar sometimes shows a wifi-disconnected icon even when the
internet is working fine. On the whole though, I think the current build of
Big Sur would make for a fine daily driver. (Although it would probably still
be a bad idea if you're working on something important!)

More than anything else—and I know this will be very hardware-specific—I just
can't overstate how _fast_ Big Sur feels. It's really as if I got a new
computer. I will note that I did a clean install, but I do those regularly
anyway, and they don't help all that much.

~~~
cytzol
Thanks for writing this! Honestly, it does make me feel better about the whole
situation.

------
oefrha
> My personal opinion is that macOS privacy protections are mainly security
> theater and only harm legitimate Mac developers while allowing malware apps
> to bypass them through many existing holes such as the one I'm disclosing,
> and that other security researchers have also found. I feel that if you
> already have a hostile non-sandboxed app running on your Mac, then you're in
> big trouble regardless, so these privacy protections won't save you. The
> best security is to be selective about which software you install, to be
> careful to avoid ever installing malware on your Mac in the first place.
> There's a reason that my security research has focused on macOS privacy
> protections: my goal is to show that Apple's debilitating lockdown of the
> Mac is not justified by alleged privacy and security benefits. In that
> respect, I think I've proved my point, over and over again. In any case, you
> have the right to know that the systems you rely on for protection are not
> actually protecting you.

Substitute "security" for "privacy" and you immediately see why the argument
is flawed. "Other people and I have found bugs that bypass security features,
ergo security features are security theater and only harm legitimate
developers. Better have a free-for-all OS and be mindful of what you install."
(Yes, you should be mindful of what you install, regardless.)

~~~
Terretta
Right! Who needs seatbelts or airbags on a car with great brakes -- just be
careful and don't drive into things.

</s>

~~~
lapcatsoftware
This is not a useful analogy. You won't die or be horribly disfigured sitting
at your keyboard. The tradeoffs of driving a car vs using a Mac are very
different. They're not comparable.

~~~
lapcatsoftware
It's strange that the people who disagree with my "security theater" comment
don't seem to be alarmed about the bug I disclosed, which is a very serious
one if you really do believe that macOS privacy protections are important.

------
yardie
> macOS privacy protections are mainly security theater and only harm
> legitimate Mac developers while allowing malware apps to bypass them through
> many existing holes such as the one I'm disclosing

So this is just another abuse of the term "security theatre." Door locks, for
example, are legitimate security. There are plenty of lock picking sets on the
market. But that does not mean door locks do not work. TCC works because a
casual user isn't trying to override it. But if it didn't exist then users
would have no protection at all. It still comes down to the person sitting
behind the computer is in complete command of it. And security knowledge is
the best security you can buy.

~~~
Wowfunhappy
> It still comes down to the person sitting behind the computer is in complete
> command of it.

No I'm not. If I had complete command, I could actually turn off the damn
prompts so my own scripts worked.

~~~
yardie
If you are physically in front of it and have admin privileges there probably
is a non-trivial way to disable those prompts. Disabling SIP and all sorts of
protections is involved.

~~~
Wowfunhappy
I've tried! I keep SIP off anyway, so it's certainly _possible_ , but Apple
neglected to actually give us a mechanism for turning off TCC, and I'm not an
OS developer. There isn't a boot flag, or a process you can disable, or
anything like that.

------
Wowfunhappy
Minor correction for the author, TCC was not introduced in Mojave. It's
actually present on the 10.9 ("Mavericks") machine I'm using right now, where
it controls which apps are allowed to use UI scripting. Like on modern
systems, this is all stored in a database called "tcc.db", and it can be reset
with the Terminal command "tccutil".

This 10.9 incarnation on TCC is much weaker, however. It doesn't apply to most
Apple Events—only UI scripting—and once the user whitelists an application,
that application can control any other app on the machine. Also, because SIP
wasn't introduced until 10.11, there was originally nothing to stop an
application with admin privileges from editing tcc.db directly and
whitelisting itself—as Dropbox later did!

------
bengotow
Wait, so you can just duplicate an app that has more privileges than your app,
modify it, and run it to exploit it's access?

This is a pretty glaring security issue actually - after reading this, it
seems like Apple's choice to track app permissions / security exceptions by
the app's bundle ID and not its file path was a pretty big mistake.

I wonder if this is a case of iOS security engineers working on macOS,
forgetting that app bundle IDs aren't enforced by a central install flow on
the platform?

~~~
saagarjha
File path is wrong, too. What should be checked is the bundle’s code
signature.

~~~
lapcatsoftware
It does check the code signature. However, it's not a "deep check". The
problem with doing a deep check, including all of the apps Resources, is that
this can be very resource intensive, depending on the app. It's the reason why
Xcode takes forever to "verify" on first launch. If there was a deep code
signature check on every TCC check, you would see a lot of very long pauses.

~~~
lapcatsoftware
You can guarantee that the system apps haven't been tampered with, at their
system file paths, because of System Integrity Protection. But all bets are
off if you make a copy of a system app elsewhere on the disk.

~~~
saagarjha
Right, I meant “deep code signature” rather than “executable code signature”,
thanks for the correction. I think macOS has a thing where it only checks the
former the first time you launch an app and not after that, so you can
scribble all over the resources and the system won’t care. Presumably this was
thought to not be a big deal, but you showed a pretty good example of how you
could launch a data-only attack on the privileges associated with the program
:)

------
mindfulhack
> My personal opinion is that macOS privacy protections are mainly security
> theater

I really disagree. This feature has revealed that Google Drive by default
spies on my ~/Downloads folder - something it has no business doing, nor did I
ever intend for it to do.

I actually love the many things Apple are implementing to improve user privacy
from third-party apps and services right now. To an extent, their privacy
brand actually is real, and helpful.

Just don't expect any privacy from Apple themselves (and by extension the
government). At least they help reduce Google and Facebook's rampant
surveillance. That's some good news, in today's era of tech.

------
Spivak
This is a scary exploit. If by modifying a bundle's resources you can coax an
app to do something it shouldn't then an attacker can make a copy of the app
with the malicious resources and assume the full privilege of the app.

Or phrased differently. All installations of the same app have the same
privilege.

------
nwellnhof
Shouldn't 'Safari.app/Contents/Resources/HTMLViewController.js' be codesigned?
Why does Safari launch at all if this file was modified?

~~~
saagarjha
IIRC once an app is launched the resources are not checked again. Let me see
if I can look up if this is documented somewhere.

~~~
jonhermansen
Wouldn't that kinda defeat the whole purpose of signing the app?

~~~
saagarjha
¯\\_(ツ)_/¯

------
Ansil849
Whenever I read an independent disclosure in an area I'm unfamiliar with such
as this, involving the failure of the vendor to engage with the security
researcher , I'm always presented with a parsing dilemma: is the vendor
justified in ignoring the exploit because it is not really as severe as the
author makes it out to be - or is the author correct and this is a serious
vulnerability which the vendor has ignored/let slip through the cracks?

~~~
lapcatsoftware
I'm not even claiming the vulnerability is serious. But when there's a bug
bounty involved, the question is whether the vendor is ever going to pay, or
the vendor is just leading the bug reporter on to keep it quiet for as long as
possible.

~~~
lapcatsoftware
Apple doesn't pay a bounty until after they release a fix. So if Apple decided
to de-prioritize a bug, you never get paid. But Apple doesn't tell if you
they've de-prioritized a bug, they just want you to remain silent forever, and
they say "We're still investigating."

~~~
searchableguy
I don't understand how big companies are always penny-pinchers in this area.
Anyone got a glue?

~~~
Ansil849
My armchair theory is that there is a bit of hubris involved: in-house
developers are hesitant to admit they've been 'bested' by a stranger on the
internet, and so downplay or even just have blinders on against recognizing in
the first place the severity of the issue. Though to be far, I think the
flipside is also at times true - where the independent security researcher
believes the anthill they've found is a mountain.

------
t0mmyb0y
"I didn't expect Mozilla to pay obviously since they were non profit." In 2017
Mozilla made a ton of money off google. Yes, Mozilla makes their money selling
your search.

------
bluesign
This sounds like a bug in safari more than osx tbh.

~~~
fortran77
Can you get a licensed copy of OSX without Safari? If not, it's part of the
OS.

~~~
saagarjha
You can update Safari independently of the OS. It even ships off the read-only
system partition by default.

