Prior to targetSdk 22, apps could add random system settings keys which
opens an opportunity for OOM attacks. This CL adds a key size limit.
BUG: 239415997
Test: manual; will add cts test
Merged-In: Ic9e88c0cc3d7206c64ba5b5c7d15b50d1ffc9adc
Change-Id: Ic9e88c0cc3d7206c64ba5b5c7d15b50d1ffc9adc
(cherry picked from commit 783bcba343)
The activity info could be from another uid which is different
from the app that hosts the task. The information should be
trimmed if the caller app doesn't have the privilege.
Bug: 243130512
Test: verified locally
Test: atest RecentTasksTest
Change-Id: Ia343ac70e5bb9aeae718fca6674e1ca491a14512
(cherry picked from commit 401e782b24)
Previously, a setting is updated before the memory usage limit
check, which can be exploited by malicious apps and cause OoM DoS.
This CL changes the logic to checkMemLimit -> update -> updateMemUsage.
BUG: 239415861
Test: atest com.android.providers.settings.SettingsStateTest
(cherry picked from commit 8eeb92950f)
Merged-In: I20551a2dba9aa79efa0c064824f349f551c2c2e4
Change-Id: I20551a2dba9aa79efa0c064824f349f551c2c2e4
Previous logic would exit the loop after removing the first service
matching the uninstalled package.
Bug: 243378132
Test: atest AccessibilityEndToEndTest
Test: m sts;
sts-tradefed run sts-dynamic-develop -m \
CtsAccessibilityServiceTestCases
Change-Id: I4ba30345d8600674ee8a9ea3ff411aecbf3655a3
For many years, Parcel mismatch typed exploits has been using the
AccoungManagerService's passing of KEY_INTENT workflow, as a foothold of
launching arbitrary intents. We are adding an extra check on the service
side to simulate the final deserialization of the KEY_INTENT value, to
make sure the client side won't get a mismatched KEY_INTENT value.
Bug: 250588548
Bug: 240138294
Test: atest CtsAccountManagerTestCases
Test: local test, also see b/250588548
Change-Id: I433e34f6e21ce15c89825044a15b1dec46bb25cc
Do not update invalid component enabled settings to prevent the
malicious apps from exhausting system server memory.
Bug: 240936919
Test: atest android.security.cts.PackageManagerTest
Change-Id: I08165337895e89f13a2b9fcce1201cba9ad13d7d
After an app publishes a shortcut that contains malformed intent, the
system can be stuck in boot-loop due to uncaught exception caused by
parsing the malformed intent.
This CL ignores that particular malformed entry. Since shortcuts are
constantly writes back into the xml from system memory, the malformed
entry will be removed from the xml the next time system persists
shortcuts from memory to file system.
Bug: 246540168
Change-Id: Ie1e39005a5f9d8038bd703a5bc845779c2f46e94
Test: manual
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 will prevent bouncer interactions from showing up in
screenrecords or screenshots.
Fixes: 215005011
Test: atest StatusBarWindowControllerTest && take screenshot
with bouncer up
Merged-In: I3f59df865dc2dd13d4b9ac54bb2dacb7b23f0aa1
Change-Id: I8df2258863b8cede5ba112331e0446f534267ba2
After PUK unlock, multiple calls to
KeyguardSecurityContainerController#dismiss() were being called from
the KeyguardSimPukViewController, which begins the transition to the
next security screen, if any. At the same time, other parts of the
system, also listening to SIM events, recognize the PUK unlock and
call KeyguardSecurityContainer#showSecurityScreen, which updates which
security method comes next. After boot, this should be one of PIN,
Password, Pattern, assuming they have a security method. If one of the
first dismiss() calls comes AFTER the security method changes, this is
incorrectly recognized by the code as a successful
PIN/pattern/password unlock. This causes the keyguard to be marked as
done, causing screen flickers and incorrect system state.
The solution: every call to dismiss() should include a new parameter
for the security method used. If there is a difference between this
parameter and the current value in KeyguardSecurityContainerCallback,
ignore the request, as the system state has changed.
Bug: 218500036
Test: atest KeyguardSecurityContainerTest
Merged-In: I7c8714a177bc85fbce92f6e8fe911f74ca2ac243
Change-Id: I30226bc7b5eda9480d471b35fe81e106b0491ff8
BUG: 242996180
Test: adb shell pm uninstall --user 0 com.google.android.apps.work.oobconfig
Test: Verified with the command above. Before this CL, the package can
be deleted. After this CL, the deletion will fail.
Change-Id: Iba408e536b340ea5d66ab499442c0c4f828fa36f
(cherry picked from commit 15f85c7fa9)
Merged-In: Iba408e536b340ea5d66ab499442c0c4f828fa36f
Previously were unable to add new zen rules because rules added via the settings pages were getting registered under package "com.android.settings", which then were not considered "system rules". These rules should have package android, so when we can trust the caller (via checking that the caller is system) we should be taking the package name from the owner of the rule.
Bug: 245236706
Bug: 242537431
Test: NMSTest; manual
Change-Id: Id69b671592396ac3304862dadbe73de328a8e27a
Merged-In: Id69b671592396ac3304862dadbe73de328a8e27a
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)
This adds validation that the package name passed to
setApplicationRestrictions is in the correct format. This will avoid
an issue where a path could be entered resulting in a file being
written to an unexpected place.
Bug: 239701237
Test: atest UserManagerServiceTest
Change-Id: I1ab2b7228470f10ec26fe3a608ae540cfc9e9a96
(cherry picked from commit 31a582490d)
Merged-In: I1ab2b7228470f10ec26fe3a608ae540cfc9e9a96
instead of checking that of the configuration activity, which is potentially spoofable. The package name is verified to be the same app as the caller by NMS.
This change removes isSystemRule (called only once) in favor of checking the provided package name directly.
Bug: 242537431
Test: ZenModeHelperTest, manual by verifying via provided exploit apk
Change-Id: Ic7f350618c26a613df455a4128c9195f4b424a4d
Merged-In: Ic7f350618c26a613df455a4128c9195f4b424a4d
