December 2023 - wlug - list.wlug.org.nz

'Lenovo B41-30 80LF' Laptop. WiFi not werking. Hardware flt.
by B. Eagle Burt 13 Dec '23

13 Dec '23

I am currently running Devuan Linux OS. The cable/eth0 connection WAS UP & RUNNINNING UNTIL MY INCESSESSANT FIDDLING AROUND WITH Network Manager Screwed that up too ... :-(( I have tried ALL the various Commands/Options of 'nmcli' & found that the WiFi Hardware Device/wlan0 was missing. I have searched & searched Lenovo websites to no avail. I have also spoken with a Lenovo support (NZ) technician who did not exactly inspire confidence. It was his suggestion for me to contact the WLUG. I WAS going to purchase a WiFi Adapter (onboard) from Trademe, but he thought that a PCI MINI card would be too small for this model of Laptop. The Lenovo site does not have any WiFi Adapters for sale. A friend suggested that I purchase a USB WiFi Adapter, which I did - 'tp-link AC600 Nano Wireless USB Adapter' BUT I discovered that there is not a Linux driver for it yet... so THAT was a waste of $40-odd. Anyone with a cheap old PCI WiFi or USB WiFi Adapter Driver for Linux or Any advice welcomed. Thank you for your consideration of this, my first, WLUG List Post. 'b'ye! - B. Gilbert

2 1

Stealthy Linux rootkit found in the wild after going undetected for 2 years
by Peter Reutemann 11 Dec '23

11 Dec '23

'Stealthy and multifunctional Linux malware that has been infecting telecommunications companies went largely unnoticed for two years until being documented for the first time by researchers on Thursday. Researchers from security firm Group-IB have named the remote access trojan “Krasue,” after a nocturnal spirit depicted in Southeast Asian folklore “floating in mid-air, with no torso, just her intestines hanging from below her chin.” The researchers chose the name because evidence to date shows it almost exclusively targets victims in Thailand and “poses a severe risk to critical systems and sensitive data given that it is able to grant attackers remote access to the targeted network. According to the researchers: - Krasue is a Linux Remote Access Trojan that has been active since 20 and predominantly targets organizations in Thailand. - Group-IB can confirm that telecommunications companies were targeted by Krasue. - The malware contains several embedded rootkits to support different Linux kernel versions. - Krasue’s rootkit is drawn from public sources (3 open-source Linux Kernel Module rootkits), as is the case with many Linux rootkits. - The rootkit can hook the `kill()` syscall, network-related functions, and file listing operations in order to hide its activities and evade detection. - Notably, Krasue uses RTSP (Real-Time Streaming Protocol) messages to serve as a disguised “alive ping,” a tactic rarely seen in the wild. - This Linux malware, Group-IB researchers presume, is deployed during the later stages of an attack chain in order to maintain access to a victim host. - Krasue is likely to either be deployed as part of a botnet or sold by initial access brokers to other cybercriminals. - Group-IB researchers believe that Krasue was created by the same author as the XorDdos Linux Trojan, documented by Microsoft in a March 2022 blog post, or someone who had access to the latter’s source code.' -- source: https://arstechnica.com/security/2023/12/stealthy-linux-rootkit-found-in-th… Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, Hamilton, NZ Mobile +64 22 190 2375 https://www.cs.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0

How AlmaLinux's Community Supported RHEL Binary Compatibility
by Peter Reutemann 10 Dec '23

10 Dec '23

'Linux magazine interviewed an AlmaLinux official about what happened after their distro pivoted to binary compatibility with Red Hat Enterprise Linux rather than being a downstream build: Linux Magazine: What prompted AlmaLinux to choose ABI over 1:1 compatibility with RHEL? benny Vasquez, chair of the AlmaLinux OS Foundation: The short answer is our users. Overwhelmingly, our users made it clear that they chose AlmaLinux for its ease of use, the security and stability that it provides, and the backing of a diverse group of sponsors. All of that together meant that we didn't need to lock ourselves into copying RHEL, and we could continue to provide what our users needed. Moreover, we needed to consider what our sponsors would be able to help us provide, and how we could best serve the downstream projects that now rely on AlmaLinux. The rippling effects of any decision that we make are beyond measure at this point, so we consider all aspects of our impact and then move forward with confidence and intention. LM: How did AlmaLinux's mission of improving the Linux ecosystem for everyone influence this decision? bV: We strongly believe that the soul of open source means working together, providing value where there is a gap, and helping each other solve problems. If we participate in an emotional reaction to a business's change, we will then be distracted and potentially hurt users and the Enterprise Linux ecosystem overall. By remaining focused on what is best (though not easiest), and adapting to the ecosystem as it is today, we will provide a better and more stable operating system. LM: What opportunities does the ABI route offer over 1:1 compatibility? bV: By liberating ourselves from the 1:1 promise, we have been able to do a few small things that have proven to be a good testing ground for what will come in the future. Specifically, we shipped a couple of smallish, but extremely important, security patches ahead of Red Hat, offering quicker security to the users of AlmaLinux... This also opens the door for other features and improvements that we could add back in or change, as our users need. We have already seen greater community involvement, especially around these ideas. LM: Does the ABI route pose any extra challenges? bV: The obvious one is that building from CentOS Stream sources takes more effort, but I think the more important challenge (and the one that will only be solved with consistency over time) is the one of proving that we will be able to deliver on the promise... We will continue on our goal of becoming the home for all users that need Enterprise Linux for free, but in the next year I expect that we will see an expansion in the number of kernels we support and see some new and exciting SIGs spun up around other features or use cases, as the community continues to standardize on how to achieve their goals collectively. Linux magazine notes that in August AlmaLinux added two new repositories, Testing and Synergy. "Testing, currently available for AlmaLinux 8 and 9, offers security updates before they are approved and implemented upstream. Synergy contains packages requested by community members that currently aren't available in RHEL or Extra Packages for Enterprise Linux (EPEL, a set of extra software packages maintained by the Fedora SIG that are not available in RHEL or CentOS Stream)." The article also points out that "On the upside, AlmaLinux can now include comments in their patches for greater transparency. Users will see where the patch comes from, which was not an option before." Vasquez tells the magazine, "I think folks will be seriously happy about what they find as we release the new versions, namely, the consistency, stability, and security that they've come to expect from us."' -- source: https://linux.slashdot.org/story/23/12/09/2121242 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, Hamilton, NZ Mobile +64 22 190 2375 https://www.cs.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0

ext4 corruption bug in Linux kernel 6.1.64-1
by Eliot Blennerhassett 10 Dec '23

10 Dec '23

(I haven't read the details yet, but worth being cautious...) ext4 corruption bug in Linux kernel 6.1.64-1 that was in last night's debian point release Avoid booting into 6.1.64-1, if you have already done so the suggestion is to boot to a previous kernel, 6.1.55-1 or earlier debian 12.3 release has been delayed. Thanks to those who are working to update the kernel for the release! Bug report - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843 "IMPORTANT: do NOT upgrade to new stable point release" on debian-user mailing list (Received via mastodon https://floss.social/@FLOX_advocate/111552470597771898) -- Eliot

1 0

openSUSE Wants A New Logo
by Lawrence D'Oliveiro 09 Dec '23

09 Dec '23

openSUSE is asking for submissions of new logos for the main project and its various offshoots. I must say the list of entrants so far <https://en.opensuse.org/Logocontest> is quite varied. Even the ones based on a (recognizable) gecko theme still manage to portray it in a remarkable number of ways.

2 1

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack
by Peter Reutemann 07 Dec '23

07 Dec '23

'Hundreds of Windows and Linux computer models from virtually all hardware makers are vulnerable to a new attack that executes malicious firmware early in the boot-up sequence, a feat that allows infections that are nearly impossible to detect or remove using current defense mechanisms. The attack—dubbed LogoFAIL by the researchers who devised it—is notable for the relative ease in carrying it out, the breadth of both consumer- and enterprise-grade models that are susceptible, and the high level of control it gains over them. In many cases, LogoFAIL can be remotely executed in post-exploit situations using techniques that can’t be spotted by traditional endpoint security products. And because exploits run during the earliest stages of the boot process, they are able to bypass a host of defenses, including the industry-wide Secure Boot, Intel’s Secure Boot, and similar protections from other companies that are devised to prevent so-called bootkit infections. LogoFAIL is a constellation of two dozen newly discovered vulnerabilities that have lurked for years, if not decades, in Unified Extensible Firmware Interfaces responsible for booting modern devices that run Windows or Linux. The vulnerabilities are the product of almost a year’s worth of work by Binarly, a firm that helps customers identify and secure vulnerable firmware. The vulnerabilities are the subject of a coordinated mass disclosure released Wednesday. The participating companies comprise nearly the entirety of the x64 and ARM CPU ecosystem, starting with UEFI suppliers AMI, Insyde, and Phoenix (sometimes still called IBVs or independent BIOS vendors); device manufacturers such as Lenovo, Dell, and HP; and the makers of the CPUs that go inside the devices, usually Intel, AMD or designers of ARM CPUs. The researchers unveiled the attack on Wednesday at the Black Hat Security Conference in London. The affected parties are releasing advisories that disclose which of their products are vulnerable and where to obtain security patches. Links to advisories and a list of vulnerability designations appears at the end of this article. [...] LogoFAIL vulnerabilities are tracked under the following designations: - CVE-2023-5058 - CVE-2023-39538 - CVE-2023-39539 - CVE-2023-40238' -- source: https://arstechnica.com/security/2023/12/just-about-every-windows-and-linux… Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, Hamilton, NZ Mobile +64 22 190 2375 https://www.cs.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0

“Ready, Fire! Aim.”
by Lawrence D'Oliveiro 07 Dec '23

07 Dec '23

NASA’s OSIRIS REx mission successfully returned a sample to Earth from the asteroid Bennu back in September, three years after it was collected. However, it could so easily have gone wrong, due to a little oopsie, according to <https://arstechnica.com/space/2023/12/nasas-asteroid-mission-struck-its-tar…>. What was supposed to happen was, at an altitude of 100,000 feet, the return capsule should have deployed its drogue chute. Then, five minutes later, the cord for this chute would be cut, allowing the main chute to unfurl, after the drogue had done its part in slowing down the capsule descent. Instead, due to a case of (literal) crossed wires, the signal sent at 100,000 feet triggered the cutting (intead of the deployment) of the drogue chute cord, while it was still packed inside the capsule. Then, at 9,000 feet, the release of the main chute caused the drogue chute to pop out first, and immediately fall away. Luckily, there was sufficient margin in the design of the main chute that it was able to cope with the higher descent speed, and bring the capsule down to a safe landing even with this complete failure of the drogue chute. And it was all down to insufficiently clear assembly instructions: "In the design plans for the system, the word 'main' was used inconsistently between the device that sends the electric signals, and the device that receives the signals," NASA said in a written statement. "On the signal side, 'main' meant the main parachute. In contrast, on the receiver side 'main' was used as a reference to a pyrotechnic that fires to release the parachute canister cover and deploy the drogue. "Engineers connected the two mains, causing the parachute deployment actions to occur out of order," NASA said. See, it’s not just software (and hardware) that needs debugging; documentation does, too.

1 0

Veteran Editors Notepad++ and Geany Hit Milestone Versions
by Peter Reutemann 07 Dec '23

07 Dec '23

'Liam Proven reports via The Register: One of the best FOSS text editors for Windows, Notepad++, is turning 20, while cross platform Geany just hit version 2.0 as it turns 18 years old. Notepad++'s version 8.6 is the twentieth anniversary release of one of the go-to FOSS text editors for Windows. [...] If you use an Arm-powered Windows machine, such as the ThinkPad X13S, there is now a native Arm64 version. It still supports x86-32 as well, and there are portable versions which work without being installed locally -- handy if you don't have admin rights. There is even a usefully recent version for Windows XP if you are still using that geriatric OS. This release adds multi-select, allowing you to manipulate multiple instances of the same text at once, which looks confusing but very powerful. It is a staple on all of the Reg FOSS desk's Windows partitions, thanks to its inclusion in the essential Windows post-install setup tool Ninite. Ninite will install -- and update -- a whole swath of FOSS and freeware tools for Windows, making setup of a new machine doable in just a couple of clicks. And if you keep the Ninite installer file around, you can re-run it later and it will update everything it installed first time around. Ninite does offer other programmers' editors, such as Eclipse and Microsoft Visual Studio Code -- but they are behemoths by comparison. VSCode is implemented as an Electron app, meaning that it's huge, embeds an entire copy of Chromium, and scoffs RAM like it's going out of fashion. Notepad++ is a native Win32 app, making it tiny and fast: the download is less than 5MB, one twentieth the size of VSCode. Sluggish, bloated editors are not just a problem on Windows. Gargantuan Electron apps are distressingly prevalent on Linux and macOS as well. This vulture is guilty of using some, and even recommending them -- because some of them can do things that nothing else can. That's not true in the case of plain text editors, though. You don't have to put up with apps that take a good fraction of a gigabyte for this. Geany is a good example. It straddles the line between a text editor and an IDE: it can manage multi-project files, automatically call out to compilers and suchlike, and parse their output to highlight errors. We last mentioned it nearly a decade ago but the project recently reached voting age -- at least for humans -- and after this milestone in maturity its developers called the latest release version 2.0. It has better support for dark mode, a new tree view in its sidebar, adds a bunch of new supported file types, and can detect if the user changes the type of a file and re-do its syntax highlighting to match. ' -- source: https://news.slashdot.org/story/23/12/06/2153200 Yes, Notepad++ and 7zip are usually the first things I install on Windows boxes, to get something more usable than the built-in tools. Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, Hamilton, NZ Mobile +64 22 190 2375 https://www.cs.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

2 1

Developers Trust AI-Written Code Too Much
by Lawrence D'Oliveiro 06 Dec '23

06 Dec '23

Some worrying results from a survey <https://devclass.com/2023/12/05/ai-assistants-write-insecure-code-that-huma…> of the increasing use of AI-generated program code. The survey references a study ... from late last year which looked at “how developers choose to interact with AI code assistants and the ways in which those interactions cause security mistakes,” though the study was limited to university students. There are some shocks here, including the willingness of the AI assistant to generate SQL “that built the query string via string concatenation,” a sure route to SQL injection vulnerabilities. And also a very common feature in code written by PHP developers. Perhaps that kind of code figured very prominently in the training sets for these AIs? Also note this: A key problem is that human intuition seems inclined to trust AI engines more than their known limitations merit. It is known that generative AI is not reliable; yet a lifetime of learning that computers are more logical than humans is hard to overcome. Surely this is just the stereotypical, simplistic Hollywood movie/TV view of computers? Can people in the real world be that dumb? Those of us with experience of computers realize that “more logical than humans” merely means “being able to follow longer logical inference chains than humans”. But if the assumptions the computer is starting from are wrong, the inferences it draws are going to be just as wrong: “Garbage In, Garbage Out” as the old saying goes. And bugs in the algorithms for following those inference chains (e.g. incorrect coding of calculation formulas) just make things worse.

1 0

Firefox On the Brink?
by Peter Reutemann 06 Dec '23

06 Dec '23

'An anonymous reader shares a report: A somewhat obscure guideline for developers of U.S. government websites may be about to accelerate the long, sad decline of Mozilla's Firefox browser. There already are plenty of large entities, both public and private, whose websites lack proper support for Firefox; and that will get only worse in the near future, because the 'fox's auburn paws are perilously close to the lip of the proverbial slippery slope. The U.S. Web Design System (USWDS) provides a comprehensive set of standards which guide those who build the U.S. government's many websites. Its documentation for developers borrows a "2% rule" from its British counterpart: "... we officially support any browser above 2% usage as observed by analytics.usa.gov." (Firefox's market share was 2.2%, per the traffic for the previous ninety days.) [...] "So what?" you may wonder. "That's just for web developers in the U.S. government. It doesn't affect any other web devs." Actually, it very well could. Here's how I envision the dominoes falling: 1. Once Firefox slips below the 2% threshold in the government's visitor analytics, USWDS tells government web devs they don't have to support Firefox anymore. 2. When that word gets out, it spreads quickly to not only the front-end dev community but also the corporate IT departments for whom some web devs work. Many corporations do a lot of business with the government and, thus, whatever the government does from an IT standpoint is going to influence what corporations do. 3. Corporations see this change as an opportunity to lower dev costs and delivery times, in that it provides an excuse to remove some testing (and, in rare cases, specific coding) from their development workflow.' -- source: https://news.slashdot.org/story/23/12/05/0745251 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, Hamilton, NZ Mobile +64 22 190 2375 https://www.cs.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0