This app-generated input needs to not be too long to avoid errors in the process of writing to disk.
Bug: 242846316
Test: cts ConditionTest; atest ConditionTest; manually verified exploit apk is OK
Change-Id: Ic2fa8f06cc7a4c1f262115764fbd1be2a226b4b9
Merged-In: Ic2fa8f06cc7a4c1f262115764fbd1be2a226b4b9
(cherry picked from commit 81352c3775)
This change both prevents any rules from being unable to be written to disk and also avoids risk of running out of memory while handling all the zen rules.
Bug: 242703460
Bug: 242703505
Bug: 242703780
Bug: 242704043
Bug: 243794204
Test: cts AutomaticZenRuleTest; atest android.app.AutomaticZenRuleTest; manually confirmed each exploit example either saves the rule successfully with a truncated string (in the case of name & conditionId) or may fail to save the rule at all (if the owner/configactivity is invalid). Additionally ran the memory-exhausting PoC without device crashes.
Change-Id: I110172a43f28528dd274b3b346eb29c3796ff2c6
Merged-In: I110172a43f28528dd274b3b346eb29c3796ff2c6
(cherry picked from commit de172ba0d4)
The service must have the CAPTURE_AUDIO_HOTWORD permission to access
AlwaysOnHotwordDetector. If it doesn't have the permission, return
STATE_HARDWARE_UNAVAILABLE state. If it is not granted the
RECORD_AUDIO permisison, it also can't start to recognize the audio.
Test: manual
Test: atest CtsVoiceInteractionTestCases
Test: atest CtsAssistTestCases
Bug: 229793943
Change-Id: I7d0f8d2f6af4bc4210060f0a44469db2afc7a1bb
Merged-In: I7d0f8d2f6af4bc4210060f0a44469db2afc7a1bb
Test: Manually install app apks targeting Q and verifying that AR permission is not auto-granted
Test: atest ActivityRecognitionPermissionTest
Bug: 210065877
Change-Id: I90adf45a6611ab8bc953765c72af77a6a4f7aae8
Before, it was like getting a used pan with food stuck on it. We run
a clean ship here. You want a Parcel? You get a fresh Parcel. When
we recycle a Parcel, we do a real clean-up job. Air freshener. All
bits brushed over. These Parcel objects are clean as heck now!
(specifically cleans mClassCookies)
Bug: 208279300
Test: build
Merged-In: I250872f5c6796bb64e2dc68008154c0e90feb218
Change-Id: I250872f5c6796bb64e2dc68008154c0e90feb218
(cherry picked from commit 46770fa49c)
Bug: 203229608
Test: Manual test with changing the check logic + debug log
Change-Id: If18009f61360564d02dcda9b1e5fa15685e3250f
(cherry picked from commit 58270527d1)
Make sure only the app currently interacting with the IME can
query this, and restrict the API to apps targeting SDKs before T
Fixes: 204906124
Test: atest 'InputMethodManagerTest#getInputMethodWindowVisibleHeight_returnsZeroIfNotFocused'
Change-Id: If1da19a3dd8c29542afc970b4b201d87547c27a9
Merged-In: If1da19a3dd8c29542afc970b4b201d87547c27a9
Duplicate permissions definition with different group allows
privilege permission escalation to a different permission group.
Android studio and gradle plugin does not allow duplicate
permissions with different attributes, these tools only allow
if duplicate permissions are exact copies.
Also platform stores permissions in map at multiple places with
permission name as key. This suggests that we can disallow
duplicate permissions during package install/update.
Bug: 213323615
Test: manual
Change-Id: I6f44e740897305e7a0553c1cf6c3af37faf02a2e
Merged-In: I1910dca44104e35a57eba4acfa8188cd9b8626ac
Merged-In: I34120fff2ec2a158dfa55779d2afd4bbd49487ff
Merged-In: I9bc839836786a0876e67fd73c05f8944bb532249
* changes:
[RESTRICT AUTOMERGE] Log to EventLog on prepareUserStorage failure
[RESTRICT AUTOMERGE] Ignore errors preparing user storage for existing users
[RESTRICT AUTOMERGE] UserDataPreparer: reboot to recovery for system user only
[RESTRICT AUTOMERGE] UserDataPreparer: reboot to recovery if preparing user storage fails
[RESTRICT AUTOMERGE] StorageManagerService: don't ignore failures to prepare user storage
Check user unlocked before write to /data/system_ce/0/snapshots
Unfortunately we can't rule out the existence of devices where the user
storage wasn't properly prepared, due to StorageManagerService
previously ignoring errors from mVold.prepareUserStorage, combined with
OEMs potentially creating files in per-user directories too early. And
forcing these broken devices to be factory reset upon taking an OTA is
not currently considered to be acceptable.
One option is to only check for prepareUserStorage errors on devices
that launched with T or later. However, this is a serious issue and it
would be strongly preferable to do more than that.
Therefore, this CL makes it so that errors are checked for all new
users, rather than all new devices. A field ignorePrepareStorageErrors
is added to the user record; it is only ever set to true implicitly,
when reading a user record from disk that lacks this field. This field
is used by StorageManagerService to decide whether to check for errors.
Bug: 164488924
Bug: 224585613
Test: Intentionally made a device affected by this issue by reverting
the CLs that introduced the error checks, and changing vold to
inject an error into prepareUserStorage. Then, flashed a build
with this CL without wiping userdata. The device still boots, as
expected, and the log shows that the error was intentionally
ignored. Tested that if a second user is added, the error is
*not* ignored and the second user's storage is destroyed before it
can be used. Finally, wiped the device and verified that it won't
boot up anymore, as expected since error checking is enabled for
the system user in that case.
Change-Id: I9bdd1a4bf5b14542adb901f264a91d489115c89b
(cherry picked from commit 60d8318c47)
Merged-In: I9bdd1a4bf5b14542adb901f264a91d489115c89b
GateKeeperResponse has inconsistent writeToParcel() and
createFromParcel() methods, making it possible for a malicious app to
create a Bundle that changes contents after reserialization. Such
Bundles can be used to execute Intents with system privileges.
We fixed related issues previously for GateKeeperResponse class, but
one of the case was remaining when payload is byte array of size 0,
Fixing this case now.
Bug: 220303465
Test: With the POC provided in the bug.
Change-Id: Ida28d611edd674e76ed39dd8037f52abcba82586
Merged-In: Ida28d611edd674e76ed39dd8037f52abcba82586
(cherry picked from commit 46653a91c3)
Change-Id: I486348c7a01c6f59c952b20fb4a36429fff22958
A malicious application could overlay the activity. The overlay is
able to be tapped through, which can trick the user into starting a
harmful activity.
The CL added the flag SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS for
the activity to prevent the tapjacking/overlay attack.
Bug: 205595291
Test: atest CtsHarmfulAppWarningHostTestCases
Change-Id: Ia1a1ae0dc451e04bf5c31e3cb8cf30a0d8e32991
(cherry picked from commit a04b3666b8)
This reverts commit 4d91b5aa0b.
Reason for revert: will deliver a better fix for that, ag/16580245.
Change-Id: I8691f47251157aae83d326eb808dd1c06b13a420
The size of the input of both setStream and setResource may very big
that system server got oom while handling it, so we try to decode it
first before copying it to the wallpaper path, if the decoding fails, we
treat the input as an invalid input.
Bug: 204087139
Test: Manually set wallpaper, no PDoS observed.
Change-Id: I014cf461954992782b3dfa0dde67c98a572cc770
Prevents non-system apps from placing a window over the app selection
screen.
Bug: 143559931
Test: Installed test app and attempted to overlay
Change-Id: Ied05088a5007e0f10cd3e1abd8d7da8ffeb3b674
Merged-In: Ied05088a5007e0f10cd3e1abd8d7da8ffeb3b674
(cherry picked from commit 34534e1fd2)
See comment here for the discussion on solution
https://b.corp.google.com/issues/169762606#comment14
Change-Id: If212df3a3b7be1de0fb26b8e88b2fcbb8077c253
Bug: 169762606
(cherry picked from commit 11053c17b3)
Change-Id: I6494366a5695daedc3f4f0046da9e130a5363f5f
Merged-In: If212df3a3b7be1de0fb26b8e88b2fcbb8077c253
The system is overwhelmed by an enormous label string returned by
the load label api. This cl truncates the label string if it exceeds
the maximum safe length.
Also update the max safe label length to 1000 characters, which is
enough.
Bug: 67013844
Test: atest PackageManagerTest
Change-Id: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
Merged-in: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
The system is overwhelmed by an enormous label string returned by
the load label api. This cl truncates the label string if it exceeds
the maximum safe length.
Also update the max safe label length to 1000 characters, which is
enough.
Bug: 67013844
Test: atest PackageManagerTest
Change-Id: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
Merged-in: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
The system is overwhelmed by an enormous label string returned by
the load label api. This cl truncates the label string if it exceeds
the maximum safe length.
Also update the max safe label length to 1000 characters, which is
enough.
Bug: 67013844
Test: atest PackageManagerTest
Change-Id: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
Merged-in: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
Do not catch exceptions when we attempt to create the following classes
from a parcel
- OutputConfiguration
- VendorTagDescriptor
- VendorTagDescriptorCache
- SessionConfiguration
This could cause subsequent parcel information to be read incorrectly.
Bug: 188675581
Test: Sample app which tries to write invalid data into an
OutputConfiguration parcel to send in an intent via Broadcast. When read by the receiving app,
gets an exception (not swallowed).
Merged-In: I745ca49daa6ca36b1020d518e9f346b52684f2b1
Change-Id: I745ca49daa6ca36b1020d518e9f346b52684f2b1
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
(cherry picked from commit 6b0bcd60c8)
Do not catch exceptions when we attempt to create the following classes
from a parcel
- OutputConfiguration
- VendorTagDescriptor
- VendorTagDescriptorCache
- SessionConfiguration
This could cause subsequent parcel information to be read incorrectly.
Bug: 188675581
Test: Sample app which tries to write invalid data into an
OutputConfiguration parcel to send in an intent via Broadcast. When read by the receiving app,
gets an exception (not swallowed).
Merged-In: I745ca49daa6ca36b1020d518e9f346b52684f2b1
Change-Id: I745ca49daa6ca36b1020d518e9f346b52684f2b1
Signed-off-by: Jayant Chowdhary <jchowdhary@google.com>
(cherry picked from commit 6b0bcd60c8)
This is a CP of ag/14736230 to qt-dev.
Apps were able to bypass BAL and BG-FGS restrictions by retrieving their
own notifications and firing their PI since those were allowlisted for
those operations.
Now we strip the token that granted them that ability
from notifications returned via NM.getActiveNotifications(), which
returns the notifications of the caller.
Notifications returned via notification listener APIs still contain such
token, as they should.
Bug: 185388103
Bug: 169821287
Test: Manually tested
Change-Id: I2ede0d639a560f6acacec3864a0a7d23af152ba5
Merged-In: I2ede0d639a560f6acacec3864a0a7d23af152ba5
(cherry picked from commit 5fbeff59df)
Instead of iterate all ellipsized characters, only iterate the necessary
ranges for copying.
Bug: 188913943
Test: atest CtsTextTestCases CtsGraphicsTestCases CtsWidgetTestCases
Change-Id: I3d03b1e3897e427c23fbe51315f412c57a4ce9e9
Merged-In: I3d03b1e3897e427c23fbe51315f412c57a4ce9e9
