Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zero-day in Sign in with Apple

bhavukjain.com

Post reply on HN
Print view View original

151–160 of 280 posts

Re: Zero-day in Sign in with Apple

#151

Post by hootbootscoot »

ksec wrote: post #100
SaltyBackendGuy wrote: post #95

Earlier quoted context omitted.

Anecdotally, I upgraded my wife's iMac to Catalina and she's experiencing issues (rendering latency) she's never had before (hadn't upgraded the OS since buying it 4 years ago). I figured is was good to get on the latest and greatest for security reasons, now she wont let me touch her computer anymore.

I used to be on the latest and security camp as well. But after all these years I am starting to understand why people dont update. It is extremely frustrating. Especially when Catalina removes features that were working perfectly.

I'm about this close to making an e-petition demanding Snow Leopard FOSS for posterity, now that they have successfully milked us all multiple times. My 2011 hardware works just fine, and 'obsolete' is meaningless in a world where IRC was replaced by Slack and where Visual Basic tutorial fodder from 1998 become MVP web products...

Re: Zero-day in Sign in with Apple

#152

Post by hootbootscoot »

iphone_elegance wrote: post #92
Jaxkr wrote: post #79

Earlier quoted context omitted.

Apple has really lost their touch, software quality has declined dramatically

does it really matter though?

Someone with an AV production studio totalling over $100k in Apple products and a few million in outboard gear whose drivers worked fine before may just care a bit...

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..)

Re: Zero-day in Sign in with Apple

#155

Post by arcdigital »

mazeltovvv wrote: post #144

This is an amazing bug, I am indeed surprised this happened in such a critical protocol. My guess is that nobody must have clearly specified the protocol, and anyone would have been able to catch that in an abstracted english spec. If this is not the issue, then the implementation might be too complex for people to compare it with the spec (gap between the theory and the practice). I would be extremely interested in…

For #3 it's part of the JWT ID Token. Take a look at https://openid.net/specs/openid-connect-core-1_0.html#Hybrid...

Re: Zero-day in Sign in with Apple

#156

Post by thephyber »

Areading314 wrote: post #90
_23sd wrote: post #78

Earlier quoted context omitted.

Even if there was clear evidence that this system underwent a proper security audit, with a failure this basic you would have to ask why it didn't work. What is going on inside Apple that brought them to the point of releasing a lock that simply opens with any key, despite the efforts of their state of the art lock design process and qualified lock auditors?

Writing some test cases for "can anyone generate a valid token" or "does an invalid token allow access" should be the first thing to do when writing an auth system.

Your test cases make sense, but they ignore an obvious hypothetical possibility: The OIDC implementation was a well-tested core feature (with the tests that you mention), but the email proxy feature was a bolt on that was somehow not considered risky (so it could easily have bypassed a full, renewed security audit).

Also, it's not sufficient to "have a test case". The intent and the implementation must be coherent.

Re: Zero-day in Sign in with Apple

#158

Post by Ronnie76er »

Just want to mention something about the id_token provided. I'm on my phone, so I don't have apples implementation handy, but in OIDC, the relying party (Spotify for example) is supposed to use the id_token to verify the user that is authenticated, specifically the sub claim in the jwt id_token.

https://openid.net/specs/openid-connect-core-1_0-final.html#...

It's likely (although like others have noted, this is scant on details), that this value was correct and represented the authenticated user.

A relying party should not use the email value to authenticate the user.

Not contesting that this is a bug that should be fixed and a potential security issue, but perhaps not as bad.

Anyone else? Am I reading this right?

Re: Zero-day in Sign in with Apple

#159

Post by lordofmoria »

ani-ani wrote: post #43

" Apple also did an investigation of their logs and determined there was no misuse or account compromise due to this vulnerability. " Given the simplicity of the exploit, I really doubt that claim. Seems more likely they just don't have a way of detecting whether it happened.

I agree, especially given how many developer “eyes” were on this from having to integrate the log in with Apple flow into their apps.

Just as a first-hand anecdote to back this up, a dev at my former company which did a mix of software dev and security consulting found a much more complex security issue with Apple Pay within the first hour of starting to implement the feature for a client and engaging with the relevant docs.

How did no one else notice this? The only thing I can think of is the “hidden in plain sight” thing? Or maybe the redacted URL endpoint here was not obvious?

Re: Zero-day in Sign in with Apple

#160

Post by dandigangi »

I always have a minute of nervousness while I read these security posts hoping that the bottom will say it's already been fixed with XYZ security team. Glad it's fixed w/ Apple already. The "they still haven't fixed it" or "still haven't responded" ones are scary.
Post reply on HN