As an industry-leading provider of advanced security and virtualization solutions for embedded mission systems, Star Lab works hard to ensure that its own products, as well as its customers’ systems, are fully-patched against late-breaking software vulnerabilities, typically before such bugs become publicly known.
The latest release of Crucible (Version 6.1), is a showcase example of such attention to ensuring customer success. Version 6.1 of Crucible addresses several vulnerabilities which have been recently identified by the Xen Project developer community. As a member of the Xen security pre-disclosure list, the Crucible team has been hard at work validating, reviewing and testing these patches since the bugs were first discovered within the Xen community. This testing has also included verification activities to ensure these security patches do not break or alter the functionality of Crucible, or customer systems. Furthermore, Crucible has unique security mitigations in place that inherently prevent exploitation of many of the identified security vulnerabilities on production systems.
Crucible 6.1 addresses the following vulnerabilities in open-source Xen:
XSA-291 – Requires a malicious or buggy (guest) kernel to incorrectly access physical device memory as is the case for devices which are physically passed thru to the guest. This was partly mitigated by Crucible / Titanium enforcing driver signing and disabling access to /dev/mem (thereby removing several vectors of making malicious kernel modifications).
XSA-284 – Requires a (PV) guest with device pass thru
XSA-290 – Requires a malicious or buggy (guest) kernel using linear page tables. The partial mitigations are similar to XSA-291.
XSA-287 – Requires a PV guest to execute a timing related attack around the XENMEM_exchange hypercall. Crucible enforces FLASK / XSM policy around this hypercall call (significantly hindering the ability to make use of the hypercall), and additionally uses a strict resource assignment paradigm making the timing attack harder to execute in practice.
XSA-288 – Requires a (untrusted) PV guest with hardware pass thru and kernel execution. Crucible does not permit untrusted guests (all guests are verified before launched, and only verified guests are launched). Additionally, for trusted guests, Crucible / Titanium enforce driver signing and disable access to /dev/mem (thereby removing several vectors of making malicious kernel modifications).
XSA-293 – Requires a PV guest (likely) running Linux. Crucible / Titanium can be configured to enforce a “full system mode” of operation, in which no untrusted executables are permitted to run. Additionally, Crucible / Titanium enforce driver signing and disable access to /dev/mem (thereby removing several vectors of making malicious kernel modifications). Further Crucible / Titanium remove kernel features and functionality that could be used to pivot or gain elevated execution context.
XSA-285 – Requires a (malicious) PV guest. Crucible does not “hotplug” hardware into a guest (all hardware is statically assigned at machine creation). Additionally, Crucible does not permit untrusted guests (all guests are verified before launched, and only verified guests are launched) and there is no access to DOM-0 at runtime.
XSA-292 – Requires a (malicious) PV guest.
Overall system security is dependent not only on the individual components, but also how the components are configured as a system, how the system is used, and the steps taken by operators to reduce system attack surface. The Crucible tooling is specifically designed to ensure that system configurations are secure-by-default, and that unsafe configuration are inherently prohibited. For more information about Crucible 6.1, please contact Star Lab at [email protected]