You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This change appears entirely pointless but is a critical bugfix.
The issue:
Under certain compiler conditions Native Login would consistently fail PKCE (and therefore login). The exact same source code running on the same device would yield a successful login when run from Xcode but fail if the build was produced with CI.
Testing against a local server uncovered strange client side behavior when generating code challenge. Repeated attempts generated similar looking challenges that didn't even appear to be hashed properly, such as: LAAAAAAAAACQqzNrAQAAACAAAAAAAAAAAAAAAAAAAAA LAAAAAAAAACQKØVrAQAAACAAAAAAAAAAAAAAAAAAAAA
...
I was eventually able to reproduce the issue by simply building the release scheme of our template in Xcode.
Explanation of Fix:
Looking at the pre-fix code:
private func generateChallenge(codeVerifier: String) -> String? {
guard let data = codeVerifier.data(using: .utf8) else { return nil }
let hash = SHA256.hash(data: data)
return urlSafeBase64Encode(data: hash.dataRepresentation)
}
SHA256.hash(data:) returns a SHA256Digest struct that stores the 32 hash bytes inline on the stack. The .dataRepresentation computed property creates a Data from those stack bytes. Depending on optimization, the compiler may reuse the stack slot occupied by hash before base64EncodedString() actually reads the bytes from the Data. As a result the Data points to stack memory that's been partially overwritten.
CommonCryptoCC_SHA256 writes directly into a heap-allocatedNSMutableData buffer. The Objective-C code does not use CryptoKit or SHA256Digest.dataRepresentation.
✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 65.48%. Comparing base (281ab17) to head (2b16f60). ⚠️ Report is 2 commits behind head on dev.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change appears entirely pointless but is a critical bugfix.
The issue:
Under certain compiler conditions Native Login would consistently fail PKCE (and therefore login). The exact same source code running on the same device would yield a successful login when run from Xcode but fail if the build was produced with CI.
Testing against a local server uncovered strange client side behavior when generating code challenge. Repeated attempts generated similar looking challenges that didn't even appear to be hashed properly, such as:
LAAAAAAAAACQqzNrAQAAACAAAAAAAAAAAAAAAAAAAAALAAAAAAAAACQKØVrAQAAACAAAAAAAAAAAAAAAAAAAAA...
I was eventually able to reproduce the issue by simply building the release scheme of our template in Xcode.
Explanation of Fix:
Looking at the pre-fix code:
SHA256.hash(data:)returns aSHA256Digeststruct that stores the 32 hash bytes inline on the stack. The.dataRepresentationcomputed property creates aDatafrom those stack bytes. Depending on optimization, the compiler may reuse the stack slot occupied by hash beforebase64EncodedString()actually reads the bytes from theData. As a result theDatapoints to stack memory that's been partially overwritten.Why web login is unaffected:
From
SFOAuthCoordinator.mCommonCryptoCC_SHA256writes directly into a heap-allocatedNSMutableDatabuffer. The Objective-C code does not useCryptoKitorSHA256Digest.dataRepresentation.