An anonymous reader quotes a report from Ars Technica: When you use your phone to unlock a Tesla, the device and the car use Bluetooth signals to measure their proximity to each other. Move close to the car with the phone in hand, and the door automatically unlocks. Move away, and it locks. This proximity authentication works on the assumption that the key stored on the phone can only be transmitted when the locked device is within Bluetooth range. Now, a researcher has devised a hack that allows him to unlock millions of Teslas -- and countless other devices -- even when the authenticating phone or key fob is hundreds of yards or miles away. The hack, which exploits weaknesses in the Bluetooth Low Energy standard adhered to by thousands of device makers, can be used to unlock doors, open and operate vehicles, and gain unauthorized access to a host of laptops and other security-sensitive devices.
[...]
[The] attack uses custom software and about $100 worth of equipment. [Sultan Qasim Khan, a principal security consultant and researcher at security firm NCC Group] has confirmed it works against the Tesla Model 3 and Model Y and Kevo smart locks marketed under the Kwikset and Weiser brand names. But he says virtually any BLE device that authenticates solely on proximity -- as opposed to also requiring user interaction, geolocation querying, or something else -- is vulnerable. "The problem is that BLE-based proximity authentication is used in places where it was never safe to do so," he explained. "BLE is a standard for devices to share data; it was never meant to be a standard for proximity authentication. However, various companies have adopted it to implement proximity authentication."

Because the threat isn't caused by a traditional bug or error in either the Bluetooth specification or an implementation of the standard, there's no CVE designation used to track vulnerabilities. Khan added: "In general, any product relying on BLE proximity authentication is vulnerable if it does not require user interaction on the phone or key fob to approve the unlock and does not implement secure ranging with time-of-flight measurement or comparison of the phone/key fob's GPS or cellular location relative to the location of the device being unlocked. GPS or cellular location comparison may also be insufficient to prevent short distance relay attacks (such as breaking into a home's front door or stealing a car from the driveway, when the owner's phone or key fob is inside the house)." There's a few countermeasures one can take to mitigate this attack. "One mechanism is to check the location of the authenticating device to ensure that it is, in fact, physically close to the locked car or other device," reports Ars.

"Another countermeasure is to require the user to provide some form of input to the authenticating device before it's trusted." The phone's accelerometer could also be used to measure its movements.

The advisories published by NCC Group can be found here, here, and here.

A bug in Google Docs is causing it to crash when a series of words are typed into a document opened with the online word processor. BleepingComputer reports: It's official -- Google Docs crashes at the sight of "And. And. And. And. And." when the "Show grammar suggestion" is turned on. A Google Docs user, Pat Needham brought up the issue on Google Docs Editors Help forum. [...] Another user, Sergii Dymchenko, said strings like "But. But. But. But. But." triggered the same response. Some also noticed putting any of the terms like "Also, Therefore, And, Anyway, But, Who, Why, Besides, However," in the same format achieved the outcome.

Once crashed, you may not be able to easily re-access the document as doing so would trigger the crash again. BleepingComputer was able to reproduce the issue last night and reached out to Google. Google told us it is aware of the bug and working on a fix. [...] Until Google has an answer as to what causes this problem, it might be wise to turn off grammar suggestions by navigating to Tools, Spelling and grammar and unticking 'Show grammar suggestions.' If the bug has already been triggered and you're locked out of the Google Doc in question, there might be a workaround. Use the Google Docs mobile app to access the document, remove the offending words and the file should now open up gracefully on your Google Docs web version too.

According to some iPhone users, the Apple Music iOS app is installing itself directly to the iPhone's dock when downloaded, instead of to the phone's home screen. "It's also kicking out other apps users had set up in their dock and taking their spot, which is not something apps would normally do," adds TechCrunch. From the report: Some iPhone owners also found the bug was causing Apple Music to establish itself as the default music service for Siri requests, even if another service had previously been configured for this, like Spotify. It's unclear how widespread the bug is at this time, as we've tested it internally with mixed results. However, we've seen the dock issue taking place across different versions of iOS 15, old and new, so it does not appear to be related to a recent iOS update. It's also been seen impacting different iPhone models. [...] Apple was not able to provide further details about the bug, but said it's looking into it. You can view the "odd behavior" in a video posted on Twitter by iOS developer Kevin Archer.

Hot Hardware warns that on Tuesday, the Stable Channel for Chrome's desktop edition "had an update on April 26, 2022. That update includes 30 security fixes, some of them so bad that Google is urging all users to update immediately." The release notes for Google's Chrome v101.0.4951.41 for Windows, Mac, and Linux has a long list of bug fixes; you can view it here. However, there's also a key statement in that page.

"Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven't yet fixed...."

Effectively the the non-developer translation of the quote above is that something so significant was found, the details are being kept hidden.

Long-time Slashdot reader UnderAttack writes: After Microsoft patched and went public with CVE-2022-26809, the recent Remote Procedure Call vulnerability, the SANS Internet Storm Center set up a complete Windows 10 system exposing port 445/TCP "to the world." The system is not patched for the RPC vulnerability. But so far, while it has seen thousands of attacks against SMB a day, nothing yet for the new RPC vulnerability....

But still, attackers are heavily hitting other vulnerabilities like of course still ETERNALBLUE
From the article: Should you stop rushing out the April patch? Absolutely not. I hope you are already done applying the patch. But the April Windows patch had several additional gems, not just patches for RPC. Chatter about CVE-2022-26809 has died down, but as they say: Sometimes the quiet ones are the dangerous ones, and people able to exploit this vulnerability may not broadcast what they are doing on social media.
The article is credited to Johannes B. Ullrich, Ph.D. , Dean of Research at the security site SANS.edu.

Interestingly, Ullrich's byline is hyperlinked to a Google+ profile which has been unavailable for nearly three years.

"The Register reports Microsoft fixed a Point of Sale bug that delayed Windows 11 startup for 40 minutes," writes Slashdot reader ellithligraw. "So much for the express lane at check-out." From the report: A fresh Windows 11 patch slipped out overnight as an optional update, but contains an impressively long list of fixes for Microsoft's flagship operating system. One bug addressed in KB5012643 could leave Point of Sale terminals hanging for up to 40 minutes during startup. Microsoft stated, "We fixed an issue that delays OS startup by approximately 40 minutes." "Microsoft described the fixes as 'improvements' [and chose to highlight the fact that temperature would now be displayed on top of the weather icon on the taskbar]," added Slashdot reader ellithligraw. "[Y]eah, Windows 11 is great as a PoS."

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."