https://news.ycombinator.com/item?id=15800676 (Anyone can login as root without any technical effort required)
And to top it off (https://news.ycombinator.com/item?id=15828767)
Apple keeps having all sorts of very simple "unbelievable" bugs.
There seems to be kind of a common theme to these:
- SSL certificates not validated at all
- root authentication not validated at all
- JWT token creation for arbitrary Apple ID users not validated at all
I think these are all very likely due to error and not malice, but it's pretty crazy how these gaping holes keep being found.
(The session itself was ok-ish. It was some trainings about xsrf, nothing special either)
(That incident also triggered me to purchase a sheet of [citation needed] stickers from xkcd to put on my laptop, so the next time this kind of thing happens I can just point to the sticker on my laptop. But I didn't got a chance to do that yet since received the stickers)
Apple pioneered usable security with TouchID and the secure enclave; a lot of Android fingerprint readers were gimmicks for years, same with the face unlocks. https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/app...
They also invest piles of money into privacy https://apple.com/privacy (1 minute overview), https://apple.com/privacy/features (in-depth with links to whitepapers).
I imagine that's where your teacher was coming from.
Regarding security, see examples like https://qz.com/1844937/hong-kongs-mass-arrests-give-police-a...
Google doesn't have the intention to keep all your data private, sure. They are an ads company after all. But for things they want to protect, in most cases they are competent enough to protect them.
(Disclaimer: I also worked for Google, but the "employer" I mentioned in my original comment was not Google)
I think it’s too early to claim anything for that one.
I hired a very high level pen test company, they mandated iPhones for their company work. They were the best infosec company we’ve ever hired. Sample of one.
I wouldn’t suggest iPhones are more safe than Android, but i also wouldn’t suggest in any way they are less safe overall.
It is extremely frustrating. Especially when Catalina removes features that were working perfectly.
I’ll upgrade when some piece of software I need to use requires it.
I have an iMac that uses it and a Mac Mini that is on Mojave and for some reason, High Sierra just feels more stable with some software.
Firefox runs fine on High Sierra and has crashed multiple times in the past few weeks after using it on Mojave.
Maybe I'm just biased having used High Sierra for so long and dreading Catalina lol.
But I’m not aware of any new feature in Mojave I want or need, so the 2013 MacBook Pro Retina I’m using will stay on High Sierra for today :)
It's just that so far, only Twitter has bothered to do so on Mac. Even software like Slack which does so for iOS just hasn't bothered to port that code to their Mac app - most likely because of the Mac app using a different Electron-based codebase.
The whole pro-multimedia production crowd probably cares...
(vs the current Apple paramour: the multimedia consumer who wants to order pizza and get back to netflix on their phablet or whatever..)
They are the Nintendo of Computing. They have some novelties, but in general they are average at their best. Notice that both Nintendo and Apple are big advertisers.
If that's it, it's about as bad as doing password authentication in JavaScript and passing authenticated=true as a request parameter.
Edit: Looking at the OAuth picture in the article, my guess would be like adding a step in between 1 and 2 where the server says "what email address do you want here" and the (client on the) user side is responsible for interacting with the email relay service and posting back with a preferred email address. Or the server does it but POSTS back to the same endpoint which means the user could just include whatever they want right from the start.
The only thing that makes me think I might not be right is that doing it like that is just way too dumb.
AND I'm guessing a bunch of Apple services probably use OAuth amongst themselves, so this might be the worst authentication bug of the decade. The $100k is a nice payday for the researcher, but I bet the scope of the damage that could have been done was MASSIVE.
Edit 2: I still don't understand why the token wouldn't mainly be linked to a subject that's a user id. Isn't 'sub' the main identifier in a JWT? Maybe it's just been too long and I don't remember right.
The details are very sparse in the post, but I believe the "sub" claim is a unique and stable value for the user against a particular relying party (based on that being a requirement in OpenID Connect.)
You _should_ be relying on sub rather than email address, which is not guaranteed to be sent every time, to stay stable, or be unique across accounts.
So while this was a zero day in terms of providing arbitrary email addresses as verified addresses, it may have not led to any account compromises.
1. Don't add these.
2. If you must add something, structure it so it can only exist in test-only binaries.
3. If you really really need to add a 'must not enable in prod' flag then you must also continuously monitor prod to ensure that it is not enabled.
Really hoping they follow up with a root-cause explanation.
Took about two years to fix. Gave me credit. No money.
I'm not surprised here.
They basically made a huge fundamental design mistake.
Sometime code review is just "Please change the name of this function" and testing is just testing the positive cases not the negative ones. Yes, even in companies like apple and google.
At least from the writeup, the bug seems so simple that it is unbelievable that it could have passes a code review and testing.
I suspect things were maybe not as simple as explained here, otherwise this is at the same incompetence level as storing passwords in plaintext :O.