A former NSA computer scientist is disgusted with the current state of security practices, writes ITWire. Slashdot reader samuel_the_fool shares their report: Patching of vulnerabilities is the security industry's equivalent of thoughts and prayers, a prominent American security expert has said during a debate on the topic "Patching is useless" at a recent online conference named Hack At The Harbor. Dave Aitel, 46, a former NSA computer scientist who ran his own security shop, Immunity, for many years, said the remedies proposed by security vendors and big technology companies had served to lull people into a false sense of security all these years and ensure that all the old problems still remained.... Aitel pointed out that if there were vulnerable devices on a network, then they should be removed and substituted with others, rather than being continuously patched....

Aitel was no less severe on Linux, noting that the biggest contributor to the kernel was the Chinese telecommunications vendor Huawei Technologies, which he claimed had been indicted by the US, and asking how one could rest content if so many patches were coming from a company of this kind.

On the positive side, he had praise for ChromeOS, an operating system that is produced by Google, and recommended the use of Chromebooks rather Windows machines.

Aitel called for vulnerability management, advocating the government as the best entity to handle this. His argument was that no other entity had sufficient power to push back against the lobby of the big software vendors and the security industry.

An anonymous reader shares a report: According to 9to5Google, a recent bug in Google's Messages app on Android phones left the camera running in the background -- a great way to both heat up your phone and run down your battery. The Google Messages app allows you to easily take a photo directly from the app and attach it to a chat message. According to the article in 9to5Google, the camera app would occasionally keep running, even when you did not have it on screen.

Google is issuing fixes for two vulnerabilities in its Chrome web browser, including one flaw that is already being exploited in the wild. From a report: The emergency updates the company issued this week impact the almost 3 billion users of its Chrome browser as well as those using other Chromium-based browsers, such as Microsoft Edge, Brave and Vivaldi. It is the third such emergency update Google has had to issue for Chrome this year. One of the flaws is a type confusion vulnerability tracked as CVE-2022-1364, a high-severity, zero-day bug that is actively being used by attackers. With a type confusion flaw, a program will allocate a resource like a pointer or object using one type but later will access the resource using another, incompatible type. In some languages, like C and C++, the vulnerability can result in out-of-bounds memory access. This incompatibility can cause a browser to crash or trigger logical errors. However, if exploited, it could enable a hacker to execute arbitrary code.

The Git team has issued an update to fix a bug in Git for Windows that "affects multi-user hardware where untrusted parties have write access to the same hard disk," reports The Register. Specifically, the update is concerned with CVE-2022-24765. From the report: Arguably, if an "untrusted party" has write access to a hard disk, then all bets are off when it comes to the nooks and crannies of a PC anyway. In this case, the miscreants would only need to create the folder c:\.git, "which would be picked up by Git operations run supposedly outside a repository while searching for a Git directory," according to NIST. The result is that Git would use the config in the directory.

NIST went on to list potentially vulnerable products, which included Visual Studio. "Users of the Microsoft fork of Git are vulnerable simply by starting a Git Bash." The Git team was little blunter about the vulnerability, and warned that "Merely having a Git-aware prompt that runs 'git status' (or 'git diff') and navigating to a directory which is supposedly not a Git worktree, or opening such a directory in an editor or IDE such as VS Code or Atom, will potentially run commands defined by that other user." [...] To deal with the issue, the Git team recommends an update. Alternatively, a user could create that .git folder themselves and remove read/write access as workaround or "define or extend 'GIT_CEILING_DIRECTORIES' to cover the parent directory of the user profile," according to NIST.

"Digital purchases are mysteriously expiring on classic PlayStation consoles," Kotaku reports, "rendering a random assortment of games unplayable."

The glitch is "affecting users' ability to play games they ostensibly own." Upon re-downloading the PSOne Classic version of Chrono Cross, for instance, Twitter user Christopher Foose was told the purchase expired on December 31, 1969, preventing him from playing the game on both PlayStation 3 and PlayStation Vita. GamesHub editor Edmond Tran described a similar issue. Trying to boot up Chrono Cross on PlayStation 3, Tran said, gave him the same expiration date and time, only adjusted for his location in Australia. Tran did mention, however, that he was able to download the PSOne Classic from his library and play just fine on Vita despite the game's apparent delisting from the handheld's store.

While at first this felt like an attempt at encouraging Chrono Cross fans to purchase the new Radical Dreamers remaster, Kotaku quickly found evidence of this same problem occurring with different games. Chrono Cross worked just fine for content creator Words, but not its spiritual predecessor Chrono Trigger, the license for which somehow lapsed 40 years before the game was added to the PSOne Classic library.

Steve J over on Twitter asked PlayStation directly why the expiration date for his copy of Final Fantasy VI was changed to 1969, but never received a response....

The only potential explanation I've seen for this issue thus far involves what's known as the "Unix epoch," or the arbitrary date early engineers designated as the beginning of the operating system's lifespan. Some bug or glitch on Sony's backend may be defaulting PlayStation game license expiration dates to the Unix epoch, essentially telling them they can't be played after midnight UTC on January 1, 1970.

Thieves netting massive sums in cybercrime have limited options for laundering the funds. From a report: Many eyes in the crypto world are on a 42-character address on the Ethereum blockchain, which has unclear ownership and is currently home to the equivalent of about $600 million. Hackers stole the funds from players of online game "Axie Infinity" in a March 23 heist uncovered last week. The criminals have moved millions of dollars of assets in recent days, according to blockchain-monitoring tools, but the majority of funds remain in place, leaving victims and outside observers awaiting next moves. Crypto's transparency has turned money laundering into a perverse spectator sport. Transaction records on public blockchains give authorities a bird's-eye view of stolen funds equivalent to tens or hundreds of millions of dollars, often pilfered by targeting poorly secured software bridges that transfer assets between blockchains. The openness leaves successful cyber thieves facing a key question: How do you launder a nine-figure score?

"When there's a hack like that, everyone is watching the wallets," said Kimberly Grauer, director of research at Chainalysis, a blockchain-analytics firm. "So you better damn well know what you're going to do." The fate of the money stolen from "Axie Infinity" users, one of the largest such thefts, has become a topic of speculation. On Etherscan, a monitoring platform where users can see transactions to and from the address in question, commenters claiming to be victims, broke college students or Ukrainian refugees have posted messages asking the hackers to spread their newfound wealth. [...] Last week, blockchain analysts and amateur digital sleuths watched as ether worth about $20 million moved to crypto exchanges based in the Bahamas and Seychelles. On Monday, an additional $12 million of assets flowed into a mixer, which blends different cryptocurrencies to help obscure their sources. Mixers can have their own security compromises and are dependent on having enough crypto on hand to exchange illicit deposits for cleaner funds, said Mitchell Amador, chief executive of Immunefi, a bug-bounty platform focused on decentralized systems.

AMD has confirmed to Tom's Hardware that a bug in its GPU driver is, in fact, changing Ryzen CPU settings in the BIOS without permission. This condition has been shown to auto-overclock Ryzen CPUs without the user's knowledge. From the report: Reports of this issue began cropping up on various social media outlets recently, with users reporting that their CPUs had mysteriously been overclocked without their consent. The issue was subsequently investigated and tracked back to AMD's GPU drivers. AMD originally added support for automatic CPU overclocking through its GPU drivers last year, with the idea that adding in a Ryzen Master module into the Radeon Adrenalin GPU drivers would simplify the overclocking experience. Users with a Ryzen CPU and Radeon GPU could use one interface to overclock both. Previously, it required both the GPU driver and AMD's Ryzen Master software.

Overclocking a Ryzen CPU requires the software to manipulate the BIOS settings, just as we see with other software overclocking utilities. For AMD, this can mean simply engaging the auto-overclocking Precision Boost Overdrive (PBO) feature. This feature does all the dirty work, like adjusting voltages and frequency on the fly, to give you a one-click automatic overclock. However, applying a GPU profile in the AMD driver can now inexplicably alter the BIOS settings to enable automatic overclocking. This is problematic because of the potential ill effects of overclocking -- in fact, overclocking a Ryzen CPU automatically voids the warranty. AMD's software typically requires you to click a warning to acknowledge that you understand the risks associated with overclocking, and that it voids your warranty, before it allows you to overclock the system. Unfortunately, that isn't happening here. Until AMD issues a fix, "users have taken to using the Radeon Software Slimmer to delete the Ryzen Master SDK from the GPU driver, thus preventing any untoward changes to the BIOS settings," adds Tom's Hardware.

The Verge reports: A group of Facebook engineers identified a "massive ranking failure" that exposed as much as half of all News Feed views to potential "integrity risks" over the past six months, according to an internal report on the incident obtained by The Verge.

The engineers first noticed the issue last October, when a sudden surge of misinformation began flowing through the News Feed, notes the report, which was shared inside the company last week. Instead of suppressing posts from repeat misinformation offenders that were reviewed by the company's network of outside fact-checkers, the News Feed was instead giving the posts distribution, spiking views by as much as 30 percent globally. Unable to find the root cause, the engineers watched the surge subside a few weeks later and then flare up repeatedly until the ranking issue was fixed on March 11th.

In addition to posts flagged by fact-checkers, the internal investigation found that, during the bug period, Facebook's systems failed to properly demote probable nudity, violence, and even Russian state media the social network recently pledged to stop recommending in response to the country's invasion of Ukraine. The issue was internally designated a level-one SEV, or site event — a label reserved for high-priority technical crises, like Russia's ongoing block of Facebook and Instagram.

GitLab has addressed a critical severity vulnerability that could allow remote attackers to take over user accounts using hardcoded passwords. Bleeping Computer reports: The bug (discovered internally and tracked as CVE-2022-1162) affects both GitLab Community Edition (CE) and Enterprise Edition (EE). This flaw results from static passwords accidentally set during OmniAuth-based registration in GitLab CE/EE. GitLab urged users to immediately upgrade all GitLab installations to the latest versions (14.9.2, 14.8.5, or 14.7.7) to block potential attacks. GitLab also added that it reset the passwords of a limited number of GitLab.com users as part of the CVE-2022-1162 mitigation effort. It also found no evidence that any accounts have been compromised by attackers using this hardcode password security flaw.

An anonymous reader quotes a report from 9to5Mac: A major Wyze Cam security flaw easily allowed hackers to access stored video, and it went unfixed for almost three years after the company was alerted to it, says a new report today. Additionally, it appears that Wyze Cam v1 -- which went on sale back in 2017 -- will never be patched, so it will remain vulnerable for as long as it is used.

Bleeping Computer reports: "A Wyze Cam internet camera vulnerability allows unauthenticated, remote access to videos and images stored on local memory cards and has remained unfixed for almost three years. The bug, which has not been assigned a CVE ID, allowed remote users to access the contents of the SD card in the camera via a webserver listening on port 80 without requiring authentication. Upon inserting an SD card on the Wyze Cam IoT, a symlink to it is automatically created in the www directory, which is served by the webserver but without any access restrictions."

And as if that weren't bad enough, it gets worse. Many people re-use existing SD cards they have laying around, some of which still have private data on them, especially photos. The flaw gave access to all data on the card, not just files created by the camera. Finally, the AES encryption key is also stored on the card, potentially giving an attacker live access to the camera feed. Altogether, Bitdefender security researchers advised the company of three vulnerabilities. It took Wyze six months to fix one, 21 months to fix another, and just under two years to patch the SD card flaw. The v1 camera still hasn't been patched, and as the company announced last year that it has reached end-of-life status, so it appears it never will.

An anonymous reader quotes a report from ZDNet: The Log4Shell vulnerability is being actively exploited to deliver backdoors and cryptocurrency miners to vulnerable VMware Horizon servers. On Tuesday, Sophos cybersecurity researchers said the attacks were first detected in mid-January and are ongoing. Not only are backdoors and cryptocurrency miners being deployed, but in addition, scripts are used to gather and steal device information. Log4Shell is a critical vulnerability in Apache Log4J Java logging library. The unauthenticated remote code execution (RCE) vulnerability was made public in December 2021 and is tracked as CVE-2021-44228 with a CVSS score of 10.0.

According to Sophos, the latest Log4Shell attacks target unpatched VMware Horizon servers with three different backdoors and four cryptocurrency miners. The attackers behind the campaign are leveraging the bug to obtain access to vulnerable servers. Once they have infiltrated the system, Atera agent or Splashtop Streamer, two legitimate remote monitoring software packages, may be installed, with their purpose twisted into becoming backdoor surveillance tools.

The other backdoor detected by Sophos is Silver, an open source offensive security implant released for use by pen testers and red teams. Sophos says that four miners are linked to this wave of attacks: z0Miner, JavaX miner, Jin, and Mimu, which mine for Monero (XMR). Previously, Trend Micro found z0Miner operators were exploiting the Atlassian Confluence RCE (CVE-2021-26084) for cryptojacking attacks. A PowerShell URL connected to this both campaigns suggests there may also be a link, although that is uncertain. [...] In addition, the researchers uncovered evidence of reverse shell deployment designed to collect device and backup information.

"Supporting generics has been Go's most often requested feature, and we're proud to deliver the generic support that the majority of users need today," the Go blog announced this week. *

It's part of what Go's development team is calling the "biggest change ever to the language".

SiliconANGLE writes that "Right out of the gate, Go 1.18 is getting a CPU speed performance boost of up to 20% for Apple M1, ARM64 and PowerPC64 chips. This is all from an expansion of Go 1.17's calling conventions for the application binary interface on these processor architectures."

And Go 1.18 also introduces native support for fuzz testing — the first major programming language to do so, writes ZDNet: As Google explains, fuzz testing or 'fuzzing' is a means of testing the vulnerability of a piece of software by throwing arbitrary or invalid data at it to expose bugs and unknown errors. This adds an additional layer of security to Go's code that will keep it protected as its functionality evolves — crucial as attacks on software continue to escalate both in frequency and complexity. "At Google we are committed to securing the online infrastructure and applications the world depends upon," said Eric Brewer, VIP infrastructure at Google....

While other languages support fuzzing, Go is the first major programming language to incorporate it into its core toolchain, meaning — unlike other languages — third-party support integrations aren't required.
Google is emphasizing Go's security features — and its widespread adoption. ZDNet writes: Google created Go in 2007 and was designed specifically to help software engineers build secure, open-source enterprise applications for modern, multi-core computing systems. More than three-quarters of Cloud Native Computing Foundation projects, including Kubernetes and Istio, are written in Go, says Google. [Also Docker and Etc.] According to data from Stack Overflow, some 10% of developers are writing in Go worldwide, and there are signs that more recruiters are seeking out Go coders in their search for tech talent..... "Although we have a dedicated Go team at Google, we welcome a significant amount of contributions from our community. It's a shared effort, and with their updates we're helping our community achieve Go's long-term vision.
Or, as the Go blog says: We want to thank every Go user who filed a bug, sent in a change, wrote a tutorial, or helped in any way to make Go 1.18 a reality. We couldn't do it without you. Thank you.

Enjoy Go 1.18!
* Supporting generics "includes major — but fully backward-compatible — changes to the language," explains the release notes. Although it adds a few cautionary notes: These new language changes required a large amount of new code that has not had significant testing in production settings. That will only happen as more people write and use generic code. We believe that this feature is well implemented and high quality. However, unlike most aspects of Go, we can't back up that belief with real world experience. Therefore, while we encourage the use of generics where it makes sense, please use appropriate caution when deploying generic code in production.

While we believe that the new language features are well designed and clearly specified, it is possible that we have made mistakes.... it is possible that there will be code using generics that will work with the 1.18 release but break in later releases. We do not plan or expect to make any such change. However, breaking 1.18 programs in future releases may become necessary for reasons that we cannot today foresee. We will minimize any such breakage as much as possible, but we can't guarantee that the breakage will be zero.

Russia's invasion of Ukraine turns up in Mike Melanson's column "This Week in Programming": While the Open Source Initiative's (OSI) definition of open source software is quite clear on the matter — there must be "no discrimination against persons or groups" and "no discrimination against fields of endeavor" — the issue of who should be allowed to use open source software, according to ethical considerations, has long been debated.

Over the last month, this topic has again become a focus of debate as Russia's invasion of Ukraine has led to developers calling for blanket bans by companies like GitHub and GitLab; and to some developers even taking action. Earlier this month, we wrote about how open source gateway Scarf began limiting access to open source packages for the Russian government and military entities, via its gateway.

As we noted at the time, there was a primary distinction made when Scarf took this action: distribution of open source software is separate from the licensing of it. Those points of the OSI definition pertain to the licensing, not to some entity actively providing the software to others.

Since then, discussions around these ideas have continued, and this week an essay by Bradley M. Kuhn, a policy fellow and hacker-in-residence at the Software Freedom Conservancy, argues that copyleft won't solve all problems, just some of them.

The essay specifically takes to task the idea that open source software can effectively affect change by way of licensing limitations. He spent nearly 3,000 words on the topic, before pointedly addressing the issue of Russia — with a similar conclusion to the one reached by Scarf earlier this month. Kuhn argues that "FOSS licenses are not an effective tool to advance social justice causes other than software freedom" and that, instead, developers have a moral obligation to take stances by way of other methods.

"For example, FOSS developers should refuse to work specifically on bug reports from companies who don't pay their workers a living wage," Kuhn offers in an example.

Regarding Russia specifically, Kuhn again points to distribution as an avenue of protest, while still remaining in line with the principles of free and open source software.

"Every FOSS license in existence permits capricious distribution; software freedom guarantees the right to refuse to distribute new versions of the software. (i.e., Copyleft does not require that you publish all your software on the Internet for everyone, or that you give equal access to everyone — rather, it merely requires that those whom you chose to give legitimate access to the software also receive CCS). FOSS projects should thus avoid providing Putin easy access to updates to their FOSS," writes Kuhn.

"Asahi Linux aims to bring you a polished Linux experience on Apple Silicon Macs," explains the project's web site.

And now that first Asahi Linux alpha release is out — ready for testing on M1, M1 Pro, and M1 Max machines (except Mac Studio): We're really excited to finally take this step and start bringing Linux on Apple Silicon to everyone. This is only the beginning, and things will move even more quickly going forward!

Keep in mind that this is still a very early, alpha release. It is intended for developers and power users; if you decide to install it, we hope you will be able to help us out by filing detailed bug reports and helping debug issues. That said, we welcome everyone to give it a try — just expect things to be a bit rough.... Asahi Linux is developed by a group of volunteers, and led by marcan as his primary job. You can support him directly via Patreon and GitHub Sponsors....

Can I dual-boot macOS and Linux?

Yes! In fact, we expect you to do that, and the installer doesn't support replacing macOS at this point. This is because we have no mechanism for updating system firmware from Linux yet, and until we do it makes sense to keep a macOS install lying around for that. You can have as many macOS and Linux installs as you want, and they will all play nicely and show up in Apple's boot picker. Each Linux install acts as a self-contained OS and should not interfere with the others.

Note that keeping a macOS install around does mean you lose ~70GB of disk space (in order to allow for updates, since the macOS updater is quite inefficient). In the future we expect to have a mechanism for firmware updates from Linux and better integration, at which point we'll be comfortable recommending Linux-only setups....

Is this just Arch Linux ARM?

Pretty much! Most of our work is in the kernel and a few core support packages, and we rely on Linux's excellent existing ARM64 support. The Asahi Linux reference distro images are based off of Arch Linux ARM and simply add our own package repository, which only adds a few packages. You can freely convert between Arch Linux ARM and Asahi Linux by adding or removing this repository and the relevant packages, although vanilla Arch Linux ARM kernels will not boot on these machines at this time.
The project's home page adds that "All contributors are welcome, of any skill level!"

"Doing this requires a tremendous amount of work, as Apple Silicon is an entirely undocumented platform," the team explains. "In particular, we will be reverse engineering the Apple GPU architecture and developing an open-source driver for it." But they're already documenting the Apple Silicon platform on their GitHub wiki. We will eventually release a remix of Arch Linux ARM, packaged for installation by end-users, as a distribution of the same name. The majority of the work resides in hardware support, drivers, and tools, and it will be upstreamed to the relevant projects....

Apple allows booting unsigned/custom kernels on Apple Silicon Macs without a jailbreak! This isn't a hack or an omission, but an actual feature that Apple built into these devices. That means that, unlike iOS devices, Apple does not intend to lock down what OS you can use on Macs (though they probably won't help with the development). As long as no code is taken from macOS to build the Linux support, the result is completely legal to distribute and for end-users to use, as it would not be a derivative work of macOS.
An interesting observataion from Slashdot reader mrwireless: It once again seems Apple is informally supportive of these efforts, as the recent release of OS Monterey 12.3 makes the process even simpler. As Twitter user Matthew Garrett writes:

"People who hate UEFI should read https://github.com/AsahiLinux/... — Apple made deliberate design choices that allow third party OSes to run on M1 hardware without compromising security, and with much less closed code than on basically any modern x86."

Sophos threat researcher Nick Gregory discovered a hole in Linux's netfilter firewall program that's "exploitable to achieve kernel code execution (via ROP [return-oriented programming]), giving full local privilege escalation, container escape, whatever you want." ZDNet reports: Behind almost all Linux firewalls tools such as iptables; its newer version, nftables; firewalld; and ufw, is netfilter, which controls access to and from Linux's network stack. It's an essential Linux security program, so when a security hole is found in it, it's a big deal. [...] This problem exists because netfilter doesn't handle its hardware offload feature correctly. A local, unprivileged attacker can use this to cause a denial-of-service (DoS), execute arbitrary code, and cause general mayhem. Adding insult to injury, this works even if the hardware being attacked doesn't have offload functionality! That's because, as Gregory wrote to a security list, "Despite being in code dealing with hardware offload, this is reachable when targeting network devices that don't have offload functionality (e.g. lo) as the bug is triggered before the rule creation fails."

This vulnerability is present in the Linux kernel versions 5.4 through 5.6.10. It's listed as Common Vulnerabilities and Exposures (CVE-2022-25636), and with a Common Vulnerability Scoring System (CVSS) score of 7.8), this is a real badie. How bad? In its advisory, Red Hat said, "This flaw allows a local attacker with a user account on the system to gain access to out-of-bounds memory, leading to a system crash or a privilege escalation threat." So, yes, this is bad. Worse still, it affects recent major distribution releases such as Red Hat Enterprise Linux (RHEL) 8.x; Debian Bullseye; Ubuntu Linux, and SUSE Linux Enterprise 15.3. While the Linux kernel netfilter patch has been made, the patch isn't available yet in all distribution releases.

Amid the ongoing disruption from Russia, some ethical hackers in Ukraine are feeling lost as bug bounty platform HackerOne has allegedly withheld their payouts. From a report: The loss due to the sudden halt is said to have mounted to hundreds and thousands of dollars. A few of the affected ethical hackers -- also known as cybersecurity researchers -- have taken the issue to social media. Some of them have also written to the platform to get clarity on why exactly it has disabled their payments in the middle of the humanitarian catastrophe in the country. Ethical hackers normally earn payouts ranging from tens and hundreds to over millions of dollars in the form of rewards through bug bounty platforms for reporting flaws in various Internet-based solutions. However, HackerOne is said to have suddenly stopped payouts for some Ukrainian hackers.

Earlier this month, HackerOne CEO Marten Mickos had announced, "[A]s we work to comply with the new sanctions, we'll withdraw all programmes for customers based in Russia, Belarus, and the occupied areas of Ukraine." On Monday, he clarified that the restrictions were for sanctioned regions - Russia and Belarus, not mentioning any clear details about the status of Ukraine. "That's a really weird situation," said independent security researcher Bob Diachenko, who has been associated with the San Francisco, California-based platform for the last two-three years now. The security researcher tweeted on Sunday that HackerOne stopped paying bounties worth around $3,000 for the flaws he reported. Alongside stopping payouts, HackerOne has removed its 'Clear' status from all Ukraine accounts. The status essentially allows ethical hackers to participate in private programmes run by various companies to earn a minimum of $2,000 for a high-severity vulnerability or $5,000 for a critical one. It requires background-check for researchers to participate in the listed programmes.

"News of a fresh Spectre BHB vulnerability that only impacts Intel and Arm processors emerged this week," reports Tom's Hardware, "but Intel's research around these new attack vectors unearthed another issue.

"One of the patches that AMD has used to fix the Spectre vulnerabilities has been broken since 2018." Intel's security team, STORM, found the issue with AMD's mitigation. In response, AMD has issued a security bulletin and updated its guidance to recommend using an alternative method to mitigate the Spectre vulnerabilities, thus repairing the issue anew....

Intel's research into AMD's Spectre fix begins in a roundabout way — Intel's processors were recently found to still be susceptible to Spectre v2-based attacks via a new Branch History Injection variant, this despite the company's use of the Enhanced Indirect Branch Restricted Speculation (eIBRS) and/or Retpoline mitigations that were thought to prevent further attacks. In need of a newer Spectre mitigation approach to patch the far-flung issue, Intel turned to studying alternative mitigation techniques. There are several other options, but all entail varying levels of performance tradeoffs. Intel says its ecosystem partners asked the company to consider using AMD's LFENCE/JMP technique. The "LFENCE/JMP" mitigation is a Retpoline alternative commonly referred to as "AMD's Retpoline."

As a result of Intel's investigation, the company discovered that the mitigation AMD has used since 2018 to patch the Spectre vulnerabilities isn't sufficient — the chips are still vulnerable. The issue impacts nearly every modern AMD processor spanning almost the entire Ryzen family for desktop PCs and laptops (second-gen to current-gen) and the EPYC family of datacenter chips....

In response to the STORM team's discovery and paper, AMD issued a security bulletin (AMD-SB-1026) that states it isn't aware of any currently active exploits using the method described in the paper. AMD also instructs its customers to switch to using "one of the other published mitigations (V2-1 aka 'generic retpoline' or V2-4 aka 'IBRS')." The company also published updated Spectre mitigation guidance reflecting those changes [PDF]....

AMD's security bulletin thanks Intel's STORM team by name and noted it engaged in the coordinated vulnerability disclosure, thus allowing AMD enough time to address the issue before making it known to the public.
Thanks to Slashdot reader Hmmmmmm for submitting the story...

Cognitive Dissident writes: Ars Technica is reporting a major new vulnerability in Linux. Named "Dirty Pipeline" it involves abuse of 'pipes' at the shell level as you might guess.

An anonymous reader quotes a report from Scientific American: New research, published in the journal Physiological Entomology, suggests that the palm-sized Joro spider, which swarmed North Georgia by the millions last September, has a special resilience to the cold. This has led scientists to suggest that the 3-inch (7.6 centimeters) bright-yellow-striped spiders -- whose hatchlings disperse by fashioning web parachutes to fly as far as 100 miles (161 kilometers) -- could soon dominate the Eastern Seaboard. Since the spider hitchhiked its way to the northeast of Atlanta, Georgia, inside a shipping container in 2014, its numbers and range have expanded steadily across Georgia, culminating in an astonishing population boom last year that saw millions of the arachnids drape porches, power lines, mailboxes and vegetable patches across more than 25 state counties with webs as thick as 10 feet (3 meters) deep, Live Science previously reported.

Common to China, Taiwan, Japan and Korea, the Joro spider is part of a group of spiders known as "orb weavers" because of their highly symmetrical, circular webs. The spider gets its name from Jorgumo, a Japanese spirit, or Ykai, that is said to disguise itself as a beautiful woman to prey upon gullible men. True to its mythical reputation, the Joro spider is stunning to look at, with a large, round, jet-black body cut across with bright yellow stripes, and flecked on its underside with intense red markings. But despite its threatening appearance and its fearsome standing in folklore, the Joro spider's bite is rarely strong enough to break through the skin, and its venom poses no threat to humans, dogs or cats unless they are allergic. That's perhaps good news, as the spiders are destined to spread far and wide across the continental U.S., researchers say.

The scientists came to this conclusion after comparing the Joro spider to a close cousin, the golden silk spider, which migrated from tropical climates 160 years ago to establish an eight-legged foothold in the southern United States. By tracking the spiders' locations in the wild and monitoring their vitals as they subjected caught specimens to freezing temperatures, the researchers found that the Joro spider has about double the metabolic rate of its cousin, along with a 77% higher heart rate and a much better survival rate in cold temperatures. Additionally, Joro spiders exist in most parts of their native Japan -- warm and cold -- which has a very similar climate to the U.S. and sits across roughly the same latitude. [...] While most invasive species tend to destabilize the ecosystems they colonize, entomologists are so far optimistic that the Joro spider could actually be beneficial, especially in Georgia where, instead of lovesick men, they kill off mosquitos, biting flies and another invasive species -- the brown marmorated stink bug, which damages crops and has no natural predators. In fact, the researchers say that the Joro is much more likely to be a nuisance than a danger, and that it should be left to its own devices.

An anonymous reader quotes a report from TechCrunch: When Erik Johnson couldn't get his university's mobile student ID app to reliably work, he sought to find a workaround. The app is fairly important, since it allows him and every other student at his university to pay for meals, get into events and even unlock doors to dorm rooms, labs and other facilities across campus. The app is called GET Mobile, and it's developed by CBORD, a technology company that brings access control and payment systems to hospitals and universities. But Johnson -- and the many who left the app one-star reviews in frustration -- said the app was slow and would take too long to load. There had to be a better way.

And so by analyzing the app's network data at the same time he unlocked his dorm room door, Johnson found a way to replicate the network request and unlock the door by using a one-tap Shortcut button on his iPhone. For it to work, the Shortcut has to first send his precise location along with the door unlock request or his door won't open. Johnson said as a security measure students have to be physically in proximity to unlock doors using the app, seen as a measure aimed at preventing accidental door openings across campus. It worked, but why stop there? If he could unlock a door without needing the app, what other tasks could he replicate?

Johnson didn't have to look far for help. CBORD publishes a list of commands available through its API, which can be controlled using a student's credentials, like his. But he soon found a problem: The API was not checking if a student's credentials were valid. That meant Johnson, or anyone else on the internet, could communicate with the API and take over another student's account without having to know their password. Johnson said the API only checked the student's unique ID, but warned that these are sometimes the same as a university-issued student username or student ID number, which some schools publicly list on their online student directories, and as such cannot be considered a secret. Johnson described the password bug as a "master key" to his university -- at least to the doors that are controlled by CBORD. As for needing to be in close proximity to a door to unlock it, Johnson said the bug allowed him to trick the API into thinking he was physically present -- simply by sending back the approximate coordinates of the lock itself. The vulnerability was fixed and session keys were invalidated shortly after TechCrunch shared details of the bug with CBORD.