github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-03-12 05:04:17 -05:00
Code Issues 144 Packages Projects Releases 116 Wiki Activity

[PR #1162] [MERGED] Fix for missing biometric integrity check in iOS extensions under certain conditions #2775

New Issue
Closed
opened 2025-11-26 23:23:56 -06:00 by GiteaMirror · 0 comments
GiteaMirror commented 2025-11-26 23:23:56 -06:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/bitwarden/android/pull/1162
Author: @mpbw2
Created: 12/1/2020
Status: ✅ Merged
Merged: 12/1/2020
Merged by: @mpbw2

Base: master ← Head: bugfix-biochange-extension

📝 Commits (4)

  • 2bdc6c7 Fix for biometric check in extension on fresh install
  • 1dd60b7 make sure bio integrity values are written to pref storage
  • ec63119 integrity state migration to pref storage
  • 08496d2 remove automatic state saving upon null validation

📊 Changes

8 files changed (+64 additions, -20 deletions)

View changed files

📝 src/App/Resources/AppResources.Designer.cs (+6 -0)
📝 src/App/Resources/AppResources.resx (+4 -1)
📝 src/App/Services/MobileStorageService.cs (+3 -0)
📝 src/Core/Constants.cs (+3 -0)
📝 src/iOS.Autofill/LockPasswordViewController.cs (+1 -1)
📝 src/iOS.Core/Controllers/LockPasswordViewController.cs (+3 -3)
📝 src/iOS.Core/Services/BiometricService.cs (+43 -14)
📝 src/iOS.Extension/LockPasswordViewController.cs (+1 -1)

📄 Description

A path was discovered where a user could modify biometric credentials on an iOS device then bypass the Bitwarden integrity check by using the autofill extension.

Reason: While the extensions do properly perform the integrity check per #1110 , the check would fail to catch the change only if the extension had yet to be triggered once biometric unlock was enabled within the app (because the very first check results in a null value, then updates to the current integrity key value and returns true to indicate success - see BiometricService line 39).

Solution Part 1: By performing the check regardless of the biometric unlock setting in the app, the null integrity value for the extension is replaced with a legitimate value when autofill is first enabled (by opening the extension for user verification). By the time the scenario above plays out, a proper integrity value is in place and the extension catches the change and forces the user to enter their master password.

Solution Part 2: While testing part 1 I witnessed the behavior occasionally revert to skipping the check. As the issue with sharing the DB across processes is still a thorn in my side, I've moved the integrity values to pref storage (where I should have put them in the first place) and added migration to prevent any unnecessary panic brought on by an unplanned bio integrity mismatch. After this change, I've been unable to repro the failure.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/bitwarden/android/pull/1162 **Author:** [@mpbw2](https://github.com/mpbw2) **Created:** 12/1/2020 **Status:** ✅ Merged **Merged:** 12/1/2020 **Merged by:** [@mpbw2](https://github.com/mpbw2) **Base:** `master` ← **Head:** `bugfix-biochange-extension` --- ### 📝 Commits (4) - [`2bdc6c7`](https://github.com/bitwarden/android/commit/2bdc6c7e11f6510d79737deff90e63ede66da81a) Fix for biometric check in extension on fresh install - [`1dd60b7`](https://github.com/bitwarden/android/commit/1dd60b75b3fd03961d3f34869ff3fdd8c414c3ee) make sure bio integrity values are written to pref storage - [`ec63119`](https://github.com/bitwarden/android/commit/ec63119674ffe39c698168542a88824b28c7d496) integrity state migration to pref storage - [`08496d2`](https://github.com/bitwarden/android/commit/08496d26e4d03a722bd89bbc6080aa363ca96984) remove automatic state saving upon null validation ### 📊 Changes **8 files changed** (+64 additions, -20 deletions) <details> <summary>View changed files</summary> 📝 `src/App/Resources/AppResources.Designer.cs` (+6 -0) 📝 `src/App/Resources/AppResources.resx` (+4 -1) 📝 `src/App/Services/MobileStorageService.cs` (+3 -0) 📝 `src/Core/Constants.cs` (+3 -0) 📝 `src/iOS.Autofill/LockPasswordViewController.cs` (+1 -1) 📝 `src/iOS.Core/Controllers/LockPasswordViewController.cs` (+3 -3) 📝 `src/iOS.Core/Services/BiometricService.cs` (+43 -14) 📝 `src/iOS.Extension/LockPasswordViewController.cs` (+1 -1) </details> ### 📄 Description A path was discovered where a user could modify biometric credentials on an iOS device then bypass the Bitwarden integrity check by using the autofill extension. Reason: While the extensions do properly perform the integrity check per #1110 , the check would fail to catch the change **only if the extension had yet to be triggered once biometric unlock was enabled within the app** (because the very first check results in a null value, then updates to the current integrity key value and returns true to indicate success - see [BiometricService line 39](https://github.com/bitwarden/mobile/blob/e27370cf32ece73ba44d7eadd6aebf519d82fdce/src/iOS.Core/Services/BiometricService.cs#L39)). _Solution Part 1_: By performing the check regardless of the biometric unlock setting in the app, the null integrity value for the extension is replaced with a legitimate value when autofill is first enabled (by opening the extension for user verification). By the time the scenario above plays out, a proper integrity value is in place and the extension catches the change and forces the user to enter their master password. _Solution Part 2_: While testing part 1 I witnessed the behavior occasionally revert to skipping the check. As the issue with sharing the DB across processes is still a thorn in my side, I've moved the integrity values to pref storage (where I should have put them in the first place) and added migration to prevent any unnecessary panic brought on by an unplanned bio integrity mismatch. After this change, I've been unable to repro the failure. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2025-11-26 23:23:56 -06:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#2775
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?