build
This is a merge of CL from widevine repo (obfuscated code only):
https://widevine-internal-review.googlesource.com/c/cdm/+/124885
The source code change that produced the obfucated code is also included
in the CL above but will not be merged to Android.
Original commit message from the fix above:
"This is a security improvement against an L3 exploit b/182584472.
The change is to store RSA private key in two parts instead of one,
and load it separately when the key is needed. This will make it
more difficult to find the entire RSA key.
This CL does the key loading part only. Key splitting is done
in Haystack in CL: cl/367515385"
New L3 system IDs included in the obfuscated code:
ID Description
22585 Android Q ARM L3 Field Provisioning 3.0
22586 Android Q ARM 64 L3 Field Provisioning 3.0
22587 Android Q x86 L3 Field Provisioning 3.0
22588 Android Q x86 64 L3 Field Provisioning 3.0
Bug: 182584472
Test: L3 unit tests
Test: GTS tests
run gts --module GtsMediaTestCases
run gts --module GtsExoPlayerTestCases
run gts --module GtsYouTubeTestCases
Change-Id: I834d3802690c2fda75cb3cfba186c41b6f5dc749
The shared memory buffer used by srcPtr can be freed by another
thread because it is not protected by a mutex. Subsequently,
a use after free AIGABRT can occur in a race condition.
SafetyNet logging is not added to avoid log spamming. The
mutex lock is called to setup for decryption, which is
called frequently.
The crash was reproduced on the device before the fix.
Verified the test passes after the fix.
Test: sts
sts-tradefed run sts-engbuild-no-spl-lock -m StsHostTestCases --test android.security.sts.Bug_176495665#testPocBug_176495665
Test: push to device with target_hwasan-userdebug build
adb shell /data/local/tmp/Bug-176495665_sts64
Bug: 176495665
Bug: 176444161
Change-Id: Ie1aca0ceacb4b7a1b6e473b823541607a36d8cb4
There is a potential integer overflow to bypass the
destination base size check in decrypt. The destPtr
can then point to the outside of the destination buffer.
Test: sts-tradefed
sts-tradefed run sts-engbuild-no-spl-lock -m StsHostTestCases --test android.security.sts.Bug_176444622#testPocBug_176444622
Test: push to device with target_hwasan-userdebug build
adb shell /data/local/tmp/Bug-17644462264
Bug: 176444622
Bug: 176496353
Change-Id: Id3aece61d46d548c304782d4e1dc3a4747795c01
Merged-In: Id3aece61d46d548c304782d4e1dc3a4747795c01
Merged from http://go/wvgerrit/114903
There is a potential integer overflow to bypass the
source base size check in decrypt. The source pointer
can then point to the outside of the source buffer,
which could potentially leak arbitrary memory content
to destination pointer.
Test: sts-tradefed
sts-tradefed run sts-engbuild-no-spl-lock -m StsHostTestCases --test android.security.sts.Bug_176496160#testPocBug_176496160
Test: push to device with target_hwasan-userdebug build
adb shell /data/local/tmp/Bug-17649616064
Bug: 176496160
Bug: 176444786
Change-Id: I0a15d86a87fbf590f39ddf2ce218c83eacb0174e
Merged from http://go/wvgerrit/114903
There is a potential integer overflow to bypass the
source base size check in decrypt. The source pointer
can then point to the outside of the source buffer,
which could potentially leak arbitrary memory content
to destination pointer.
Test: sts-tradefed
sts-tradefed run sts-engbuild-no-spl-lock -m StsHostTestCases --test android.security.sts.Bug_176496160#testPocBug_176496160
Test: push to device with target_hwasan-userdebug build
adb shell /data/local/tmp/Bug-17649616064
Bug: 176496160
Bug: 176444786
Change-Id: I208e0d5d949e8ef003fcf7d6f129eab66b9b3656
Merged from http://go/wvgerrit/114903
There is a potential integer overflow to bypass the
source base size check in decrypt. The source pointer
can then point to the outside of the source buffer,
which could potentially leak arbitrary memory content
to destination pointer.
Test: sts-tradefed
sts-tradefed run sts-engbuild-no-spl-lock -m StsHostTestCases --test android.security.sts.Bug_176496160#testPocBug_176496160
Test: push to device with target_hwasan-userdebug build
adb shell /data/local/tmp/Bug-17649616064
Bug: 176496160
Bug: 176444786
Change-Id: I208e0d5d949e8ef003fcf7d6f129eab66b9b3656
[ Merge of http://go/wvgerrit/79883 ]
This corrects test code and undoes CE CDM changes in b/113167010 which
will be resolved in a future release.
The tests failures addressed are
* ProvisioningTestWithServiceCertificate
* ReleaseRetryOfflineKeyTest
* ReleaseRetryL3OfflineKeyTest
* ReleaseRetryL3OfflineKeySessionUsageDisable
ProvisioningInterspersedRetryTest has been disabled and will be
addressed in a post 15.2 OEMCrypto release in 133641240
Bug: 119428680
Test: WV unit/integration tests
Change-Id: I7961b4556a0ac749e4f38d43f1bea8f520d67f20
[ Merge of http://go/wvgerrit/80084 ]
Corrected the key type being returned after entitled keys from
init data are loaded. Made test changes to validate.
Bug: 133903028
Test: WV unit/integration tests
Change-Id: Icb44587f5c3aba3b0facae6d83dc9344d6b60833
Bug: b/133427576
Test: Unit tests on Taimen and Crosshatch
Merge of http://go/wvgerrit/79804
Currently, the run_all_unit_tests.sh script fails to load in the Level 1
OEMCrypto for some devices that don't have a 64-bit liboemcrypto.so. This
is because the liboemcrypto.so tries to load in libQSEEComAPI.so, which
some devices contain both a 32-bit and 64-bit version of. Since we set
the LD_LIBRARY_PATH to use /vendor/lib64 first, and since we only have a
32-bit liboemcrypto.so, the 32-bit liboemcrypto.so will try to load in the
libQSEEComAPI.so in the lib64 path first. Since the liboemcrypto.so is
32-bit, it will fail to open the 64-bit library. The solution to this is
to conditionally set the LD_LIBRARY_PATH based on if a 64-bit
liboemcrypto.so exists or not.
Change-Id: I80a9e778f31f089f66df0544cb022d810e9d3de3
Bug: b/130252305
Test: nyc-mr2-release -> pi-dev, oc-mr1-release -> pi-dev
nyc-mr2-release -> oc-mr1-release -> pi-dev upgrades with offline
licenses
Merge of http://go/ag/7323341
In N, the L3 files were stored in /data/mediadrm/IDM[uid]/. In O, they
were moved to /data/mediadrm/IDM[uid]/L3/. In P, we moved the contents
of mediadrm to /data/vendor/mediadrm/. For an O->P upgrade, the L3 files
can be read in /data/vendor/mediadrm/IDM[uid]/L3/, but when we upgrade
N->P, the L3 files sit in /data/vendor/mediadrm/IDM[uid]/, unable to be
read. This CL addresses this issue by changing the script to move any L3
files if they exist under this directory to the L3 subdirectory after we
do the bulk move from /data/mediadrm/ to /data/vendor/mediadrm/.
Change-Id: I319c323879766df063d25478046367878023a7cf
(cherry picked from commit 1a6ca36976)
Merge from Widevine repo of http://go/wvgerrit/78949
LoadKeyWithSuspiciousIV is a new test for OEMCrypto v15.2. It is
being disabled since we do not require 15.2 for the Q release.
SelectKeyNotThereAPI15 was failing because the error code is
delayed. This is acceptable.
Bug: 132720732
Test: unit tests on taimen
Change-Id: Iea3fabfb3afd800065119ce812fb454be1e82644
[ Merge of http://go/wvgerrit/78763 ]
The android timer instance is held by a regular pointer rather
than reference counted as all classes that derive from RefBase
should be. This could result in a double deallocation, if the
timer is ever passed to a strong pointer.
Bug: 79364026
Test: WV unit/integration tests. GtsMediaTestCases. Play movies
playback tests.
Change-Id: I01f622bc045e1012f2240b3775a6d121f9415463
