Episode 429 Show Notes
Welcome to mintCast
the Podcast by the Linux Mint Community for All Users of Linux
This is Episode 429!
This is Episode 429.5!
Recorded on Sunday, January 21, 2024
Frozen in Texas I’m Joe, and not much warmer is Florida, I’m Eric
— Play Standard Intro —
- First up in the news: Mint 21.3 released, Linux kernel 4.14 goes EOL, Google sued over patent infringement, OpenSSH phases out DSA keys, Canonical snap steams Valve,
- In security and privacy: NoaBot worms its way into Linux; Pixieboot vulnerabilities show up in UEFI, and SlippyBook rears its head;
- Then in our Wanderings: Joe buys things cheap, and Eric talks audio production.
- In our Innards section: We talk about out favorite subjects: ourselves and how we use technology
- And finally, the feedback and a couple of suggestions
— Play News Transition Bumper —
The News
20 minutes
- Mint 21.3 released
- From the Linux Mint Blog
- Mint 21.3 Virginia was released on Friday, January 12. It now comes with full support for SecureBoot and compatibility with a wider variety of BIOS and EFI implementations.
- In Hypnotix, you can now set channels as favorites and create your own channels.
- In Warpinator it is now possible to connect to another device manually, either by entering its IP address or on mobile, by scanning a QR code.
- Sticky, the notes app, received support for DBUS commands. This makes it possible to manage notes from scripts or keybindings.
- In Slick Greeter, the login screen, the alignment of the login box is now configurable.
- Bulky, the batch file renaming tool, received support for thumbnails and drag and drop.
- In Pix, video playback now takes the video orientation into account and automatically rotates it.
- The Backup tool, mintbackup, now features a headerbar and an about dialog.
- A color picker was added to the Xapp XDG Desktop Portal.
- And, as usual, Linux Mint 21.3 features a superb collection of new background artwork.
- There were no changes to the MATE and Xfce desktop versions, but the Cinnamon version was updated tp version 6.0. which includes experimental Wayland support.
- Just as an aside, Moss and Londoner participated in a bug report on mintstick, #121 and #122, which got patched within a day.
- Linux Kernel 4.14 Reaches End of Life After More Than 6 Years of Maintenance – Eric
- from Linux Today
- Greg Kroah-Hartman announced January 12th on the Linux kernel mailing list the release of Linux 4.14.336 as what appears to be the last maintenance update to the long-term supported Linux 4.14 kernel series, which is now marked as EOL (End of Life) on the kernel.org website.
- Google’s TPUs could end up costing it a billion-plus, thanks to this patent challenge – Joe
- from The Register
- Allegations that Google’s Tensor Processing Units (TPUs) were developed using stolen designs are being put to the test as a jury trial brought against the search giant by Singular Computing kicks off this week.
- Google is accused of infringing patents held by Singular and developed by computer scientist Joseph Bates, an academic turned startup founder. According to his LinkedIn profile, Bates held research and teaching positions at Cornell, MIT, Carnegie Mellon, and Johns Hopkins universities in the US between 1980 until 2011.
- In 2005, Bates founded Singular Computing to commercialize various computing architectures. According to Singular’s website, the biz “develops and licenses hardware and software technologies for high-performance energy-efficient computing, both large scale and embedded.”
- Singular’s legal spat with Google dates back to late 2019 when Bates filed a lawsuit in a Massachusetts federal court against the cloud titan [PDF]. According to the complaint, Bates disclosed various technologies he had come up with to Google under a non-disclosure agreement on three occasions between 2010 and 2014. During this time, Singular said, Bates made Google aware the technologies in question were patent protected.
- The patents, said to have been first filed in 2009 and made public in 2010, describe a computer architecture designed to execute a large number of low-precision calculations each processor cycle. While this lower precision may be impractical for conventional compute workloads, the complaint argues it’s well suited to AI software that can accommodate this lower precision.
- Singular Computing also emphasized that these technologies don’t just exist on paper, as a prototype based on the designs was constructed shortly after the first patent application was filed. The patents in question are: an initial US 8,407,273, and US 9,218,156 and 10,416,961 as related followups.
- Singular contends Google deliberately incorporated Bates’ architectures into its TPU v2 and v3 processors, without permission or a license, and thus knowingly infringed the associated patents. TPUs being the custom AI accelerator chips Google designed with outside help to use in its cloud to speed up the training of neural networks and their decision making.
- Jeff Dean, today Google’s chief scientist, wrote to colleagues about how Bates’ designs could be “really well suited” for the web goliath’s workloads, according to internal emails surfaced by the complaint. Google’s legal team, meanwhile, argued no one who worked on the TPUs had any connection with Bates or his blueprints.
- Google has repeatedly denied these allegations of patent infringement. In a statement to The Register, a spokesperson said: “Singular’s patent claims are dubious and currently on appeal. They don’t apply to our Tensor Processing Units, which we developed independently over many years. We look forward to setting the record straight in court.”
- By appeal that PR person is referring to a separate US appeals court case being heard this week in which Google will present arguments as to why Singular’s patents should be considered invalid. Big G is essentially trying to get the patents thrown out to crash Singular’s infringement complaint.
- Google’s TPUs, introduced in 2016, were first developed to power the machine-learning features baked into things like Gmail, Google Maps, and YouTube.
- At a high level, the accelerators are these days essentially a bunch of brain-float matrix math engines called MXUs supported by some high-bandwidth memory and a few CPU cores to make it programmable.
- Now in their fifth-generation, Google is pushing the silicon as an alternative to GPUs for cloud-based AI training and inference workloads.
- The main trial, which kicked off Monday, is expected to last at least two weeks.
- According to pretrial documents [PDF] filed by Google, Singular is seeking between $1.6 billion and $5.19 billion in damages in the form of a lump sum payment if the jury determines the company’s patents were infringed.
- OpenSSH Announces Plan to Phase Out DSA Keys – Eric
- from Linuxiac
- In a move aimed at bolstering digital security, OpenSSH has announced its plan to phase out support for DSA keys, a decision informed by the algorithm’s inherent weaknesses and the evolution of more secure alternatives. But first, let’s shed more light on what DSA is for our readers.
- DSA, which stands for Digital Signature Algorithm, is a cryptographic algorithm for digital signatures and authentication and a key component in the SSHv2 protocol. However, its limitations have long been recognized, particularly its restriction to a 160-bit private key and reliance on the SHA1 digest.
- DSA SSH keys’ generation.
- These constraints render its security level equivalent to less than or equal to 80 bits in symmetric encryption, a standard considered insufficient in the current cybersecurity landscape.
- Despite being the only mandatory-to-implement algorithm in the SSHv2 RFCs, mainly due to patent encumbrances on alternative algorithms when SSHv2 was developed, DSA has fallen behind more robust options like RSA, ECDSA, and EdDSA in terms of security and performance.
- Of course, this will not happen overnight. Instead, OpenSSH has outlined a phased approach. Here’s what’s the plan.
- March 2024 (Estimated): DSA will become optional at compile-time but enabled by default in the next OpenSSH release. This change allows users and distributors to assess the impact of DSA’s removal in their specific environments.
- June 2024 (Estimated): A subsequent release will change the compile-time default to disable DSA. However, it will remain an option for those who require it.
- Post-January 2025: The first release after January 1, 2025, will see the complete removal of DSA code from OpenSSH.
- For users with devices that only support DSA, OpenSSH recommends maintaining a legacy release of the OpenSSH client, akin to the strategy adopted when SSHv1 protocol support was discontinued.
- Further discussions and inquiries about the DSA removal can be directed to the OpenSSH development mailing list or by contacting the developers directly.
- PipeWire Camera Support Is Coming to OBS Studio for Linux Desktops – Joe
- from 9to5 Linux
- GNOME developer Georges Stavracas has merged today the PipeWire Camera support into the master branch of the popular OBS Studio open-source screencasting and streaming app.
- While it’s not ready for prime time due to the lack of real consumers, this change to OBS Studio, which combines the PipeWire media framework and Camera portal, promises to be the future of cameras on the Linux desktop, according to developer Georges Stavracas.
- Since PipeWire Camera support is now merged into OBS Studio master, we should be able to see it in an upcoming release of the popular application in the form of a new “Camera (PipeWire)” source, allowing us to stream from our webcams directly into OBS Studio.
- However, this feature may be marked as experimental in a future OBS Studio release as the devs still need to work on some aspects, such as support for camera resolutions and framerates. Some bugs also need to be addressed, such as the fact that sometimes the selected camera isn’t started automatically.
- Georges Stavracas also noted the fact that the new PipeWire-based Camera source supports YUY2 cameras, which means that many standard webcams out there should work without issues. The developer is currently working on adding support for MJPEG and H.264 streams as well, while NV12 support has been merged as well today.
- More details about this change can be found in this OBS Studio GitHub merge. There, you’ll find instructions on how to enable the new “Camera (PipeWire)” source if you plan on test-driving it, but keep in mind that you’ll have to clone the latest master branch and compile it from sources.
- This might be implemented in OBS Studio 31 or whatever the next major release will be versioned. The latest OBS Studio release is OBS Studio 30, which brought support for Intel QSV (Quick Sync Video) H.264, HEVC, and AV1 on Linux.
- Canonical’s Steam Snap is Causing Headaches for Valve – Eric
- from OMGUbuntu
- Timothée Besset, a software engineer who works on the Steam client for Valve, took to Mastodon this week to reveal: “Valve is seeing an increasing number of bug reports for issues caused by Canonical’s repackaging of the Steam client through snap”.
- “We are not involved with the snap repackaging. It has a lot of issues”, Besset adds, noting that “the best way to install Steam on Debian and derivative operating systems is to […] use the official .deb”.
- Those who don’t want to use the official Deb package are instead asked to ‘consider the Flatpak version’ — though like the Steam snap the Steam Flatpak is also unofficial and not directly supported by Valve but unlike the Snap it says so in its store listing.
- Canonical launched its Steam snap in 2022 as a testing/development preview. That effort lasted around 11 months, and the build was deemed stable in April of last year, in time for the release of Ubuntu 23.04.
- Because Canonical a) develops Snap, and b) packages and integrates the Steam Linux client to work within the tech, any bugs, issues, or quirks stemming from the Steam snap build should (in theory) be reported to them first, rather than to Valve.
- After all, Canonical’s engineers are best placed to know if an issue is snap-related or something within Steam itself that upstream developers at Valve should know about.
- But it doesn’t sound like that’s happening.
- Why?
- I mean, do Ubuntu users know they’re using a snap version not made by Valve? They open Ubuntu Software, search for ‘Steam’, click the matching result, see the a reassuring green tick (albeit next to ‘Canonical’ rather than Valve, but it’s a tick), and hit install — ergo, the Steam snap.
- While Ubuntu Software (and the newer App Center) shows display package filters and format/source labels within the UI, as well developer/packager names and support links, such features are only helpful to those who know what they mean or to look for them.
- Cos it’s easy to assume that anyone who uses Ubuntu, breathes it too. I’d argue they don’t. Ubuntu has a colossal install base, and there’s a good chance most users don’t know what snap is, how it differs to traditional packaging, etc (and arguably they shouldn’t need to, either).
- Still, some simple signposting within the Steam Snap to point users to the right avenues for reporting bugs would help shift the burden off if Valve. And with the recent launch of an Ubuntu Gaming room on Matrix, there’s plenty of places Ubuntu users can go to get advice on gaming.
- They just need to know about them, I guess!
- Could Canonical could tweak their store description to mention their package is not supported/affiliated with Valve? Maybe, but the benefit would hinge on people reading the description, and I reckon most people looking to install Steam wouldn’t since they know what it is!
- “If it gets really bad I guess we could start popping a warning”
- Snap back to the current situation, and there is another option.
- If Canonical’s Steam snap continues to have issues which cause Valve to contacted by users unhappy with the experience Timothée Besset suggests the company could “start popping a warning” to Steam snap users when they open the app.
- While that would be seem as an extreme move, would it be unfair? Valve (and its reputation to an extent) is the one being affected as it stands.
— Play Security Transition Bumper —
Security and Privacy
10 minutes
- Linux devices are under attack by a never-before-seen worm
- from arsTechnica
- For the past year, previously unknown self-replicating malware has been compromising Linux devices around the world and installing cryptomining malware that takes unusual steps to conceal its inner workings, researchers said.
- The worm is a customized version of Mirai, the botnet malware that infects Linux-based servers, routers, web cameras, and other so-called Internet of Things devices. Mirai came to light in 2016 when it was used to deliver record-setting distributed denial-of-service attacks that paralyzed key parts of the Internet that year. The creators soon released the underlying source code, a move that allowed a wide array of crime groups from around the world to incorporate Mirai into their own attack campaigns. Once taking hold of a Linux device, Mirai uses it as a platform to infect other vulnerable devices, a design that makes it a worm, meaning it self-replicates.
- Traditionally, Mirai and its many variants have spread when one infected device scans the Internet looking for other devices that accept Telnet connections. The infected devices then attempt to crack the telnet password by guessing default and commonly used credential pairs. When successful, the newly infected devices target additional devices using the same technique. Mirai has primarily been used to wage DDoSes. Given the large amounts of bandwidth available to many such devices, the floods of junk traffic are often huge, giving the botnet as a whole tremendous power.
- On Wednesday, researchers from network security and reliability firm Akamai revealed that a previously unknown Mirai-based network they dubbed NoaBot has been targeting Linux devices since at least last January. Instead of targeting weak telnet passwords, the NoaBot targets weak passwords connecting SSH connections. Another twist: Rather than performing DDoSes, the new botnet installs cryptocurrency mining software, which allows the attackers to generate digital coins using victims’ computing resources, electricity, and bandwidth. The cryptominer is a modified version of XMRig, a piece of legitimate open-source software being abused by the threat actor. More recently, NoaBot has been used to also deliver P2PInfect, a separate worm researchers from Palo Alto Networks revealed last July.
- Akamai has been monitoring NoaBot for the past 12 months in a honeypot that mimics real Linux devices to track various attacks circulating in the wild. To date, attacks have originated from 849 distinct IP addresses, almost all of which are likely hosting a device that’s already infected. The following figure tracks the number of attacks delivered to the honeypot over the past year.
- “On the surface, NoaBot isn’t a very sophisticated campaign—it’s ‘just’ a Mirai variant and an XMRig cryptominer, and they’re a dime a dozen nowadays,” Akamai Senior Security Researcher Stiv Kupchik wrote in a report Wednesday. “However, the obfuscations added to the malware and the additions to the original source code paint a vastly different picture of the threat actors’ capabilities.”
- The most advanced capability is how NoaBot installs the XMRig variant. Typically, when crypto miners are installed, the wallets’ funds are distributed to are specified in configuration settings delivered in a command line issued to the infected device. This approach has long posed a risk to threat actors because it allows researchers to track where the wallets are hosted and how much money has flowed into them.
- NoaBot uses a novel technique to prevent such detection. Instead of delivering the configuration settings through a command line, the botnet stores the settings in encrypted or obfuscated form and decrypts them only after XMRig is loaded into memory. The botnet then replaces the internal variable that normally would hold the command line configuration settings and passes control to the XMRig source code.
- Kupchik offered a more technical and detailed description:
- In the XMRig open source code, miners can accept configurations in one of two ways — either via the command line or via environment variables. In our case, the threat actors chose not to modify the XMRig original code and instead added parts before the main function. To circumvent the need for command line arguments (which can be an indicator of compromise IOC and alert defenders), the threat actors had the miner replace its own command line (in technical terms, replacing argv) with more “meaningful” arguments before passing control to the XMRig code. The botnet runs the miner with (at most) one argument that tells it to print its logs. Before replacing its command line, however, the miner has to build its configuration. First, it copies basic arguments that are stored plaintext— the rig-id flag, which identifies the miner with three random letters, the threads flags, and a placeholder for the pool’s IP address (Figure 7).
- Curiously, because the configurations are loaded via the xmm registers, IDA actually misses the first two loaded arguments, which are the binary name and the pool IP placeholder.
- Next, the miner decrypts the pool’s domain name. The domain name is stored, encrypted, in a few data blocks that are decrypted via XOR operations. Although XMRig can work with a domain name, the attackers decided to go the extra step, and implemented their own DNS resolution function. They communicate directly with Google’s DNS server (8.8.8.8) and parse its response to resolve the domain name to an IP address.
- The last part of the configuration is also encrypted in a similar way, and it is the passkey for the miner to connect to the pool. All in all, the total configuration of the miner looks something like this:
- -o –rig-id –threads –pass espana*tea
- Notice anything missing? Yep, no wallet address.
- We believe that the threat actors chose to run their own private pool instead of a public one, thereby eliminating the need to specify a wallet (their pool, their rules!). However, in our samples, we observed that miner’s domains were not resolving with Google’s DNS, so we can’t really prove our theory or gather more data from the pool, since the domains we have are no longer resolvable. We haven’t seen any recent incident that drops the miner, so it could also be that the threat actors decided to depart for greener pastures.
- Other unusual differences include:
- NoaBot is compiled using the code library known as UClibc, whereas the standard Mirai uses the GCC library. The alternative library seems to change the way antivirus protections detect NoaBot. Instead of being detected as a member of the Mirai family, AV engines categorize it as an SSH scanner or generic trojan.
- The malware is statically compiled and stripped of any symbols. That makes reverse engineering the malware is much harder.
- Strings, the human-readable words included in code, are obfuscated instead of saved as plaintext. This tweak makes it harder still for reverse engineers to do things like extracting details from the binary or using IDA and other disassembly tools.
- The NoaBot binary runs from a randomly generated folder in the /lib directory, a design that makes searching devices for NoaBot infections is made still harder.
- The standard Mirai dictionary storing the list of commonly used passwords has been replaced with a new one so big that it’s impractical for Akamai to test all of them. The variant also swaps out the Telnet scanner with a custom-made SSH scanner.
- The addition of a host of post-breach capabilities, including installing a new SSH authorized key for use by the attacker as a backdoor to download and execute additional binaries or propagate to new devices.
- While the operational security of the NoaBot creators is high, they’re also notable for the juvenile string names and other gratuitous additions in some of versions of their code. In one case, they added the lyrics to the song “Who’s Ready for Tomorrow” by Rat Boy and IBDY.
- The 849 distinct source IPs are spread relatively uniformly across the globe. The researchers say this uniformity is common for worms, which allow every new victim to be a new attacker as well. Something else that’s not understood: What accounts for a hotspot of China-located source IPs that generate roughly 10 percent of attacks? It’s also unclear how many more IPs hosting the devices targeting the Akamai honeypot may exist, and for that matter, whether some of the devices are actually run by the attackers in an attempt to seed their botnet.
- Akamai has published an extensive library of indicators that people can use to check for signs of NoaBot on their devices. It includes a preconfigured instance of Akamai’s Infection Monkey app for testing networks for signs of compromise. There’s also a CSV file storing all indicators of compromise and YARA rules for detecting XMRig infections.
- It’s hard to know at the moment if NoaBot remains a botnet of less than 1,000 infected hosts or if the Akamai honeypot has seen only a small fraction of the affected devices. Given the difficulty of detecting NoaBot infections, the indicators-of-compromise library assembled by Akamai may prove valuable.
- New UEFI vulnerabilities send firmware devs industry wide scrambling
- from ArsTechnica
- UEFI firmware from five of the leading suppliers contains vulnerabilities that allow attackers with a toehold in a user’s network to infect connected devices with malware that runs at the firmware level.
- The vulnerabilities, which collectively have been dubbed PixieFail by the researchers who discovered them, pose a threat mostly to public and private data centers and possibly other enterprise settings. People with even minimal access to such a network—say a paying customer, a low-level employee, or an attacker who has already gained limited entry—can exploit the vulnerabilities to infect connected devices with a malicious UEFI.
- Short for Unified Extensible Firmware Interface, UEFI is the low-level and complex chain of firmware responsible for booting up virtually every modern computer. By installing malicious firmware that runs prior to the loading of a main OS, UEFI infections can’t be detected or removed using standard endpoint protections. They also give unusually broad control of the infected device.
- Five vendors, and many a customer, affected
- The nine vulnerabilities that comprise PixieFail reside in TianoCore EDK II, an open source implementation of the UEFI specification. The implementation is incorporated into offerings from Arm Ltd., Insyde, AMI, Phoenix Technologies, and Microsoft. The flaws reside in functions related to IPv6, the successor to the IPv4 Internet Protocol network address system. They can be exploited in what’s known as the PXE, or Preboot Execution Environment, when it’s configured to use IPv6.
- PXE, sometimes colloquially referred to as Pixieboot or netboot, is a mechanism enterprises use to boot up large numbers of devices, which more often than not are servers inside of large data centers. Rather than the OS being stored on the device booting up, PXE stores the image on a central server, known as a boot server. Devices booting up locate the boot server using the Dynamic Host Configuration Protocol and then send a request for the OS image.
- PXE is designed for ease of use, uniformity, and quality assurance inside data centers and cloud environments. When updating or reconfiguring the OS, admins need to do so only once and then ensure that hundreds or thousands of connected servers run it each time they boot up.
- By exploiting the PixieFail vulnerabilities, an attacker can cause servers to download a malicious firmware image rather than the intended one. The malicious image in this scenario will establish a permanent beachhead on the device that’s installed prior to the loading of the OS and any security software that would normally flag infections.
- The vulnerabilities and proof-of-concept code demonstrating the presence of the vulnerabilities were developed by researchers from security firm Quarkslab, which published the findings Tuesday.
- The network presence required to exploit most of the vulnerabilities is relatively minor. Attackers need not establish their own malicious server or gain high-level privileges. Instead, the attacker only needs the ability to view and capture traffic as it traverses the local network. This kind of access may be possible when someone has a legitimate account with a cloud service or after first exploiting a separate vulnerability that gives limited system rights. With that, the attacker can then exploit PixieFail to plant a UEFI-controlled backdoor in huge fleets of servers.
- Quarkslab Chief Research Officer Iván Arce said in an interview:
- An attacker doesn’t need to have physical access neither to the client nor the boot server. The attacker just needs to have access to the network where all these systems are running and it needs to have the ability to capture packets and to inject packets or transmit packets. When the client-{based server] boots, the attacker just needs to send the client a malicious packet in the [request] response that will trigger some of these vulns. The only access that the attacker needs is access to the network, not physical access to any of the clients, nor to the boot server or DHCP server. Just capture packets or send packets in the network, where all these servers are running.
- For PixieFail to be exploited, PXE must be turned on. For the overwhelming number of UEFIs in use, PXE isn’t turned on. PXE is generally used only in data centers and cloud environments for rebooting thousands or tens of thousands of servers. Additionally, PXE must be configured to be used in combination with IPv6 routing.
- A motley bunch
- PixieFail is a motley mix of different vulnerability types, ranging from buffer overflows and integer underflows, both of which allow for remote code execution, to the lack of standard but crucial security practices, such as a properly functioning pseudorandom number generator. There was also a TCP implementation that didn’t follow a basic IETF RFC that has been recommended since 2012. The nine vulnerabilities are:
- https://nvd.nist.gov/vuln/detail/CVE-2023-45229: an integer underflow when processing configurations contained in a DHCPv6 advertise message. The underflows from the failure of EDK II—and all the affected UEFIs that rely on it—perform basic “sanity checking” that is designed to flag when memory contents are too small. The base score severity rating is 6.5 out of a possible 10.
- https://nvd.nist.gov/vuln/detail/CVE-2023-45230: A buffer overflow in the DHCPv6client. This vulnerability also stems from a sanity-checking failure. It can be exploited by choosing an overly long Server ID option during what’s known in PXE as the Solicit/Advertise exchange. Base score 8.3.
- https://nvd.nist.gov/vuln/detail/CVE-2023-45231: An out-of-bounds read that can occur during the Network Discovery phase. Base score 6.5
- https://nvd.nist.gov/vuln/detail/CVE-2023-45232: An infinite loop when parsing unknown options in the Destination Options header. Base score 7.5
- https://nvd.nist.gov/vuln/detail/CVE-2023-45233: An infinite loop when parsing a PadN option in the Destination Options header. Base score 7.5
- https://nvd.nist.gov/vuln/detail/CVE-2023-45234 A buffer overflow when processing DNS Servers option in a DHCPv6 Advertise message. Base score 8.3
- https://nvd.nist.gov/vuln/detail/CVE-2023-45235: A buffer overflow when handling a Server ID option from a DHCPv6 proxy Advertise message. Base score 8.3
- https://nvd.nist.gov/vuln/detail/CVE-2023-45236: Predictable TCP Initial Sequence Numbers. Base score 5.7
- https://nvd.nist.gov/vuln/detail/CVE-2023-45237: Use of a weak pseudorandom number generator. Base score 5.3
- The makers of the affected UEFIs are in the process of getting updates pushed out to customers. And from there, those customers are making patches available to their customers, who usually are end users. AMI confirmed the vulnerability affects its Optio V line of firmware and said it has made patches available to its customers. AMI provided a public advisory here and customer-only ones here and here.
- Microsoft, meanwhile, issued a statement that said the company was taking “appropriate action” without saying what that was. Microsoft also claimed—in error, Arce said—that exploiting the vulnerability required the attacker to first establish a malicious server on the affected network. Arce says no such requirement exists.
- “An attack only needs to be able to send packets on that network,” he said. “Also, the proof of concept code which we provided to all vendors, including Microsoft, does not set up any server.”
- Microsoft didn’t have a response to Arce’s analysis. Microsoft also noted the requirement of using PXE over an IPv6 network.
- “As a security best practice, we recommend disabling unused boot capabilities, only using PXE or other protocols on trusted networks, and using TLS over the internet,” Microsoft officials added.
- Officials with Arm Insyde and Phoenix didn’t respond or didn’t have a comment.
- As noted, PixieFail isn’t something most people need to worry about. The vulnerabilities, however, are most definitely something that cloud environments and data centers should greatly care about. After all, exploits allow someone with limited network access to suddenly backdoor any server in a network the next time it reboots. Over the course of a matter of weeks, that could lead to an entire fleet of infected machines.
- Out of an abundance of caution and in keeping with security in-depth principles, all end users should patch the vulnerabilities as well, but the urgency in this case is fairly relaxed. Users generally should look to their device or motherboard maker for an update.
- Update: A little more than 13 hours after this post went live, Microsoft officials updated their statement to add: “If an attacker is able to capture and transmit packets on the network (this is, the ability “to serve” packets), they can pretend to be a ‘server.'”
- Breaking Down Slippy-Book: The New RCE Flaw in Linux Distros
- from SecurityOnline
- A new vulnerability, whimsically named “Slippy-Book,” has emerged as a formidable threat to the integrity of popular Linux distributions. Discovered by security researcher Febin Mon Saji, this Remote Code Execution (RCE) vulnerability, identified as CVE-2023-44451 for Xreader and CVE-2023-52076 for Atril, targets the very core of file parsing in Linux’s prominent document viewers.
- Slippy-Book is a critical path traversal and arbitrary file write flaw. It resides in Atril and Xreader, the default document viewers for the MATE environment and Linux Mint respectively, and affects a range of widely-used operating systems, including Kali Linux, Parrot Security OS, Ubuntu-Mate, and Xubuntu. This vulnerability enables the writing of arbitrary files to any location on the file system accessible to the user, thus paving the way for remote command execution.
- The Slippy-Book vulnerability can be exploited in various ingenious ways:
- Autostart Maneuver: By placing a malicious .desktop entry in the $HOME/.config/autostart/ directory, attackers can ensure execution upon user login, akin to the startup folder in Windows.
- SSH Key Writing: Writing to the authorized_keys file within the user’s .ssh/ directory, enabling immediate command execution via SSH if the system has SSH enabled.
- File Execution on Login: Placing files like .bash_profile or .bash_login with malicious commands in the user’s home directory can result in RCE, especially during non-GUI logins like SSH.
- Targeting Directories for Maximum Impact: Writing malicious files to directories like ~/.local/bin or ~/.local/lib/python3.x/site-packages/ can grant control over the target system.
- The impact of Slippy-Book is profound, especially for security researchers and desktop users of Kali, Parrot OS, and Linux Mint. The vulnerability allows attackers to execute remote commands, compromising system integrity and user privacy. The fact that it doesn’t require overwriting existing files to achieve its malicious ends only adds to its stealth and potency.
- CVE-2023-52076
- Using the exploit, Create a Malicious Document that Executes the Calculator app
- The publication of proof-of-concept code and a video demonstration by the researcher has sounded the alarm for users and administrators of affected Linux distributions. It is a stark reminder of the need for constant vigilance in the cyber world. Users must ensure timely updates and patches to their systems and maintain a keen eye on system behaviors and file integrity.
- Also, the researcher revealed another critical one-click RCE/Command Injection vulnerability affecting popular Linux operating systems with MATE, Cinnamon, and some Xfce desktop environments.
— Play Wanderings Transition Bumper —
Bi-Weekly Wanderings
30 minutes (~5-8 mins each)
- Joe
- I was able to get a hold of a tap strap keyboard for 20 dollars. Normally they cost a lot more than i am willing to put forward for a very unknown device. It is a wearable keyboard and normally costs 150 to 200 dollars but i took a chance on an auction and i won
- It is definitely a large learning curve and i am not impressed with the durability of the device considering how much it was supposed to cost. I spent a few hours practicing with it and will need to spend many more before i com proficient with it but i can get around with a cheat sheet handy.
- The typing is also a bit hit or miss and gets worse as the battery gets lower and some of the dexterity that is required is a bit difficult for me but i am learning it and enjoying. when the battery is high it is good for typing and decent as a mouse so long as you have the proper surface to use it on. Multi colored or textured surfaces seem to give it a bit of a problem in mouse mode and some of the letters are difficult to get right. Also i am still learning how to do capitalization and punctuation. standard numbers and letters are not that difficult. Very good for controlling youtube if you know all the letter commands and how to use them.
- But like i said i am not impressed with the durability. i already had to repair one of the rubber loops that keep the trap in place that broke during the tightening process. my own fault for not realizing how delicate it was but it does not give me high hopes for it long term
- I have also taken a look at the next generation of the device, the tapxr which looks like it might not have the same issues and be more comfortable to wear. I dont know if the control structure is the same but i think that it will one day be interesting to try. That day being when i can get it for 20 dollars instead of the 300 that it retails for.
- I also was able to purchase a modmic USB for use with my headsets without mics. I was able to get it for 5 dollars from fb marketplace which is a really good price considering that it goes new for 85. All I had to do was 3d print or purchase some new mounts for the thing
- I 3d printed some new mounts which were supposed to take 5mm x 1mm magnets but I did not have any neodymium’s that size but I was able to pull some that would work from some old casings that I had lying around. It works really well compared to the 2.4ghz one that I like to use but I don’t know how often I will use it since it is not wireless and I like to be able to get up and move around or whats the point in not using my hyperx and my 99 neos.
- Still I have always wanted the modmic and it will make a good backup mic and system to use when my wife gets on some of my shows. Let her use the hyperx clone and I will use the ath and the modmic.
- I also needed to fix my nextcloud instance again but only in regards to my backups for android. I think that this happened when i did the reformat but i just did not notice until now because i dont take all that many pictures.
- The issue was a permissions problems and when i checked the folders the permissions were correct. I did not realize that the folder location i had was based on the desktop version and the download that it created so there was another location that needed to be checked. When i went there some of the files were owned by root and some were owned by my local user. I changed the permission to make everything writeable and my backups started working again.
- I had one of my lg hbs headsets basically disintegrate on me. The plastic on both sides that hold everything in place snapped and became useless. So I went through my parts bins and pulled out 4 more that were in good order and a pair that needed fixing. During the live stream of the linux lug cast I sat and replaced earbuds with mmcx connections and now have a plethora of working headsets again. I still have a bunch of the retractables that need to be worked on and I do like how those get out of my way so I will be working on them. I also need to look into some more batteries and maybe some power switches if I can ever get those replaced correctly. But for now everything is good.
- Eric
- I have done the audio editing for the past two episodes of Distrohoppers’ Digest, taking over for Tony Hughes after he had been graciously doing so for some time, although not being a presenter on the show.
- I have kept it simple thus far, opting to use Audacity as my main editing tool. Audacity is a capable tool but lacks some of the more advanced capabilities of Digital Audio Workstation, or DAW, software. These include Ardour, Bitwig, and REAPER, with the latter being my preferred option in the past.
- REAPER isn’t free or open source software but it seems like an ethical company that offers a solid product for a reasonable price. Considering how insanely capable it is, the $60 price tag is a bargain. This is also true considering how expensive their competitors can be. Also, I purchased my license in three years ago and it will be valid through version 7.99. Considering the current release version from January 17, 2024 is 7.09, I should be covered for a while longer.
- One of the more powerful aspects of REAPER is the ability to completely customize the UI to support any number of workflows. It comes configured more for music production but can be easily transformed into a spoken word setup suitable for voiceover and podcast production. I followed a series of videos from a voiceover artist which explains how to perform this setup. I have linked to that in the show notes. https://youtube.com/playlist?list=PLzEW-dm_vsRvfiH9RVKAJA6Vd2CccnVmn&si=I1QRy02Jj-hgGSUm
- The main advantage of a DAW over Audacity is the use of realtime, non-destructive effects and filters which allow for manipulating the audio without fundamentally changing it. You can layer effects like noise gates, compressors, and so on, adjusting them as needed and it never changes the underlying original audio.
- Compare this to applying effects in Audacity which do fundamentally alter the audio and make it so that you need to potentially undo several layers of effects to go back and change an earlier edit.
- Audacity has recently added the ability to use realtime effects but I don’t find it to be nearly as robust as something like REAPER, although I suspect this will improve over time.
- I will hopefully get REAPER set up this month to be ready to use it for the next episode.
- One last thing I’d like to mention on audio production is a service called Auphonic. They claim “Auphonic is your all-in-one audio post production webtool to achieve a professional quality result.”. I had used it several years ago and once again for the last episode. It’s honestly a bit of voodoo in that there are a number of features and filters you can choose to use for any given project, things like an Intelligent Leveler which balances levels between speakers, music and speech – no compressor knowledge required. One of the most challenging things to get just right is the audio levels of the various participants and their algorithm absolutely nails it. A few other notable features are Filtering & AutoEQ which removes unwanted frequencies and sibilance (De-Esser) and creates a clear, warm, and pleasant sound and Cut Filler Words and Silence which automatically cut silent segments, pauses, and filler words like “ah”, “uhm”, “mh”, or “ähm” in multiple languages. They generously provide 2 hours of free audio processing per month with paid subscriptions as well as the ability to purchase blocks of hours as well. It has been a huge time saver for me and well worth looking at if you are producing audio. https://auphonic.com/
— Play Innards Transition Bumper —
Linux Innards
30 minutes (~5-8 minutes each)
- Broad strokes about what we want to accomplish in tech in 2024?
- Whether we still use desktops and for what purpose?
- How has Linux broadened your technical landscape? Has it led you to new interests or job prospects? Did you learn more about hardware, software, development, system administration, etc?
— Play Vibrations Transition Bumper —
Vibrations from the Ether
20 minutes (~5 minutes each)
- Jayden Blackman
- To answer your questions about pressure sensitivity on Linux I took a few
screenshots and a screen recording showing the results of pressure
sensitivity in Rnote, Xournal++ (pronounced Zournal-plus-plus I believe),
and Krita. The screen recording is of the tablet tester that’s built into
Krita. The “P” near the middle is of the pressure reading that Krita is
getting. I hope this helps.
- To answer your questions about pressure sensitivity on Linux I took a few
— Play Check This Transition Bumper —
Check This Out
10 minutes
- from ArsTechnica:
- On January 18, Internet pioneer Vint Cerf announced that Dr. David L. Mills, the inventor of Network Time Protocol (NTP), died peacefully at age 85 on January 17, 2024. More information at the link.
- From Ken Fallon at HPR
- I am sumorizing this but they have been thinking about closing down HPR after 18 years. Due to what appears to be low interest since people are not uploading shows.
- So if you have a show idea or ever wanted to try your hand at podcasting then head over to
- https://hub.hackerpublicradio.org/calendar.php
- and follow the instructions. If you are nervous about it then add it to the reserve queue and it will be released if they do run out of shows
Housekeeping & Announcements
- Thank you for listening to this episode of mintCast!
- If you see something that you’d like to hear about, tell us!
Send us email at [email protected]
Join us live on Youtube
Post at the mintCast subreddit
Chat with us on Telegram and Discord,
Or post directly at https://mintcast.org
- Next Episode – 2 pm US Central time on Sunday, February 4, 2024.
- Get mintCast converted to your time zone
- for 429 Next Roundtable Live Stream – 2 pm US Central time on Saturday, January 27, 2024.
- Get the Roundtable Live Stream converted to your time zone
- for 429.5 Next Roundtable Live Stream – 2 pm US Central time on Saturday, February 10, 2024.
- Get the Roundtable Live Stream converted to your time zone
- Livestream information is at mintcast.org/livestream
Wrap-up
- Joe – Tllts.org, linuxlugcast.com, [email protected], Buy Joe a coffee
- Moss – Full Circle Weekly News, Distrohoppers’ Digest, [email protected], Mastodon @[email protected], and my other contact information can be found at It’s Moss dot com
- Bill – [email protected], Bill_H on Discord, @[email protected] on Mastodon, also – checkout my other podcasts Linux OTC and 3 Fat Truckers
- Majid – [email protected] @atypicaldr870on twitter, AtypicalDr on instagram and The Atypical Doctor Podcast on Spotify
- Eric – You can hear and see me on this and the Linux OTC podcasts as well as the Linux Saloon and LinuxLUGCast streams. If you’d like to get in touch with me I can be reached by email at [email protected], Discord (eric_adams), Telegram (https://t.me/ericadams), Matrix (@esa1975:matrix.org), and Mastodon (https://fosstodon.org/@ericadams). Links in the show notes.
Before we leave, we want to make sure to acknowledge some of the people who make mintCast possible:
- Someone for our audio editing
- Archive.org for hosting our audio files
- Hobstar for our logo, initrd for the animated Discord logo
- Londoner for our time syncs and various other contributions
- Bill Houser for hosting the server which runs our website, website maintenance, and the NextCloud server on which we host our show notes and raw audio
- The Linux Mint development team for the fine distro we love to talk about <Thanks, Clem … and co!>
— Play Closing Music and Standard Outro —
Recent Comments