Christoph Puppe’s Post

und hier ein Statement seitens #suse. https://lnkd.in/eWdifesf O-Ton: "SUSE Linux Enterprise and Leap are built in isolation from openSUSE. Code, functionality and characteristics of Tumbleweed are not automatically introduced in SUSE Linux Enterprise and/or Leap. It has been established that the malicious file introduced into Tumbleweed is not present in SUSE Linux Enterprise and/or Leap. Additionally, SUSE has verified that SLE BCI, SUSE Rancher, and SUSE Edge products are not affected. SUSE will continue to monitor this issue, and make any updates if and as necessary." somit #sles, #rancher und SLE Base Container Images (#slebci") not affected.

🔍 Researchers have identified a critical flaw in the Linux kernel, designated CVE-2024-43856, which involves a race condition in the dmam_free_coherent() function. This vulnerability, related to Direct Memory Access (DMA) operations, can lead to serious issues such as system instability, data corruption, or crashes. The flaw stems from the improper sequence of operations when managing DMA memory allocations. Specifically, the function incorrectly handles memory deallocation before destroying the associated tracking data structure. This misstep can allow attackers to exploit the race condition, resulting in incorrect memory access and potential system vulnerabilities. A patch, introduced by Lance Richardson of Google and integrated by Greg Kroah-Hartman, addresses this issue by reordering the function calls to ensure proper cleanup. This fix has been tested and approved, enhancing the security and stability of the Linux kernel. This development underscores the importance of continuous vigilance and prompt responses to vulnerabilities in critical system components. As Linux supports a wide range of devices, such updates are essential for maintaining robust system performance and security. #LinuxKernel #SecurityPatch #CVE2024 #DMA #Cybersecurity #OpenSource #SystemStability #TechUpdates

I first became acquainted with denial-of-service attacks in a weirdly ironic manner. I was at a session for the desktop publishing and prepress-focused Seybold Seminars in 2000. One of the presenters was discussing high availability of servers, and went to show examples of sites that were "always up." He started with Yahoo, it was down. Amazon was also down. Ditto, Microsoft. Oh-for-three. I read later than this was "denial of service," aka DOS, where the servers at several companies were overwhelmed by artificially high levels of web traffic, where the lion's share was generated by compromised computers, and not actually human users. (FYI, in DDoS, the first "D" stands for "distributed" meaning multiple servers compromised to generate traffic). Mike Skrobot, this is for you:

Over the past few days, the open-source community has been rocked by a meticulously planned assault targeting the XZ compression tool. This attack, affecting critical Linux distributions like Debian, openSUSE, and others, has sent shockwaves through the tech world. This incident isn’t your run-of-the-mill security breach. It’s a Threat Level Midnight 10.0. Remarkably, the attacker’s sophistication is evident in the obfuscation techniques employed. The code conceals itself using intricate methods, making detection arduous. Furthermore, any payload sent to the backdoor requires the attacker’s private key for authentication, adding another layer of complexity. The discovery of this exploit was serendipitous. Andre Frin, a vigilant software engineer, stumbled upon anomalies while benchmarking PostgreSQL on Debian’s unstable branch. High CPU usage during SSH logins led him to uncover the malicious activity rooted in XZ Utils. Frin’s astute observation averted a potential catastrophe, showcasing the significance of community vigilance. The identity of the perpetrator remains shrouded in mystery. While Lasse Collin maintains liblzma, the malicious tarballs were attributed to a contributor named Jia Tan. This individual, once deemed trustworthy, exploited years of accumulated trust to orchestrate the attack. Speculation abounds regarding the actor’s motives, ranging from individual malice to state-sponsored espionage. How is the comic book style stories should i keep it in future posts ? #linux #xz

Is remote code execution in UEFI firmware possible? Yes it is! 9 vulnerabilities in the IPv6 stack of EDK II, the open source UEFI implementation used by billions of computers. Full details in our blog post:

ComputadoRita secure boot tested, Now working on secure networking. Using a DHCP server and client written in Rust to pass a cryptographic token as ID or DUID that defines the ComputadoRita, user and groups that the sever can use to allow, deny or restrict network use. This allow network separation using VLANs. The DUID/ID is stored in the boot loader so changing the OS will not reduce security. Because it is cryptographic, changing the boot loader destroys the cryptographic material. It prevents invalid devices on the net and audit the devices that try. Students have one level of security, teachers have another, administrators another and support and a different network access.

Been researching Chrome's new AppBoundEncryption. It basically raises the bar for infostealers by preventing them from stealing stored cookies (and soon to be credentials) directly from the the Windows credential store. It does this by encrypting stored data with a user-specific encryption key which is distributed by a Chrome service running as SYSTEM. The user's Chrome browser process obtains the encryption key from the Chrome service, then stores it in encrypted memory when not in use. Since the Chrome service only provides the key to Chrome browser processes, an attacker would need to either elevate to SYSTEM and steal the key directly, or tamper with the user's browser process. Whilst the change doesn't massively raise the bar for infostealers, requiring them to perform privilege escalation or tamper with other processes drastically increases the likelihood of them being detected by EDR products.

New tool: linux-pkgs.sh, (Sun, Mar 24th): During a recent Linux forensic engagement, a colleague asked if there was anyway to tell what packages were installed on a victim image. As we talk about in FOR577, depending on which tool you run on a live system and how you define "installed" you may get different answers, but at least on the live system you can use things like apt list or dpkg -l or rpm -qa or whatever to try to list them, but if all you have is a disk image, what do you do? So after some research, I initially put together 2 scripts, one to pull info from /var/lib/dpkg/status on Debian/Ubuntu-family systems and another to look through /var/lib/yum/yumdb to try to pull that info from RHEL/CentOS boxes that use yum, but then I remembered that Fedora uses dnf instead of yum and when I found a Fedora image I realized that dnf doesn&#39&#x3b;t use /var/lib/yum/yumdb. I finally combined my original 2 into a single script and playing around for a bit figured out that the dnf info is kept in a sqlite db in /var/lib/dnf. So, I&#39&#x3b;m putting another new tool out there. This one can handle all 3 of the above cases. If anyone wants to help out with figuring out where other distros (not based on these 3 families) hide this data, feel free to share and I&#39&#x3b;ll update, but these 3 handle the vast majority of cases that I run across and probably the vast majority of clound Linux instances, so I figure it is a good place to start. #SANS #Cybersecurity

What do you do when the dual boot laptop at home suddenly stops booting with the message - "Verifying shim DBAT data failed:Security Policy Violation" Of course you go digging on Google, disable secure boot, disable the SBAT policy, reboot, update linux, re-enable secure boot, reboot and get the laptop back to your kid in time for an online class - but maybe you also take the time to go down the rabbit hole of 'secure boot' and 'UEFI' and 'shims'... Here's what I found diving down one of the rabbit holes - A report on a critical flaw in shim (https://lnkd.in/gqrzUvWq) that allows an attacker to manipulate buffer allocation when retrieving files using http or related protocols. This was also presented during a talk during OffensiveCon24 (https://lnkd.in/gwVt8uWk) A nice article by Ally Petitt on the Linux Secure Boot Process (https://lnkd.in/g_kU64DZ) An old page by Rod Smith on transitioning an old BIOS system to UEFI using DUET (https://lnkd.in/gwEgEP9C) ... it also has number of other interesting articles too, if you can find the time - like one that talks of EFIs bootloaders (https://lnkd.in/dCN5TfMR) Link to an Intel page that branches out to interesting information about UEFI (https://lnkd.in/gwEpUF6z)

In the past 24 hours, I’ve developed Pi6eon: a Rust-based CLI chat over IPv6 and TCP that operates without any intermediary servers. And the best part? It’s also end-to-end encrypted! 🦀 https://lnkd.in/d_wCYaDb 🐦 But first, some background. When the Internet was first developed, the Internet Protocol version 4 (IPv4) was designed to identify devices with a 32-bit value, allowing for nearly 4.3 billion addresses. At the time, this seemed more than sufficient. However, with the explosive growth of the Internet, we quickly exhausted these addresses, leading to inconvenient workarounds like Network Address Translation (NAT), which disrupted end-to-end connectivity and fundamentally altered the way the Internet functions. In 1995, IPv6 was introduced to address the issue of IPv4 exhaustion. IPv6 uses 128-bit addresses, providing an astronomical number of addresses, over 3.4 x 10^38. To put it in perspective, you could assign an address to every grain of sand on Earth and still being nowhere near of running out of them! Finally, IPv6 eliminates the need for NAT, bringing back the possibility of end-to-end connectivity between devices globally (as long as firewalls don't block it). This was one of the motivations behind this project: to offer a glimpse of how the Internet should have been and still could be in the future.