Responding to Recent Attacks with Vigishield
In light of recent attacks on the open source community, we’ve been asked if or how our tools (specifically, Vigishield) could have helped prevent them from being successful. The two most recent attacks of interest were:
- XZ attack (CVE-2024-3094)
- AcidRain, AcidPour, and other wiper variants
What is the XZ attack, CVE-2024-3094, and what is its impact?
CVE-2024-3094, also known as the XZ attack, is a critical supply chain compromise found in the XZ Utils library. It involves the introduction of malicious code into the upstream tarballs of XZ, which results in a modified library capable of intercepting and modifying data interactions. This vulnerability poses a significant threat to systems utilizing affected versions of the XZ library.
What is AcidPour and how does it differ from AcidRain?
AcidPour is a newly discovered variant of the AcidRain malware, specifically tailored to target Linux systems running on x86 architecture. While it shares similarities with AcidRain in terms of its destructive capabilities, AcidPour exhibits notable differences in its codebase and targeted devices. AcidPour expands upon AcidRain’s functionality by enabling raw access to flash memory and logical volume management, allowing it to target a wide range of Linux devices including IoT, networking, and possibly some ICS devices.
So, what’s the answer?
I wish I could emphatically say yes, but It’s complicated. Software security is ultimately a battle of attack surface reduction. The further your attack surface can be reduced (by disabling unnecessary features, enabling memory barriers, and so on) the better. Unfortunately, it’s virtually impossible to reduce the attack surface entirely. If someone says they could have prevented all exploits and attacks… they’re lying.
So, with this in mind, we’re going to discuss what Vigishield can do from a compile time perspective. Mainly, we reduce the attack surface as much as we can through compiler and configuration options. And yes — these most certainly could have helped with preventing the attacks above.
Analysis: Deconstructing the XZ Attack
This was a very sophisticated supply chain attack, where a malicious entity gained maintainer status of an upstream package and then slowly injected their exploit into the source through an elaborately woven spiderweb.
How does the XZ attack (CVE-2024-3094) work and what systems are affected?
The XZ attack involved the insertion of malicious code into the upstream tarballs of XZ, starting with version 5.6.0. This code, introduced by a previously trusted developer, modified specific functions in the liblzma code during the build process, resulting in a backdoor capable of intercepting and modifying data interactions. The affected systems include those utilizing versions 5.6.0 and 5.6.1 of the XZ library.
If you’re interested in additional gory details, you should read these two links:
Unraveling the Intricacies of Supply Chain Attacks
The exploit itself works by replacing a few function calls using GCC’s ifunc feature.
The GNU indirect function support (IFUNC) is a feature of the GNU toolchain that allows a developer to create multiple implementations of a given function and to select amongst them at runtime using a resolver function
So, the exploit uses this feature to hijack the function call for RSA_public_decrypt(), when OpenSSH dynamically loads the XZ library (through tainted _is_arch_extension_supported() and _get_cpuid() functions)
Looking through this spiderweb of commits, we can see where this ifunc mess requires that the -fsanitize=address toolchain hardening option is not enabled.
+ # ifunc explicitly does not work with -fsanitize=address. + # If configured, it will result in a liblzma build that + # will fail when liblzma is loaded at runtime (when the + # ifunc resolver executes). + AS_CASE([$CFLAGS], [*-fsanitize=*], [AC_MSG_ERROR([ + CFLAGS contains '-fsanitize=' which is incompatible with ifunc. + Use --disable-ifunc when using '-fsanitize'.])])
Addressing Vulnerabilities with Vigishield
In our current development branch of Vigishield (the one which follows the OpenSSF guidelines for toolchain hardening), -fsanitize=address was set. So, if you were running this Vigishield branch, you would have been hit with this incompatibility message. This would have prompted you to disable ifunc and thus disable the backdoor and protect your device.
Analysis: Combating Wiper Variants like AcidRain and AcidPour
These are malicious executables that seek to erase all information on any disks that they can find. Generally, it’s not clear how these variants make it onto a target device and how they’re given execution privileges.
How does the new AcidPour work compared to AcidRain and what does it do?
AcidPour targets Linux systems on x86 architecture by exploiting vulnerabilities and leveraging advanced techniques to gain access to the target devices. It expands upon AcidRain’s functionality by enabling access to flash memory and logical volume management, allowing it to target a broader range of Linux devices.
In cyber attacks, AcidPour causes widespread damage and disruption to Linux systems running on x86 architecture. It achieves this by wiping critical files and directories, rendering the affected devices inoperable and causing significant downtime for the targeted organizations.
If one of these binaries were to make it onto a Vigishield-hardened device, I don’t doubt that they could succeed in scanning for disk devices and erasing them. However, Vigishield makes many attempts to prevent this from ever being possible.
Fortifying Systems against Malicious Executables
With Vigishield, we offer many features which would help prevent a malicious binary from ever making it onto the device:
- Fully-enforced secure boot and chain of trust
- Verified read-only filesystems (dm-verity)
- Encrypted read-write filesystems (dm-crypt)
- IP Tables-based firewall
- Locked down SSH and console access
- Kernel Configuration Hardening
- Bootloader Hardening
- Toolchain Hardening
So, not only is it virtually impossible for an attacker to load or replace software (due to encryption and verification features), it should also be quite difficult to find any sort of root privilege escalation attack to use for execution.
Analysis: Enhancing Vendor Kernel Security with Vigishield
On the Linux kernel side of things, Vigishield injects some additional baseline security options into your kernel config. We also make recommendations for items which should be manually set.
This has lead us to finding buffer overflows in kernel modules. Digging through some of my previous logs, I can see where this happened (on a Freescale/IMX 5.10 kernel):
| In function 'memcpy', | inlined from 'imx_pcm512x_probe' at ./kernel-source/sound/soc/fsl/imx-pcm512x.c:425:2: | ./kernel-source/include/linux/string.h:395:4: error: call to '__read_overflow2' declared with attribute error: detected read beyond size of object passed as 2nd parameter | 395 | __read_overflow2(); | | ^~~~~~~~~~~~~~~~~~
So, it located a buffer overflow in one of NXP’s audio-related drivers.
This was discovered because we set this option in the Linux kernel:
CONFIG_FORTIFY_SOURCE=y
Which then allowed us to extend the size of the buffer/array and fix the overflow via:
diff --git a/sound/soc/fsl/imx-pcm512x.c b/sound/soc/fsl/imx-pcm512x.c index 7b7592a81524..eb98864bd419 100644 --- a/sound/soc/fsl/imx-pcm512x.c +++ b/sound/soc/fsl/imx-pcm512x.c @@ -30,7 +30,7 @@ #define DAC_CLK_EXT_48K 24576000UL struct imx_pcm512x_data { - struct snd_soc_dai_link dai_link[3]; + struct snd_soc_dai_link dai_link[4]; struct snd_soc_card card; struct snd_soc_codec_conf *codec_conf; struct gpio_desc *mute_gpio;
Conclusion: How to Embrace a Comprehensive Security Approach with Vigishield
Vigishield offers the following compile-time tools and advantages:
- Baseline Kernel configuration hardening
- Kernel configuration scanning (with recommendations for manual adjustment)
- Additional toolchain/GCC compilation options for all packages built
Each of the features in Vigishield follows the Defense in Depth strategy, making it difficult for attacks like the XZ backdoor and AcidPour to compromise your device.
Unlock Your Project’s Security Potential with Vigilant Engineering Support
As always, we offer professional engineering services to help you with your project. Whether you wish for us to integrate our security feature implementation, called Vigishield, into your project, scan your project for CVEs using Vigiles, or just need another set of hands to help with general embedded software engineering and security, we’re available to help!
