This article is contributed. See the original author and article here.

In our continued effort to increase the baseline security of Azure Sphere, we have now released the Azure Sphere 20.08 quality fix that brings along a number of security enhancements to the platform. As before during our Azure Sphere Security Research Challenge, Cisco Talos continues to find more vulnerabilities and we have the final patch for the attack chain that McAfee ATR used. We also found an interesting scenario with the Linux Kernel 5.4 upgrade that I will cover below.

 

First of all, our list of security enhancements and fixes:

  • We now properly limit the Linux application capability bounding set instead of leaving all bits set.
  • We have added a call to set the PR_SET_NO_NEW_PRIVS value on new applications, further restricting their abilities once set.
  • In an effort to further restrict impacts on the device, symlinks are disabled on most of the tmpfs mounted areas in the system.
  • As a final patch for the McAfee privilege escalation, azcore now has its capability bits properly set restricting it from having extra permissions.
  • wolfSSL has a patch from crashes in ASN parsing found by fuzzing.
  • TrapaSecurity has been using Unicorn to test parts of the system that are not normally accessible, one of the calls they tested for secure world failed to validate its offset when writing to flash which has been corrected. The actual code itself is not accessible to a normal user application and would require a kernel bug or controlling the AzureD daemon.

Cisco Talos has stayed busy in identifying more issues in the system:

  • They found another unsigned code execution bypass via /proc/self/tasks/taskid/maps which was overlooked when setting the /proc/self/maps file read-only.
  • Cisco Talos used a similar attack chain that McAfee ATR located in 20.06, however one of the differences that is now patched is duplicating UIDs in the uid_map file to gain access to other users.
  • The kernel personality flag READ_IMPLIES_EXEC can be used to bypass some of the memory protections, this has been disabled.

Our 20.08 release moves the Linux kernel to version 5.4.54. During the upgrade it was discovered that a key difference between the Linux kernel v4.9 and v5.4 releases is how the random data pool is initialized and used. The new 5.4 kernel brought along optimizations for how the random pool was initialized and used during boot prior to the loading of any drivers for the hardware random number generator (hwrng). On normal computers this is never a problem as the CPU itself has a hwrng embedded in it that the Linux kernel has access to during boot however on the Azure Sphere platform this caused a very small window prior to the Pluton driver initialization to be partially deterministic. Code has been added to secure world to pass a chunk of random data from the Pluton hwrng into the Linux kernel initialization to force a truly random state on boot until the Pluton driver is initialized. This patch guarantees the kernel now has full random data for its full boot process even prior to the driver initialization.

 

We strive to keep all Azure Sphere devices in the field secure and continue to work on improving their security even when unexpected security impacts occur. The ability to hold the security guarantees on Azure Sphere requires multiple companies to work together and help each other when design flaws are found, last month this involved Microsoft alerting the Linux Kernel team to a flaw in the ioctl handling of flash devices. Recently wolfSSL had a few vulnerabilities come out, one of which directly impacts TLS 1.3 client communications which is used by Azure Sphere. wolfSSL helps us keep our security promises for TLS by alerting us to the potential MITM attack along with a patch prior to public disclosure allowing us to get it into our release.

 

Thank you to the teams and researchers that help us increase the security of the platform and make attacking more difficult. As head of the OSP Security team I will continue to do blog posts as new security related enhancements are made to the Azure Sphere platform.

 

Jewell Seay
Azure Sphere OSP Security Lead

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.