"Security researchers are blasting Apple for a feature in the latest Big Sur release of macOS that allows some Apple apps to bypass content filters and VPNs..." reports Threatpost. "While users assumed Apple would fix the flaw before the OS emerged from beta into full release, this doesn't appear to have happened."

"Beginning with macOS Catalina released last year, Apple added a list of 50 Apple-specific apps and processes that were to be exempted from firewalls like Little Snitch and Lulu," explains Ars Technica: The undocumented exemption, which didn't take effect until firewalls were rewritten to implement changes in Big Sur, first came to light in October. Patrick Wardle, a security researcher at Mac and iOS enterprise developer Jamf, further documented the new behavior over the weekend. To demonstrate the risks that come with this move, Wardle — a former hacker for the NSA — demonstrated how malware developers could exploit the change to make an end-run around a tried-and-true security measure...

Wardle tweeted a portion of a bug report he submitted to Apple during the Big Sur beta phase. It specifically warns that "essential security tools such as firewalls are ineffective" under the change.

Apple has yet to explain the reason behind the change.

Reader shanen shares a report (and offers this commentary): When the open source concept emerged in the '90s, it was conceived as a bold new form of communal labor: digital barn raisings. If you made your code open source, dozens or even hundreds of programmers would chip in to improve it. Many hands would make light work. Everyone would feel ownership. Now, it's true that open source has, overall, been a wild success. Every startup, when creating its own software services or products, relies on open source software from folks like Jacob Thornton: open source web-server code, open source neural-net code. But, with the exception of some big projects -- like Linux -- the labor involved isn't particularly communal. Most are like Bootstrap, where the majority of the work landed on a tiny team of people. Recently, Nadia Eghbal -- the head of writer experience at the email newsletter platform Substack -- published Working in Public, a fascinating book for which she spoke to hundreds of open source coders. She pinpointed the change I'm describing here. No matter how hard the programmers worked, most "still felt underwater in some shape or form," Eghbal told me.

Why didn't the barn-raising model pan out? As Eghbal notes, it's partly that the random folks who pitch in make only very small contributions, like fixing a bug. Making and remaking code requires a lot of high-level synthesis -- which, as it turns out, is hard to break into little pieces. It lives best in the heads of a small number of people. Yet those poor top-level coders still need to respond to the smaller contributions (to say nothing of requests for help or reams of abuse). Their burdens, Eghbal realized, felt like those of YouTubers or Instagram influencers who feel overwhelmed by their ardent fan bases -- but without the huge, ad-based remuneration. Sometimes open source coders simply walk away: Let someone else deal with this crap. Studies suggest that about 9.5 percent of all open source code is abandoned, and a quarter is probably close to being so. This can be dangerous: If code isn't regularly updated, it risks causing havoc if someone later relies on it. Worse, abandoned code can be hijacked for ill use. Two years ago, the pseudonymous coder right9ctrl took over a piece of open source code that was used by bitcoin firms -- and then rewrote it to try to steal cryptocurrency.

Go SMS Pro, one of the most popular messaging apps for Android, is exposing photos, videos and other files sent privately by its users. Worse, the app maker has done nothing to fix the bug. TechCrunch reports: Security researchers at Trustwave discovered the flaw in August and contacted the app maker with a 90-day deadline to fix the issue, as is standard practice in vulnerability disclosure to allow enough time for a fix. But after the deadline elapsed without hearing back, the researchers went public. Trustwave shared its findings with TechCrunch this week.

When a Go SMS Pro user sends a photo, video or other file to someone who doesn't have the app installed, the app uploads the file to its servers, and lets the user share a web address by text message so the recipient can see the file without installing the app. But the researchers found that these web addresses were sequential. In fact, any time a file was shared -- even between app users -- a web address would be generated regardless. That meant anyone who knew about the predictable web address could have cycled through millions of different web addresses to users' files. Go SMS Pro has more than 100 million installs, according to its listing in Google Play.

Apple has updated a documentation page detailing the company's next steps to prevent last week's Gatekeeper bug from happening again. The company plans to implement the fixes over the next year. From a report: Apple had a difficult launch day last week. The company released macOS Big Sur, a major update for macOS. Apple then suffered from server-side issues. Third-party apps failed to launch as your Mac couldn't check the developer certificate of the app. That feature, called Gatekeeper, makes sure that you didn't download a malware app that disguises itself as a legit app. If the certificate doesn't match, macOS prevents the app launch. Many have been concerned about the privacy implications of the security feature. Does Apple log every app you launch on your Mac to gain competitive insights on app usage? It turns out it's easy to answer that question as the server doesn't mandate encryption. Jacopo Jannone intercepted an unencrypted network request and found out that Apple is not secretly spying on you. Gatekeeper really does what it says it does. "We have never combined data from these checks with information about Apple users or their devices. We do not use data from these checks to learn what individual users are launching or running on their devices," the company wrote.

"Ubuntu developers have fixed a series of vulnerabilities that made it easy for standard users to gain coveted root privileges," reports Ars Technica: "This blog post is about an astonishingly straightforward way to escalate privileges on Ubuntu," Kevin Backhouse, a researcher at GitHub, wrote in a post published on Tuesday. "With a few simple commands in the terminal, and a few mouse clicks, a standard user can create an administrator account for themselves."

The first series of commands triggered a denial-of-service bug in a daemon called accountsservice, which as its name suggests is used to manage user accounts on the computer... With the help of a few extra commands, Backhouse was able to set a timer that gave him just enough time to log out of the account before accountsservice crashed. When done correctly, Ubuntu would restart and open a window that allowed the user to create a new account that — you guessed it — had root privileges...

The second bug involved in the hack resided in the GNOME display manager, which among other things manages user sessions and the login screen. The display manager, which is often abbreviated as gdm3, also triggers the initial setup of the OS when it detects no users currently exist. "How does gdm3 check how many users there are on the system?" Backhouse asked rhetorically. "You probably already guessed it: by asking accounts-daemon! So what happens if accounts-daemon is unresponsive....?"

The vulnerabilities could be triggered only when someone had physical access to, and a valid account on, a vulnerable machine. It worked only on desktop versions of Ubuntu.
"This bug is now tracked as CVE-2020-16125 and rated with a high severity score of 7.2 out of 10. It affects Ubuntu 20.10, Ubuntu 20.04, and Ubuntu 18.04..." reports Bleeping Computer.

They add that the GitHub security research who discovered the bugs "reported them to Ubuntu and GNOME maintainers on October 17, and fixes are available in the latest code."

An anonymous reader shares an excerpt from Wired: On Monday morning, when representatives from the drug company Pfizer said that its Covid-19 vaccine appears to be more than 90 percent effective, stocks soared, White House officials rushed to (falsely) claim credit, and sighs of relief went up all around the internet. [...] The arrival of an effective vaccine to fight SARS-CoV-2 less than a year after the novel coronavirus emerged would smash every record ever set by vaccine makers. "Historic isn't even the right word," says Larry Corey of the Vaccine and Infectious Disease Division at the Fred Hutchinson Cancer Center. A renowned virologist, Corey has spent the last three decades leading the search for a vaccine against the virus that causes AIDS. He's never seen an inoculation developed for a new bug in under five years, let alone one. "It's never happened before, never, not even close," he says. "It's just an amazing accomplishment of science."

And perhaps even more monumental is the kind of vaccine that Pfizer and BioNTech are bringing across the finish line. The active ingredient inside their shot is mRNA -- mobile strings of genetic code that contain the blueprints for proteins. Cells use mRNA to get those specs out of hard DNA storage and into their protein-making factories. The mRNA inside Pfizer and BioNTech's vaccine directs any cells it reaches to run a coronavirus spike-building program. The viral proteins these cells produce can't infect any other cells, but they are foreign enough to trip the body's defense systems. They also look enough like the real virus to train the immune system to recognize SARS-CoV-2, should its owner encounter the infectious virus in the future. Up until now, this technology has never been approved for use in people. A successful mRNA vaccine won't just be a triumph over the new coronavirus, it'll be a huge leap forward for the science of vaccine making.

[I]n the last decade, the field has started to move away from this see-what-sticks approach toward something pharma folks call "rational drug design." It involves understanding the structure and function of the target -- like say, the spiky protein SARS-CoV-2 uses to get into human cells -- and building molecules that can either bind to that target directly, or produce other molecules that can. Genetic vaccines represent an important step in this scientific evolution. Engineers can now design strands of mRNA on computers, guided by algorithms that predict which combination of genetic letters will yield a viral protein with just the right shape to prod the human body into producing protective antibodies. In the last few years, it's gotten much easier and cheaper to make mRNA and DNA at scale, which means that as soon as scientists have access to a new pathogen's genome, they can start whipping up hundreds or thousands of mRNA snippets to test -- each one a potential vaccine. The Chinese government released the genetic sequence of SARS-CoV-2 in mid-January. By the end of February, BioNTech had identified 20 vaccine candidates, of which four were then selected for human trials in Germany. [...] Genetic vaccines might be proving they can work -- but it's still not definitive, and they may not yet work for everyone. That's why experts say it's so crucial to continue supporting ongoing trials for the more than 60 other vaccine candidates still in various stages of human testing. What older technologies lack in terms of speed, they make up for in durability.

Google Project Zero, the Google security team that finds bugs in all popular software, has disclosed what it classes a high-severity flaw on GitHub after the code-hosting site asked for a double extension on the normal 90-day disclosure deadline. From a report: The bug in GitHub's Actions feature -- a developer workflow automation tool -- has become one of the rare vulnerabilities that wasn't properly fixed before Google Project Zero's (GPZ) standard 90-day deadline expired. Over 95.8% of flaws are fixed within the deadline, according to Google's hackers. GPZ is known to be generally strict with its 90-day deadline, but it appears GitHub was a little lax in its responses as the deadline approached after Google gave it every chance to fix the bug. As detailed in a disclosure timeline by GPZ's Felix Wilhelm, the Google security team reported the issue to GitHub's security on July 21 and a disclosure date was set for October 18. According to Wilhelm, Actions' workflow commands are "highly vulnerable to injection attacks."

iFixit: After exhaustive testing, comparing notes with multiple repair technicians, and reviewing leaked Apple training documents, we've found that the iPhone 12 camera is entirely unreliable when swapped between iPhones. This latest fault, along with indications from Apple's repair guides, makes it more clear than ever: Apple, by design or neglect or both, is making it extremely hard to repair an iPhone without their blessing. This may be a bug that Apple eventually fixes. There is even precedent for iPhone parts misbehaving when swapped between phones.

But it is also possible that Apple is planning on locking out all unauthorized iPhone camera and screen repairs. Apple's internal training guides tell authorized technicians that, starting with the 12 and its variants, they will need to run Apple's proprietary, cloud-linked System Configuration app to fully repair cameras and screens. We are very concerned about this possibility.

"Google released an update to its Chrome browser that patches a zero-day vulnerability in the software's FreeType font rendering library that was actively being exploited in the wild, Threatpost reported this week: Security researcher Sergei Glazunov of Google Project Zero discovered the bug which is classified as a type of memory-corruption flaw called a heap buffer overflow in FreeType. Glazunov informed Google of the vulnerability on Monday. Project Zero is an internal security team at the company aimed at finding zero-day vulnerabilities.

By Tuesday, Google already had released a stable channel update, Chrome version 86.0.4240.111, that deploys five security fixes for Windows, Mac & Linux — among them a fix for the zero-day, which is being tracked as CVE-2020-15999 and is rated as high risk. "Google is aware of reports that an exploit for CVE-2020-15999 exists in the wild," Prudhvikumar Bommana of the Google Chrome team wrote in a blog post announcing the update Tuesday... "The fix is also in today's stable release of FreeType 2.10.4," Ben Hawkes, technical lead for the Project Zero team, tweeted. Meanwhile, security researchers took to Twitter to encourage people to update their Chrome browsers immediately to avoid falling victim to attackers aiming to exploit the flaw...

In addition to the FreeType zero day, Google patched four other bugs — three of high risk and one of medium risk — in the Chrome update released this week... So far in the last 12 months Google has patched three zero-day vulnerabilities in its Chrome browser.

This week the Verge reported: If you ask Chrome to delete all cookies and site data whenever you quit the browser, it's reasonable to expect that this policy applies to all websites. Recently, though, a bug in the browser meant data wasn't being removed for two sites in particular: Google and YouTube.

This problem was first documented by iOS developer Jeff Johnson on his blog. Johnson found that in Chrome version 86.0.4240.75, "local storage" data for Google.com and YouTube.com stuck around even after restarting the browser. We've been able to replicate similar behavior... The Register notes that Chrome's behavior could allow Google to stash cookie-style data as site data, allowing it to track users even when they think they're being careful by deleting their cookie and site data every time they close the browser.

In a statement, Google said it was aware of the issue and was working on a fix... At least one of the affected sites, YouTube, appears to have already been fixed. After we upgraded the Chrome browser to version 86.0.4240.111, YouTube's local storage data seems to successfully purge after a restart, although the data from Google.com still sticks around.

An anonymous reader quotes a report from NPR: Remember the "murder hornets"? You know, the terrifyingly large Asian giant hornets that are threatening to wipe out the North American bee population? Entomologists with the Washington State Department of Agriculture have now located a nest of them -- the first to be found in the U.S., the agency says. The nest was discovered in the cavity of a tree on a property in the city of Blaine, near the Canadian border.

This achievement closely follows another advance: State entomologists had recently had luck trapping the hornets. This week, they were able to collect four live Asian giant hornets using a new type of trap -- and managed to attach radio trackers to three of them. One of those tagged hornets led staffers to the nest. The plan now? Destroy the nest. The agency says it intends to eradicate it on Saturday, removing the tree if necessary. Asian giant hornets are an invasive pest that prey on honeybees and other insects. "Only a couple of hornets can slaughter an entire healthy honeybee hive in just a matter of a few hours," Sven-Erik Spichiger, chief entomologist for the state's agriculture department, told NPR last week.

The official public repository for CUPS, an Apple open-source project widely used for printing on Linux, is all-but dormant since the lead developer left Apple at the end of 2019. From a report: Apple adopted CUPS for Mac OS X in 2002, and hired its author Michael Sweet in 2007, with Cupertino also acquiring the CUPS source code. Sweet continued to work on printing technology at Apple, including CUPS, until December 2019 when he left to start a new company. Asked at the time about the future of CUPS, he said: "CUPS is still owned and maintained by Apple. There are two other engineers still in the printing team that are responsible for CUPS development, and it will continue to have new bug fix releases (at least) for the foreseeable future." Despite this statement, Linux watcher Michael Larabel noted earlier this week that "the open-source CUPS code-base is now at a stand-still. There was just one commit to the CUPS Git repository for all of 2020." This contrasts with 355 commits in 2019, when Sweet still worked at Apple, and 348 the previous year. We asked Apple about its plans for CUPS and have yet to hear back.

An anonymous reader quotes a report from Ars Technica: Google and Intel are warning of a high-severity Bluetooth flaw in all but the most recent version of the Linux Kernel. While a Google researcher said the bug allows seamless code execution by attackers within Bluetooth range, Intel is characterizing the flaw as providing an escalation of privileges or the disclosure of information. The flaw resides in BlueZ, the software stack that by default implements all Bluetooth core protocols and layers for Linux. Besides Linux laptops, it's used in many consumer or industrial Internet-of-things devices. It works with Linux versions 2.4.6 and later. So far, little is known about BleedingTooth, the name given by Google engineer Andy Nguyen, who said that a blog post will be published "soon." A Twitter thread and a YouTube video provide the most detail and give the impression that the bug provides a reliable way for nearby attackers to execute malicious code of their choice on vulnerable Linux devices that use BlueZ for Bluetooth.

Intel, meanwhile, has issued this bare-bones advisory that categorizes the flaw as privilege-escalation or information-disclosure vulnerability. The advisory assigned a severity score of 8.3 out of a possible 10 to CVE-2020-12351, one of three distinct bugs that comprise BleedingTooth. "Potential security vulnerabilities in BlueZ may allow escalation of privilege or information disclosure," the advisory states. "BlueZ is releasing Linux kernel fixes to address these potential vulnerabilities." Intel, which is a primary contributor to the BlueZ open source project, said that the most effective way to patch the vulnerabilities is to update to Linux kernel version 5.9, which was published on Sunday. Those who can't upgrade to version 5.9 can install a series of kernel patches the advisory links to. Maintainers of BlueZ didn't immediately respond to emails asking for additional details about this vulnerability. Ars Technica points out that since BleedingTooth requires proximity to a vulnerable device, there's not much reason for people to worry about this vulnerability. "It also requires highly specialized knowledge and works on only a tiny fraction of the world's Bluetooth devices," it adds.

The Xplora 4 smartwatch, made by Chinese outfit Qihoo 360 Technology Co, and marketed to children under the Xplora brand in the US and Europe, can covertly take photos and record audio when activated by an encrypted SMS message, says Norwegian security firm Mnemonic. The Register reports: This backdoor is not a bug, the finders insist, but a deliberate, hidden feature. Around 350,000 watches have been sold so far, Xplora says. Exploiting this security hole is non-trivial, we note, though it does reveal the kind of remotely accessible stuff left in the firmware of today's gizmos. "The backdoor itself is not a vulnerability," said infosec pros Harrison Sand and Erlend Leiknes in a report on Monday. "It is a feature set developed with intent, with function names that include remote snapshot, send location, and wiretap. The backdoor is activated by sending SMS commands to the watch."

The researchers suggest these smartwatches could be used to capture photos covertly from its built-in camera, to track the wearer's location, and to conduct wiretapping via the built-in mic. They have not claimed any such surveillance has actually been done. The watches are marketed as a child's first phone, we're told, and thus contain a SIM card for connectivity (with an associated phone number). Parents can track the whereabouts of their offspring by using an app that finds the wearer of the watch. Xplora contends the security issue is just unused code from a prototype and has now been patched. But the company's smartwatches were among those cited by Mnemonic and Norwegian Consumer Council in 2017 for assorted security and privacy concerns.

With the appropriate Android intent, an incoming encrypted SMS message received by the Qihoo SMS app could be directed through the command dispatcher in the Persistent Connection Service to trigger an application command, like a remote memory snapshot. Exploiting this backdoor requires knowing the phone number of the target device and its factory-set encryption key. This data is available to those to Qihoo and Xplora, according to the researchers, and can be pulled off the device physically using specialist tools. This basically means ordinary folks aren't going to be hacked, either by the manufacturer under orders from Beijing or opportunistic miscreants attacking gizmos in the wild, though it is an issue for persons of interest. It also highlights the kind of code left lingering in mass-market devices.

A security flaw in a hi-tech chastity belt for men made it possible for hackers to remotely lock all the devices in use simultaneously. The BBC reports: Qiui's Cellmate Chastity Cage is sold online for about $190 and is marketed as a way for owners to give a partner control over access to their body. Pen Test Partners believe about 40,000 devices have been sold based on the number of IDs that have been granted by its Guangdong-based creator. The cage wirelessly connects to a smartphone via a Bluetooth signal, which is used to trigger the device's lock-and-clamp mechanism. But to achieve this, the software relies on sending commands to a computer server used by the manufacturer.

The security researchers said they discovered a way to fool the server into disclosing the registered name of each device owner, among other personal details, as well as the co-ordinates of every location from where the app had been used. In addition, they said, they could reveal a unique code that had been assigned to each device. These could be used to make the server ignore app requests to unlock any of the identified chastity toys, they added, leaving wearers locked in.

The sex toy's app has been fixed by its Chinese developer after a team of UK security professionals flagged the bug. They have also published a workaround. This could be useful to anyone still using the old version of the app who finds themselves locked in as a result of an attacker making use of the revelation. Any other attempt to cut through the device's plastic body poses a risk of harm.

Apple has confirmed several problems including "increased battery drain" for some users who upgraded their iPhone to iOS 14. But ZDNet warns Apple's proposed solution "sounds pretty drastic."

Forbes reports: In an official post, Apple reveals seven significant data and battery-related problems with iOS 14 and watchOS 7, and the company states the only fix is to "erase all content and settings from your iPhone".

Breaking these down, Apple classifies six as related to its Activity, Health and Fitness apps as well as the broader problem of "Increased battery drain on your iPhone or Apple Watch." The latter will not be a surprise to anyone who has seen the growing number of complaints directed at the company's @AppleSupport Twitter account since iOS 14 was released...

On the plus side, Apple's belief that these problems can be fixed without an iOS update is good news. That said, a complete data wipe is also the nuclear option, so Apple is not messing around... I would also be amazed if iOS 14.0.2 is not being fast tracked as we speak.

"Hello Chrome OS Community," posted one of Google's community managers Wednesday. "Thank you for raising this issue, and for your patience as we work to resolve this. Our team has identified the issue and is rolling out a fix to affected devices."

The issue? ChromeOS users reported the latest updates "cause a Google Play Store service to utilize 100 percent of their CPUs..." according to TechRadar, "making their devices hot and leading to performance issues." As reported by BleepingComputer, after upgrading their devices to ChromeOS version 85.0.4183.108 and later users have faced a number of issues including apps that are running erratically, devices getting hot, fans running at high speed and batteries draining much too quickly. Upon investigating these issues further, users discovered that they were caused by the Google Play 'com.android.vending:download_service' utilizing 95 to 100 percent of their devices CPU for an extended period. This service is used to download new updates from the Google Play Store when they become available. However, a bug in the service causes the CPU to run at 100 percent power all of the time even when a new update is not available.
Bleeping Computer reported last Sunday that the issues didn't affect all Chromebooks, but was reported by users of Acer Chromebooks, ASUS Chromebook Flip, and Galaxy Chromebooks. "One user stated they resolved this issue by rolling back to an older Google Play Store version."

"Google is hiring to create a special Android security team that will be tasked with finding vulnerabilities in highly sensitive apps on the Google Play Store," reports ZDNet: "As a Security Engineering Manager in Android Security... Your team will perform application security assessments against highly sensitive, third party Android apps on Google Play, working to identify vulnerabilities and provide remediation guidance to impacted application developers," reads a new Google job listing posted on Wednesday.

Applications that this new team will focus on include the likes of COVID-19 contact tracing apps and election-related applications, with others to follow, according to Sebastian Porst, Software Engineering Manager for Google Play Protect.

"Anyone can access portions of a web portal used by law enforcement to request customer data from Amazon," reports TechCrunch, "even though the portal is supposed to require a verified email address and password..." Only time sensitive emergency requests can be submitted without an account, but this requires the user to "declare and acknowledge" that they are an authorized law enforcement officer before they can submit a request.

The portal does not display customer data or allow access to existing law enforcement requests. But parts of the website still load without needing to log in, including its dashboard and the "standard" request form used by law enforcement to request customer data... Assuming this was a bug, we sent Amazon several emails prior to publication but did not hear back...

Motherboard reported a similar issue earlier this month that allowed anyone with an email address to access law enforcement portals set up by Facebook and WhatsApp.

"Mozilla has fixed a bug that can be abused to hijack all the Firefox for Android browsers on the same Wi-Fi network and force users to access malicious sites, such as phishing pages," reports ZDNet: The bug was discovered by Chris Moberly, an Australian security researcher working for GitLab. The actual vulnerability resides in the Firefox SSDP component. SSDP stands for Simple Service Discovery Protocol and is the mechanism through which Firefox finds other devices on the same network in order to share or receive content (i.e., such as sharing video streams with a Roku device).

When devices are found, the Firefox SSDP component gets the location of an XML file where that device's configuration is stored. However, Moberly discovered that in older versions of Firefox, you could hide Android "intent" commands in this XML and have the Firefox browser execute the "intent," which could be a regular command like telling Firefox to access a link...

The bug was fixed in Firefox 79; however, many users may not be running the latest release. Firefox for desktop versions were not impacted.