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
[ Merge of http://go/wvgerrit/77506 ]
Callers of MediaDrm can register to be notified when key status
changes and if they are usable for decryption. A number of factors
are evaluated when making this determination. Key container security
level will now be included in the evaluation.
Bug: 78652608
Test: WV unit/integration test, GtsMediaDrmTest, Play movies playback
testing.
Change-Id: I20243e5cb160f7957e3239e8d05f715ff0ee6dd6
Merge from Widevine repo of http://go/wvgerrit/78623
This updates the license request client identification to include
OEMCrypto build information.
Bug: 129070445
Test: ExoPlayer on crosshatch with mod mock
Change-Id: I0dbce0cca4e9810e14f60561e4e434f1dbcadfb6
Merge from Widevine repo of http://go/wvgerrit/77609
For v15.2 we require that nonces not collide across sessions and there are
restrictions placed on the mac key's IV in LoadKeys.
Test: ran unit tests on reference code
Bug: 131325434
Bug: 131326334
Change-Id: I1bb01c30d8c15d66d762c28b57d7700c44daa835
(This is a merge of http://go/wvgerrit/78105)
The Widevine Android CDM should not allow itself to be instantiated
without an app package name, as this breaks SPOID protection.
Unfortunately, pathways exist prior to Android Q that allow this to
happen, and we cannot break these devices by changing the behavior now.
As such, we will only refuse to allow instantiation without an app
package name on devices first launched with Q and later.
This change also migrates the WVDrmFactory and its tests away from
explicitly naming friend classes for individual test, in favor of the
now-recommended "test peer" pattern.
Bug: 65680731
Test: libwvdrmengine_hidl_test
Test: CTS NativeMediaDrmClearkeyTest
Change-Id: Icccd1d8b9972ef6ad7e5b0dbf2d37ec987656385
Merge from Widevine repo of http://go/wvgerrit/78143
This verifies that the correct mac keys are used to sign a message when
generating a usage report or secure stop.
Test: unit tests on ref code and taimen
Bug: 111261264
Change-Id: I7d56a6ff0aae68a5554f7ce84d467697d1f9997b
Merge from Widevine repo of http://go/wvgerrit/78063
This test incorrectly asserted a buffer size.
Bug: 131864150
Test: Unit tests ran on taimen.
Change-Id: If53fdd4cce9d6b3dfa85f50a3dbc08c99bceebfb
Merge from Widevine repo of http://go/wvgerrit/78144
This CL verifies that LoadKeys cannot be called twice a second time in
an OEMCrypto session.
Bug: 131359743
Test: unit tests on refernce code and taimen
Change-Id: I3da1c7639ed163799ee5996fd9f7f8b427c7ed30
Merge from Widevine repo of http://go/wvgerrit/77604
Test: ran unit tests
Bug: 131326334 Nonce collision should be avoided in open sessions
Bug: 131325434 mac key iv should not be 16 bytes before encrypted mac key
Bug: 129368634 HDCP 2.3 and 2.2 are not distinguishable
Bug: 127423611 Question about OEMCrypto V15 API
Bug: 124312571 Picture-in-Picture -- is it really needed for Android TV?
Bug: 131175454 Extend Provisioning 3.0 Schedule
Bug: 131359743 Do not allow multiple LoadKeys in a session
Change-Id: I8db4ec921978ea918adb17420db86de69e806120
Bug: b/129426820
Test: CE CDM, Android unit/integration, Linux, ExoPlayer key rotation
playback with modmock and L3
Merge of http://go/wvgerrit/77608http://go/ag/6543431 modified the entitlement key session to select the
entitled content key if it had just been loaded in so that there's a
valid current content key loaded in OEMCrypto. However, this did not
account for the case where you have two entitlement to entitled key
pairs. If OEMCrypto does not select the key when you switch from the
first pair to the second pair back to the first pair, OEMCrypto will
still be using the key from the second pair during decrypt. This CL
changes it so we SelectKey each time to make sure that we update the
current content key.
Change-Id: I764ec13deb87e14188707b811a44eff132eeb5a1
