Open3.pm tries to run code in /tmp when preconfiguring packages

[Andrew J. Caines]

During update of ubuntu-drivers-common:

  Can't exec "/tmp/ubuntu-drivers-common.config.55GJ8b": Permission denied at /usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm line 178, <GEN0> line 1.
open2: exec of /tmp/ubuntu-drivers-common.config.55GJ8b configure 1:0.9.6.2~0.22.04.4 failed: Permission
  denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.
  Preconfiguring packages ...
  Can't exec "/tmp/ubuntu-drivers-common.config.uSPrCH": Permission denied at /usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm line 178, <GEN0> line 1.
  open2: exec of /tmp/ubuntu-drivers-common.config.uSPrCH configure 1:0.9.6.2~0.22.04.4 failed: Permission
  denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.

/tmp is mounted with noexec because running code from /tmp has been a vulnerability vector for several decades, hence reporting this as a vulnerability in perl-base.

This error did not appear to prevent the update of ubuntu-drivers-common and "dpkg --verify ubuntu-drivers-common" returns 0.

___________________________________________________________________________________________________________

Attempting to use the package search on this form by clicking the 🔍 created a modal in which there is an error

  Sorry, something went wrong with your search. We've recorded what happened, and we'll fix it as soon as possible. (Error ID: OOPS-c80f71590b02908a1187b9f743c53eac)

which is repeated with any attempt to search for a package.

___________________________________________________________________________________________________________

Submitting this form gives an error

  "perl-base" does not exist in Ubuntu. Please choose a different package. If you're unsure, please select "I don't know"

  $ dpkg -S /usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm
  perl-base: /usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm
  $ dpkg -l perl-base
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name Version Architecture Description
  +++-==============-=================-============-=============================>
  ii perl-base 5.34.0-3ubuntu1.2 amd64 minimal Perl system

Looks like a package to me. Nevertheless, using "Did you mean..." offers "perl".

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: perl-base 5.34.0-3ubuntu1.2
ProcVersionSignature: Ubuntu 6.5.0-1007.7-oem 6.5.3
Uname: Linux 6.5.0-1007-oem x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Thu Nov 16 10:08:48 2023
InstallationDate: Installed on 2016-04-23 (2763 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
ProcEnviron:
 TERM=rxvt
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: perl
UpgradeStatus: Upgraded to jammy on 2022-08-19 (453 days ago)

[Steve Langasek (vorlon)]

This is not a security bug, or a bug at all in perl.

Software that executes commands under /tmp is not intrinsically insecure. Various hardening guides recommend mounting /tmp noexec because it's harder for programmers to get security handling of files under /tmp *right*; but an attempt to execute a command under /tmp is not evidence that the programmer has gotten it wrong.

The perl package did not create the file /tmp/ubuntu-drivers-common.config.55GJ8b and try to execute it. This was done by some other software that then invoked perl to try to execute it. Perl should not refuse to try to execute the command because the path starts with "/tmp", it should do what it has been asked to do.

The specific path in use is suggestive of a debconf config script that has been unpacked as part of the apt "pre-configuration" stage and is being run from a temporary directory. However, the normal interface for this is /usr/sbin/dpkg-preconfigure as invoked via /etc/apt/apt.conf.d/70debconf; and dpkg-preconfigure explicitly specifies to extract the config script to /var/cache/debconf/tmp.ci in order to avoid site policies that restrict execution of binaries under /tmp. So I do not know why this script has been unpacked to /tmp on your system; that does not appear to be the normal flow of operation (and also has not been, for decades).

Since there is not a confirmed securtiy bug here, and since I don't know where those files on your system came from, I am closing this bug invalid. If you can provide further information that would show this path is coming from an Ubuntu package, it would be appropriate to reopen the bug report and assign it to the corresponding package.

I am also marking this as a public non-security bug.

[Julian Andres Klode (juliank)]

This might in fact be debconf itself that tries to place it there, in a system without dpkg-preconfigure aka without apt-utils installed or where it couldn't be preconfigured

[Andrew J. Caines (cainesaj)]

@vorlon, Thank you for your considered response. I concur that this is not a vulnerability in the Ubuntu perl package.

While I do not disagree with any of the points you make, the fact remains that processes running as root created a file directly in /tmp not using a safe *mktemp* process and later ran the code in that file. The risks of doing this are sufficiently well understood, as the preferable alternatives.

Given that that this quite vanilla Ubuntu system and that this behaviour was only observed as a result of the reasonable and fairly common configuration of mounting `/tmp` with *noexec* and did so while running updates in a fully supported manner, i.e. with *Software Updater*, this remains a bug with a directly associated security risk. That is to say - as you expressed it - this comes from an Ubuntu package, though I don't know which.

Do you recommend that I do anything other than change the Package to "debconf" and Status to "New"?

@juliank, *apt-utils* is installed.

[Alex Murray (alexmurray)]

I am struggling to see the vulnerability here still - the path used in this case is /tmp/ubuntu-drivers-common.config.55GJ8b appears to have a randomly generated suffix and so couldn't have been guessed beforehand nor preseeded with other contents by a local attacker - so the only way then that I can see that this could be a vulnerability would be if this file was world-writable - but it is not clear that this is the case either.

Assuming this file comes from debconf, from what I can see in its sources, it creates temporary files via the https://perldoc.perl.org/File::Temp package - which states that files are created with permissions 0600 by default too.

[Andrew J. Caines (cainesaj)]

You are of course quite right that the risk associated with a file created with a "random" six character case-insensitive alphanumeric suffix and run a moment later is far smaller than more obviously risky misuses of /tmp. Nevertheless the issue is not about evaluating the risk of an adversary creating over forty-four milliard files or symlinks per package in /tmp, or if the code checks for the presence of the file before trying to create it (which I trust it does), or just how random the suffix really is, or how many race conditions might exist, or any of the other cases we've seen exploited over the decades, but that this is even a matter to consider in late 2024.

Since you mention it specifically, creating the file with mode 600 will (or certainly should) of course prevent the contents of the file from being overwritten by another user between creation and execution.

I consider it uncontroversial to claim that a standard process for updating software on Ubuntu should not
1) involve creating executables (or files containing code to be executed) directly in /tmp and running them as root, and
2) result in errors when /tmp is mounted noexec, especially when they may indicate unhandled breakage.

I briefly observed more similar errors during an update earlier today, but was not quick enough to capture more details before the Software Updater output window disappeared; however I doubt those details provided any more useful information.

[Steve Langasek (vorlon)]

On Mon, Nov 20, 2023 at 08:50:05PM -0000, Andrew J. Caines wrote:
> You are of course quite right that the risk associated with a file
> created with a "random" six character case-insensitive alphanumeric
> suffix and run a moment later is far smaller than more obviously risky
> misuses of /tmp.

No. The use of a random filename is not a security feature; it is a
mechanism to avoid filename *collisions* (either accidental or as part of a
denial of service).

> or if the code checks for the presence of the file before trying to create
> it (which I trust it does)

That is not how you securely handle temp files.

I'm sorry, but you have a very incomplete understanding of how secure temp
file handling works.

You have /tmp mounted noexec on your system. This is fine, and supported.

It is not a protection against vulnerable system code. It is a mechanism to
protect against attackers from writing payload code to /tmp and then
executing it.

System software must handle temp files under /tmp securely *independently of
whether the files it's writing are intended to be executed*.

You have something on your system trying to write a file to /tmp and then
execute it. That should be fixed. But it's not a bug in perl, and it's not
a bug in apt-utils, and it's entirely unclear what code is doing this since
this in not part of the standard debconf code path.

If you can identify where this is coming from in Ubuntu, we can reassign the
bug report and get it fixed.

The rest is off-topic for an Ubuntu bug report.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
<email address hidden> <email address hidden>

[Steve Langasek (vorlon)]

On Sun, Nov 19, 2023 at 08:02:42PM -0000, Andrew J. Caines wrote:

> the fact remains that processes running as root created a file directly in
> /tmp not using a safe *mktemp* process

There is no evidence in this bug of unsafe temp file creation in /tmp.

[Andrew J. Caines (cainesaj)]

I will attempt to capture more details when I next observe the error so that the correct package can be identified for this report.

[Andrew J. Caines (cainesaj)]

Caught the error again, again while running in Software Updater, but I captured the output from the beginning. There were only four related packages being updated.

Preconfiguring packages ...
Can't exec "/tmp/cryptsetup-initramfs.config.UaZ02N": Permission denied at /usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm line 178, <GEN0> line 1.
open2: exec of /tmp/cryptsetup-initramfs.config.UaZ02N configure 2:2.4.3-1ubuntu1.1 failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.
Preconfiguring packages ...
Can't exec "/tmp/cryptsetup-initramfs.config.dTuBRN": Permission denied at /usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm line 178, <GEN0> line 1.
open2: exec of /tmp/cryptsetup-initramfs.config.dTuBRN configure 2:2.4.3-1ubuntu1.1 failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.
(Reading database ... 247176 files and directories currently installed.)
Preparing to unpack .../libcryptsetup12_2%3a2.4.3-1ubuntu1.2_amd64.deb ...
Unpacking libcryptsetup12:amd64 (2:2.4.3-1ubuntu1.2) over (2:2.4.3-1ubuntu1.1) ...
Preparing to unpack .../cryptsetup-initramfs_2%3a2.4.3-1ubuntu1.2_all.deb ...
Unpacking cryptsetup-initramfs (2:2.4.3-1ubuntu1.2) over (2:2.4.3-1ubuntu1.1) ...
Preparing to unpack .../cryptsetup-bin_2%3a2.4.3-1ubuntu1.2_amd64.deb ...
Unpacking cryptsetup-bin (2:2.4.3-1ubuntu1.2) over (2:2.4.3-1ubuntu1.1) ...
Preparing to unpack .../cryptsetup_2%3a2.4.3-1ubuntu1.2_amd64.deb ...
Unpacking cryptsetup (2:2.4.3-1ubuntu1.2) over (2:2.4.3-1ubuntu1.1) ...
Setting up libcryptsetup12:amd64 (2:2.4.3-1ubuntu1.2) ...
Setting up cryptsetup-bin (2:2.4.3-1ubuntu1.2) ...
Setting up cryptsetup (2:2.4.3-1ubuntu1.2) ...
Setting up cryptsetup-initramfs (2:2.4.3-1ubuntu1.2) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for libc-bin (2.35-0ubuntu3.5) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for initramfs-tools (0.140ubuntu13.4) ...
update-initramfs: Generating /boot/initrd.img-6.5.0-1009-oem
...

Since ConfModule.pm is part of debconf, the errors occur during "Preconfiguring packages" and earlier speculation, I will presume to attribute this bug to debconf and update the title accordingly.

[Andrew J. Caines (cainesaj)]

Attributing the bug to debconf and setting status to New following advice while (mis)attributed to perl.

[Steve Langasek (vorlon)]

Thanks, this definitely does point at debconf. However:

> Preconfiguring packages ...

This line is from /usr/sbin/dpkg-preconfigure, which is called via /etc/apt/apt.conf.d/70debconf.

> Can't exec "/tmp/cryptsetup-initramfs.config.UaZ02N": Permission denied at /usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm line 178, <GEN0> line 1.

This line shows a path which is NOT where /usr/sbin/dpkg-preconfigure unpacks the configure script. It uses a hard-coded path of /var/cache/debconf/tmp.ci:

my $tempdir='/var/cache/debconf/tmp.ci';
[...]
                        if (system("apt-extracttemplates", "--tempdir", $tempdir, @collect) != 0) {
[...]

What does `readlink -f /var/cache/debconf/tmp.ci` return on your system?

[Andrew J. Caines (cainesaj)]

$ readlink -f /var/cache/debconf/tmp.ci
/var/cache/debconf/tmp.ci

[Steve Langasek (vorlon)]

Ok. Then I still have absolutely no idea how/why this is happening for you, because that doesn't seem to match the code we ship.

Unless you have some non-distribution version of the apt-extracttemplates program installed? (which apt-extracttemplates; sudo apt install debsums; debsums -s apt-utils)

[Andrew J. Caines (cainesaj)]

This system has remained substantially vanilla since the original install - 18.04 if I remember correctly - with only LTS upgrades and I have certainly made no local changes to the packaging tools.

$ which apt-extracttemplates
/usr/bin/apt-extracttemplates
$ debsums -s apt-utils
$

That is to say that there was no output and debsums returned an exit code of 0.