Jeff Johnson

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/ 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:…

In a sense Mastodon reminds of the very early stages of Twitter, where there was mostly no toxicity and people were mostly kind and willing to participate in civilized discussions. Hopefully this will continue that way for longer time, given the get-popular-quick schemes that worked on Twitter don't tend to work in Mastodon.

But be careful of the server you choose. I submitted this some days ago to see what people think, albeit it got no traction, so I'll put again here just in case:

https://lapcatsoftware.com/articles/mastodon2.html

If switching servers is not made painless and straightforward, we'll end up having a single, mostly trusted, mostly centralized server (whatever that happens to end up being), because nobody wants to see themselves in the situation of losing their accounts on a server that seemed to be trustworthy. And also nobody wants to put on themselves the burden of having to make a full research on the viability of each and every potential server that they might want to use, that's something that shouldn't be a problem solved by individual users, but a problem solved by the service itself, somehow. A Covenant is far from enough.

Thank you for pointing this out.

The macOS appocalypse was a really shocking moment -- it was so disappointing to learn that despite the privacy marketing shtick, macOS engineers chose to have Macs phone home sensitive data in an seemingly aggressive way, with no opt out. Now in 2023 the fact that "A new preference for users to opt out of these security protections" never materialized is also super disappointing. Great write up here [0] - thanks @lapcat!

Anecdata: Ever since that day I've blackholed ocsp.apple.com/ocsp2.apple.com at the DNS level, and all my Mac apps have launched just fine since.

If anyone at Apple reads this, I want to be given the choice. Warn me, stuff it into whatever plist, CLI edit only -- whatever, but just let me decide.

For a company with Apple's resources, it's hard to believe the OCSP test suite somehow didn't consider half-open TCP connections. If a global catastrophe like that can happen once, it can happen again - this is why, in addition to the privacy implications, Apple should IMO give us a clear opt-out.

[0] https://lapcatsoftware.com/articles/ocsp.html

This "warning" by Rixstep is pure FUD.  Rixstep are kind of like the trolls of the Apple development community.  They regularly publish "industry watch warnings" about changes in the Mac development ecosystem that are factually incorrect at best, and are intentionally misleading to imply that Apple is killing off Mac development.

I don't think anyone takes these guys seriously. Many Mac developers get upset at Rixsteps's constant barrage of fear-mongering, lies and factually incorrect "technical articles" (that are designed to make it look like the Mac SDKs are incapable of doing basic things, which they can actually do quite well).

A few random complaints pulled from Google:

http://www.bynkii.com/archives/2007/12/no_in_fact_i_dont_think_ill_be.html

http://lapcatsoftware.com/blog/2008/02/02/fud-from-rixstep-nsdocumentcontroller-in-leopard/

http://forums.macrumors.com/showthread.php?t=208976

There's even a "Fake Rixstep" web site similar to Fake Steve Jobs that attempts to reveal through satire what sort of people these are:

 http://thefakerixstep.blogspot.com/

The "not a fan of passkeys" link toward the bottom is a great read [1].

It mentions: As far as Apple is concerned, I would be satisfied if passkeys could be saved in a local, non-iCloud keychain, as normal keychain items with support for export and import. Ideally, the export format would be cross-platform, and I don't see why it couldn't be cross-platform, given that passkeys are just public-private key pairs tied to a domain. In that case, I would be happy to eliminate web passwords, since I already use randomly-generated, keychain-managed web passwords that can't be memorized (by me). Unless and until Apple provides such a solution, though, I remain extremely skeptical of passkeys and feel inclined to fight back against the notion of replacing and eliminating passwords.

[1]: https://lapcatsoftware.com/articles/2023/5/1.html

Would it be possible/viable for a third party to release such a piece of software? Does one already exist?

Speaking of macOS's firewall being broken, there's a bug (or "feature"?) in the NetworkExtension framework which causes connections to get initiated (SYN, leaks your IP address) even if there's an explicit rule to deny that connection. This affects LittleSnitch, Lulu, and all the other apps building on top of the framework. Bug reports have been filed and as usual ignored by Apple.

More:

Little Snitch "denied" connections leak your IP address - https://lapcatsoftware.com/articles/2023/3/4.html

Follow-up to Little Snitch "denied" connections leak your IP address - https://lapcatsoftware.com/articles/2023/3/5.html

Little Snitch "denied" connections leak your IP address: Developer response - https://lapcatsoftware.com/articles/2023/6/3.html

https://twitter.com/JiriPospisil/status/1679838397983064064