oemcrypto/oemcrypto/test

OEMCrypto Memory Unit Tests

Objective

• Add OEMCrypto buffer overflow unit tests (indirect way of fuzzing) to verify OEMCrypto API behavior when the parameters passed to the API are out of range or not reasonable. The API can return an error code, but shouldn't crash.

• A lot of OEMCrypto APIs take buffers and their length as inputs to the APIs and we have added unit tests with buffers of varying lengths (small to huge) to verify API behavior which is an indirect and simplest way of fuzz testing to detect buffer overflows.

• Add the tests for OEMCrypto APIs with prefix OEMCryptoMemory in the following format. Huge length is set at 100 MB as of now.

  for (size_t length=small_length; length<huge_length; length=length * 2) {
      Create buffer of size length.
      Call api expecting it not to crash or segfault.
  }
  

• Add tests for OEMCrypto APIs with out of range values for length and offsets of OEMCryptoSubstring struct. This length and offset fields are used to read values from an input buffer in most of the APIs. This can cause buffer overflows if the length and offset fields are not validated against the input buffer.

Background

• Security is the top priority for Widevine. We came up with a simple approach to catch most common issues with widevine's implementations. A simplest approach is to add OEMCrypto unit tests to verify OEMCrypto API behavior when the parameters are out of range, meaning for an unreasonable length which can cause buffer overflows. Most of the implementation either does not validate input length parameters or copies data to secure buffers out of TA space causing memory corruptions, buffer overflows. Partners who implement OEMCrypto implementations will run OEMCrypto unit tests as part of the process.

• We have added unit tests with parameters that can cause buffer overflows if the parameters are not validated. This way partners can catch issues earlier in the process when they run OEMCrypto unit tests. All the unit tests with prefix OEMCryptoMemory are added to test the above scenario.

What to expect from these tests

• OEMCryptoMemory* tests are designed to fail if API doesn't have enough validations around input buffer lengths, parameters or OEMCryptoSubstring struct. If the API doesn't have validations which might lead to a crash, the test fails with a segfault or an appropriate crash message based on the API implementation.

• Find out for what buffer length, the API is crashing and then debugging the test against the OEMCrypto implementation should be able to provide information about the error.

• Another way to debug would be to compile the tests with sanitizer flags, which will be able to provide detailed information about the crash.

• Partners are expected to fix issues with the API so that the tests don't fail.

• As these tests run for varying lengths from small to huge buffer lengths, some of the tests might take longer to run(~3 minutes).

• OEMCryptoMemoryInstallKeyboxForHugeKeyboxBuffer* tests which tries to call install keybox API with varying buffer lengths. This test by default is not compiled as it overwrites the keybox on the device. Uncomment, compile and run the tests only if you have ability to recover the keybox on device where the test is ran.