local denial of service due to parsing bugs in arfile.cc

Bug #1899193 reported by kev
262
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apt (Ubuntu)
Undecided
Unassigned
aptdaemon (Ubuntu)
Undecided
Unassigned
python-apt (Ubuntu)
Undecided
Unassigned

Bug Description

# GitHub Security Lab (GHSL) Vulnerability Report: `GHSL-2020-168`, `GHSL-2020-169`, `GHSL-2020-170`

The [GitHub Security Lab](https://securitylab.github.com) team has identified potential security vulnerabilities in aptd.

We are committed to working with you to help resolve these issues. In this report you will find everything you need to effectively coordinate a resolution of these issues with the GHSL team.

If at any point you have concerns or questions about this process, please do not hesitate to reach out to us at `<email address hidden>` (please include `GHSL-2020-168`, `GHSL-2020-169`, or `GHSL-2020-170` as a reference).

If you are _NOT_ the correct point of contact for this report, please let us know!

## Summary

The aptd daemon is a system service for installing and updating packages. It is accessible via [dbus](https://www.freedesktop.org/wiki/Software/dbus/) and has a method named "InstallFile" which is used for installing local `.deb` packages. Although polkit is used to prevent an unprivileged user from using "InstallFile" to install a malicious `.deb` package, it does not prevent aptd from parsing the contents of the `.deb` file. The parsing logic is provided by two packages, [libapt-pkg-dev](https://packages.ubuntu.com/focal/libapt-pkg-dev) and [python-apt](https://packages.ubuntu.com/source/focal/python-apt), and is implemented in C. These two packages contain several bugs, which an unprivileged user can exploit to trigger a local denial of service attack.

## Product

aptd

## Tested Version

* libapt-pkg-dev: version 2.0.2ubuntu0.1
* python-apt: 2.0.0ubuntu0.20.04.1
* Tested on Ubuntu 20.04.1 LTS

## Details

### Issue 1: aptd crash due to integer overflow in arfile.cc (GHSL-2020-168)

A crafted `.deb` package can trigger a negative integer overflow at [arfile.cc, line 116](https://git.launchpad.net/ubuntu/+source/apt/tree/apt-pkg/contrib/arfile.cc?h=applied/ubuntu/focal-updates&id=4c264e60b524855b211751e1632ba48526f6b44d#n116):

```c
Memb->Size -= Len;
```

Due to the integer overflow, the value of `Memb->Size` is `0xFFFFFFFFFFFFFFFF`. This leads to an out-of-memory error at [arfile.cc, line 602](https://git.launchpad.net/ubuntu/+source/python-apt/tree/python/arfile.cc?h=applied/ubuntu/focal-updates&id=0f7cc93acdb51d943114f1cd79002288c4ca4d24#n602):

```c
char* value = new char[member->Size];
```

The out-of-memory error causes aptd to crash.

Please note that the source locations above refer to two separate files, both named `arfile.cc`. The first is from the libapt-pkg-dev package and the second is from the python-apt package.

To trigger the crash, first use the attached source file named "createdeb.c" to generate the malicious `.deb` file:

```bash
gcc createdeb.c -o createdeb
./createdeb crash test.deb
```

Now use `dbus-send` to send the malicious `.deb` file to aptd:

```bash
$ dbus-send --system --type="method_call" --print-reply --dest=org.debian.apt /org/debian/apt org.debian.apt.InstallFile string:`realpath test.deb` boolean:true
method return time=1602245339.731762 sender=:1.287 -> destination=:1.288 serial=8 reply_serial=2
   string "/org/debian/apt/transaction/90f29de930854568964af1918f6ca5eb"
$ dbus-send --system --type="method_call" --print-reply --dest=org.debian.apt /org/debian/apt/transaction/90f29de930854568964af1918f6ca5eb org.debian.apt.transaction.Run
```

Note that you need to use the "transaction id" returned by the first `dbus-send` in the second `dbus-send` command.

#### Impact

This issue may lead to local denial of service.

#### Resources

I have attached `createdeb.c`, which can be used to generate the malicious `.deb` file.

### Issue 2: aptd infinite loop due to integer overflow in arfile.cc (GHSL-2020-169)

This issue is very similar to issue 1, but is caused by a different bug. This bug occurs during the call to `StrToNum` at [arfile.cc, line 92](https://git.launchpad.net/ubuntu/+source/apt/tree/apt-pkg/contrib/arfile.cc?h=applied/ubuntu/focal-updates&id=4c264e60b524855b211751e1632ba48526f6b44d#n92):

```c
StrToNum(Head.Size,Memb->Size,sizeof(Head.Size)) == false)
```

The bug is due to the use of `strtoul` in [StrToNum](https://git.launchpad.net/ubuntu/+source/apt/tree/apt-pkg/contrib/strutl.cc?h=applied/ubuntu/focal-updates&id=4c264e60b524855b211751e1632ba48526f6b44d#n1169):

```c
// StrToNum - Convert a fixed length string to a number /*{{{*/
// ---------------------------------------------------------------------
/* This is used in decoding the crazy fixed length string headers in
   tar and ar files. */
bool StrToNum(const char *Str,unsigned long &Res,unsigned Len,unsigned Base)
{
   char S[30];
   if (Len >= sizeof(S))
      return false;
   memcpy(S,Str,Len);
   S[Len] = 0;

   // All spaces is a zero
   Res = 0;
   unsigned I;
   for (I = 0; S[I] == ' '; I++);
   if (S[I] == 0)
      return true;

   char *End;
   Res = strtoul(S,&End,Base); <====== negative numbers accepted
   if (End == S)
      return false;

   return true;
}
```

The bug is that `strtoul` allows the number to be negative. For example, it will accept the string "-60". I have written a proof-of-concept exploit which uses this to put the parser into an infinite loop.

To run the proof-of-concept, first use the attached source file named "createdeb.c" to generate the malicious `.deb` file:

```bash
gcc createdeb.c -o createdeb
./createdeb loop test.deb
```

Now use `dbus-send` to send the malicious `.deb` file to aptd:

```bash
$ dbus-send --system --type="method_call" --print-reply --dest=org.debian.apt /org/debian/apt org.debian.apt.InstallFile string:`realpath test.deb` boolean:true
method return time=1602245339.731762 sender=:1.287 -> destination=:1.288 serial=8 reply_serial=2
   string "/org/debian/apt/transaction/90f29de930854568964af1918f6ca5eb"
$ dbus-send --system --type="method_call" --print-reply --dest=org.debian.apt /org/debian/apt/transaction/90f29de930854568964af1918f6ca5eb org.debian.apt.transaction.Run
```

Note that you need to use the "transaction id" returned by the first `dbus-send` in the second `dbus-send` command.

#### Impact

This issue may lead to local denial of service.

#### Resources

I have attached `createdeb.c`, which can be used to generate the malicious `.deb` file.

### Issue 3: aptd file descriptor leak (GHSL-2020-170)

There is a file descriptor leak in `debfile_new` at [arfile.cc, line 588](https://git.launchpad.net/ubuntu/+source/python-apt/tree/python/arfile.cc?h=applied/ubuntu/focal-updates&id=0f7cc93acdb51d943114f1cd79002288c4ca4d24#n588):

```c
static PyObject *debfile_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
{
    PyDebFileObject *self = (PyDebFileObject*)ararchive_new(type, args, kwds);
    if (self == NULL)
        return NULL;

    // DebFile
    self->control = debfile_get_tar(self, "control.tar");
    if (self->control == NULL)
        return NULL; <===== self is not freed, so a file descriptor is leaked
```

If the `.deb` file is invalid, then `debfile_new()` returns `NULL`, forgetting to free `self`. This means that the file descriptor for the `.deb` file is not closed. An attacker could use this to exhaust the system's file descriptors, causing a local denial of service.

To run the proof-of-concept, first use the attached source file named "createdeb.c" to generate the malicious `.deb` file:

```bash
gcc createdeb.c -o createdeb
./createdeb leakfd test.deb
```

Now use `dbus-send` to send the malicious `.deb` file to aptd:

```bash
$ dbus-send --system --type="method_call" --print-reply --dest=org.debian.apt /org/debian/apt org.debian.apt.InstallFile string:`realpath test.deb` boolean:true
method return time=1602245339.731762 sender=:1.287 -> destination=:1.288 serial=8 reply_serial=2
   string "/org/debian/apt/transaction/90f29de930854568964af1918f6ca5eb"
$ dbus-send --system --type="method_call" --print-reply --dest=org.debian.apt /org/debian/apt/transaction/90f29de930854568964af1918f6ca5eb org.debian.apt.transaction.Run
```

Note that you need to use the "transaction id" returned by the first `dbus-send` in the second `dbus-send` command. Every time you run the PoC, aptd will open another file descriptor to the `.deb` file, which you can observe by running `lsof -p <pid of aptd>`.

#### Impact

This issue may lead to local denial of service.

#### Resources

I have attached `createdeb.c`, which can be used to generate the malicious `.deb` file.

## Credit

These issues were discovered and reported by GHSL team member [@kevinbackhouse (Kevin Backhouse)](https://github.com/kevinbackhouse).

## Contact

You can contact the GHSL team at `<email address hidden>`, please include a reference to `GHSL-2020-168`, `GHSL-2020-169`, or `GHSL-2020-170` in any communication regarding these issues.

## Disclosure Policy

This report is subject to our [coordinated disclosure policy](https://securitylab.github.com/disclosures#policy).

Revision history for this message
kev (kbackhouse2000) wrote :
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Hello Kevin, it's good to hear from you again. Thanks for the excellent report and beautiful reproducer.

Julian, is this something you can look at?

Thanks

Changed in apt (Ubuntu):
status: New → Confirmed
Revision history for this message
Julian Andres Klode (juliank) wrote :

I don't understand the focus on aptd here given that none of the bugs are in there, and I'll have to see if I can come up with a reproducer to integrate with the tests, and see if it's all fixable. This also affects package kit and apt itself, likely.

I don't care all that much about denial of services, there are likely easier approaches than using these issues.

Also, shouldn't they only be exploitable as root anyway? If not, we should really be worrying why we read deb files in the root daemon without having done policy kit checking.

Revision history for this message
kev (kbackhouse2000) wrote :

Hi Julian,

I am sorry if reported this bug to the wrong package. I followed the "bug reports" link from this page: https://packages.ubuntu.com/focal/libapt-pkg-dev

These bugs do not require any privileges to trigger. As you say, I think part of the problem is that polkit checking is done too late. Although the main problem is, of course, the bugs in the C code.

Thanks,

Kev

Revision history for this message
Julian Andres Klode (juliank) wrote :

Don't worry, it's in the right spot, I just thought it's an aptdaemon bug from the messaging, but then it's 3 (well 4) bugs spread all over apt, python-apt, and (policykit) aptdaemon.

Practically speaking, the main problem is the late policykit check, not the bugs in the C code, because once you passed that, you are in the trusted zone anyway. The package scripts run as root a few moments later anyway, and that gives me much better opportunities to do harm. Or you install setuid binaries.

In summary, the input to those daemons (and apt binaries) that run as root must be trusted. Now neither has (had for PK) appropriate checks at the right spot, so well, that's bad. I wonder what QApt does.

Now, aptdaemon isn't used much anymore past 16.04 - only for non-security updates, so the impact of DoS-ing aptdaemon is not the most critical out there, which is good. The rest installs via PackageKit or directly using apt (security updates). And I think aptdaemon does not acquire locks at the point where those issues happen, so security updates would still apply fine.

There is software where I think this is more critical, e.g. archive management like Launchpad and dak uses it to analyse packages, and you can then crash certain queues or hang them. Now Launchpad has some protection by running them separately, but I'm not sure how well it deals with those infinite loops - if one queue "hangs". So basically, you can DoS whatever archive(s) you can upload too.

Revision history for this message
Julian Andres Klode (juliank) wrote :

#1 and #2 only require fixes in apt:

So #2. Is it really infinite, isn't it basically too big? Similar to when you start reading the file, but the file is truncated.

Now, apparently we do require that we know the size of the arfile (which is stored in Left), so what we should do I guess is

if (Memb->Size > Left) {
    delete Memb;
    return _error->Error(_("Invalid archive member header"))
}

which fixes the issue and also detects truncated files. Well, I guess the message could also say the archive is truncated, but everything else uses this message.

Now #1 we know that Memb->Size is as correct as it will get, so the step here seems to be to add

if (Len > Memb->Size) {
    delete Memb;
    return _error->Error(_("Invalid archive member header"))
}

This ensures that the length we parse for the long name is shorter than the member, which is correct.

#3 needs wrapping object in a smart pointer so the fd is relased. This also needs similar changes in ararchive_new, and possibly a whole bunch of other code that opens files on its own. Further investigation is necessary.

The good thing is that we should be able to get unit tests for all of those. For FDs we count open fds before and after an erronous call, and #1#2 we can check that the malicious debs fail with an error :)

Revision history for this message
Julian Andres Klode (juliank) wrote :

I'm now also looking into where aptd opens those files in the first place, and how we can move the PolicyKit check before that, as we really don't want untrusted users to be able to parse/decompress random files in a root process, which happens if it's reading the deb.

Changed in apt (Ubuntu):
status: Confirmed → Triaged
Changed in python-apt (Ubuntu):
status: New → Triaged
Revision history for this message
Julian Andres Klode (juliank) wrote :

Attached patch for the first two issues, the ones in apt. I embedded the provided test creator code (reformatted), I assume it's fine distributing this as GPL-2+ in apt?

The test case shows that the created debs are properly rejected.

This should apply to apt 1.3 and later, older versions (e.g. 1.2 in xenial) need an adjustment for the old buildsystem - replacing the CMakeLists bit with a makefile one (and I vaguely recall helper path lookup worked differently there, need to test)

Please give it a try! Four/six eyes see more than 2.

Revision history for this message
kev (kbackhouse2000) wrote :

Patch for issues 1 and 2 looks good. Thanks!

Revision history for this message
Julian Andres Klode (juliank) wrote :

### Issue 3: aptd file descriptor leak (GHSL-2020-170)

I also found out that if the function returns successfully, the runtime won't immediately deallocate the object once it's reference count reaches zero, so e.g.

def f():
    apt_inst.DebFile("../apt_1.9.5_amd64.deb")

f()

will cause an extra fd to be used, until the cyclic garbage collector ran. I think this is a problem I introduced years ago when I made them subclassable because that somehow required adding GC support or something - I don't remember.

In any case, this means, that these need to become context managers or at least gain a close() method so that they can be closed when no longer needed.

arfile_new has the same issue FWIW, if there's an error somewhere and the file was opened, it leaks it, as does tagfile_new; and both of them also have memory leaks as they never free those objects in these error cases.

Revision history for this message
Julian Andres Klode (juliank) wrote :

Attached is a patch for the error cases in debfile_new (and ArArchive and TagFile). It works by decreasing the reference count of the object on error paths, and clearing the cycles, so that the object will be collected and the FD released once the function returns.

A test case will be added shortly, that will do os.listdir(/proc/self/fd) before and after calls to ensure that the number of file descriptors is the same.

Because the reason it needed a GC run before was: It turns out I do have cycles in both DebFile and TagFile:

DebFile contains references to data.tar and control.tar members, which in point hold references to the DebFile, so as to make sure that the file stays around while the data needs it.

TagFile links to a TagSection which links back to the TagFile, as the data is actually stored in the tagfile buffer. Oh dear.

I suppose I could fix them both correctly by removing the cycle, e.g. abstracting the File to a FileCommon that both File and Section/member reference, then existing code relying on reference counts will start behaving correctly.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Hello Julian, the file descriptor leak patch has a section that I'm not sure about:

 static PyObject *debfile_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
 {
- PyDebFileObject *self = (PyDebFileObject*)ararchive_new(type, args, kwds);
+ PyApt_UniqueObject<PyDebFileObject> self((PyDebFileObject*)ararchive_new(type, args, kwds));
     if (self == NULL)
         return NULL;

     // DebFile
- self->control = debfile_get_tar(self, "control.tar");
+ self->control = debfile_get_tar(self.get(), "control.tar");
     if (self->control == NULL)
         return NULL;

- self->data = debfile_get_tar(self, "data.tar");
+ self->data = debfile_get_tar(self.get(), "data.tar");
     if (self->data == NULL)
         return NULL;

@@ -603,7 +603,7 @@ static PyObject *debfile_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
     self->Fd.Read(value, member->Size, true);
     self->debian_binary = PyBytes_FromStringAndSize(value, member->Size);
     delete[] value;
- return self;
+ return self.release();
 }

What happens with those return NULL cases if the data.tar or control.tar entries don't exist? Is that a new leak? I expected a self.release() before those cases.

(Or, alternatively, I don't understand the 'return self.release()' idiom.)

There's also a minor typo "file descritor" in the header. Do what you wish with this.

Thanks

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Cleaning up the integer overflows and filedescriptor leaks feels like a good idea; however I'm inclined to say there's one CVE (or perhaps one per software package, if it's truly scattered around correctly) for misplaced polkit checks -- does that sound correct?

Thanks

Revision history for this message
Julian Andres Klode (juliank) wrote :

We certainly want a CVE for moving the root check earlier I suppose, if that's doable with the API - I've not looked at how that all interacts in practice.

I think we need one CVE for each of these things? The code was not meant for untrusted input, but archive tools like launchpad use it for such (albeit in one process per PPA or so, so you can like only DoS a PPA you have write access to).

Revision history for this message
Julian Andres Klode (juliank) wrote :

> What happens with those return NULL cases if the data.tar or control.tar entries don't exist? Is that a new leak? I expected a self.release() before those cases.

OK, so release() releases ownership from the smart pointer to the caller (by setting the internal pointer to NULL and returning it).

Just returning NULL without calling release means the smart pointer object will decrement the reference count and hence deallocate it.

See https://en.cppreference.com/w/cpp/memory/unique_ptr/release for more information about the origin of the idiom.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Thanks for the descriptions; I always assumed there was a lot more magic to unique_ptr. I hadn't expected a dozen-line implementation.

This one's a little complicated:

CVE-2020-27349 (aptdaemon, LP: #1899193) -- policykit checks are too late
CVE-2020-27350 (apt, LP: #1899193) -- apt-pkg/contrib/arfile.cc missing comparisons GHSL-2020-168 GHSL-2020-169
CVE-2020-27351 (python-apt, LP: #1899193) -- python/arfile.cc, python/tag.cc, python/tarfile.cc -- various memory and file descriptor leaks GHSL-2020-170

I'm not 100% sure on lumping together memory leaks (missing free) and file descriptor leaks (missing close) but as they are both missing release of resource, and the same patch addresses both, I don't see a benefit to another CVE in this case.

Thanks

Revision history for this message
Julian Andres Klode (juliank) wrote :

I still wonder if we also should try to fix aptdaemon to explictly close the files it opens, as we can't rely on Python doing that automatically due to the reference cycles in DebFile, and if that needs a CVE as well - I have no idea if it's practically exploitable.

You need to give it a deb that's valid enough to open, aka has data.tar.xz and control.tar.xz and debian-binary members but then is being rejected by aptdaemon itself after the object is created (e.g. control.tar.xz contains nonsense).

Arguably if we fix the PolicyKit interaction, that's enough to go on the aptdaemon side.

Revision history for this message
Julian Andres Klode (juliank) wrote :

Attached patch addresses the reference loop in apt_inst.DebFile, ensuring that no longer referencing the object will release it immediately, as opposed to when the cycle GC runs.

Subject: [PATCH] apt_inst.DebFile: Avoid reference cycle with control,data
 members

apt_inst.DebFile provides two members `data` and `control` for
easy access to those tarballs. Each of those members stores a
reference to the DebFile as its owner:

           v-----------------\
        control ----\ |
                     -> deb -|
        data ----/ |
           ^-----------------/

This means that whenever a DebFile is successfully constructed,
and no longer needed, it won't be collected until the GC runs,
which is bad, as the DebFile holds an open FileFd.

Introduce a __FileFd wrapper that holds the FileFd and becomes
the owner of both control and data, and replaces the direct use
of the FileFd in ArArchive/DebFile:

          v-----------------------------\
        control ----\ \
                     -> __FileFd <- deb -|
        data ----/ /
          ^-----------------------------/

This avoids the reference cycle, ensuring the memory and file
descriptor are released by the reference counter as soon as
the reference count drops to 0.

A future version should move `apt_inst.__FileFd` to `apt_pkg.FileFd`
and expose all the methods, such that people can make use of FileFd's
extensive compression support.

We have a similar cycle in TagFile that we have yet to address,
the problem there is arguably more frustrating, as the buffer
I believe is stored inside the TagFile, and that's really shared
between the TagSection objects.

This is related to LP: #1899193 and CVE-2020-27351, but an additional
hardening measure - the fix for those bugs was for more direct leaks.

Revision history for this message
Julian Andres Klode (juliank) wrote :

Here is the patch for aptdaemon, just add it to the debian/patches, works back to xenial

Revision history for this message
Julian Andres Klode (juliank) wrote :

python-apt debdiff for focal.

Revision history for this message
Julian Andres Klode (juliank) wrote :

python-apt bionic diff

Revision history for this message
Julian Andres Klode (juliank) wrote :

python-apt xenial debdiff

Revision history for this message
Julian Andres Klode (juliank) wrote :

python-apt groovy debdiff

Revision history for this message
Julian Andres Klode (juliank) wrote :

Also subscribing other upstream APT maintainer for visibility.

Revision history for this message
Julian Andres Klode (juliank) wrote :
Revision history for this message
Julian Andres Klode (juliank) wrote :
Revision history for this message
Julian Andres Klode (juliank) wrote :
Revision history for this message
Julian Andres Klode (juliank) wrote :
Revision history for this message
Julian Andres Klode (juliank) wrote :

Release dates:

2020-12-08:
- CVE-2020-27349 (aptdaemon, LP: #1899193) -- policykit checks are too late

2020-12-09:
- CVE-2020-27350 (apt, LP: #1899193)
- CVE-2020-27351 (python-apt, LP: #1899193)

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package aptdaemon - 1.1.1+bzr982-0ubuntu34.1

---------------
aptdaemon (1.1.1+bzr982-0ubuntu34.1) groovy-security; urgency=medium

  * SECURITY UPDATE: info disclosure via transaction properties
    (LP: #1899513)
    - debian/patches/CVE-2020-16128.patch: drop privileges when doing file
      checks in aptdaemon/core.py, aptdaemon/worker/aptworker.py,
      aptdaemon/utils.py.
    - CVE-2020-16128
  * SECURITY UPDATE: policykit checks are too late (LP: #1899193)
    - debian/patches/CVE-2020-27349.patch: check PolicyKit before
      simulating local install in aptdaemon/core.py.
    - CVE-2020-27349

 -- Marc Deslauriers <email address hidden> Tue, 01 Dec 2020 09:23:26 -0500

Changed in aptdaemon (Ubuntu):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package aptdaemon - 1.1.1+bzr982-0ubuntu32.3

---------------
aptdaemon (1.1.1+bzr982-0ubuntu32.3) focal-security; urgency=medium

  * SECURITY UPDATE: info disclosure via transaction properties
    (LP: #1899513)
    - debian/patches/CVE-2020-16128.patch: drop privileges when doing file
      checks in aptdaemon/core.py, aptdaemon/worker/aptworker.py,
      aptdaemon/utils.py.
    - CVE-2020-16128
  * SECURITY UPDATE: policykit checks are too late (LP: #1899193)
    - debian/patches/CVE-2020-27349.patch: check PolicyKit before
      simulating local install in aptdaemon/core.py.
    - CVE-2020-27349

 -- Marc Deslauriers <email address hidden> Wed, 02 Dec 2020 07:42:52 -0500

Changed in aptdaemon (Ubuntu):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package aptdaemon - 1.1.1+bzr982-0ubuntu19.5

---------------
aptdaemon (1.1.1+bzr982-0ubuntu19.5) bionic-security; urgency=medium

  * SECURITY UPDATE: info disclosure via transaction properties
    (LP: #1899513)
    - debian/patches/CVE-2020-16128.patch: drop privileges when doing file
      checks in aptdaemon/core.py, aptdaemon/worker/aptworker.py,
      aptdaemon/utils.py.
    - CVE-2020-16128
  * SECURITY UPDATE: policykit checks are too late (LP: #1899193)
    - debian/patches/CVE-2020-27349.patch: check PolicyKit before
      simulating local install in aptdaemon/core.py.
    - CVE-2020-27349

 -- Marc Deslauriers <email address hidden> Wed, 02 Dec 2020 07:43:55 -0500

Changed in aptdaemon (Ubuntu):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apt - 2.1.10ubuntu0.1

---------------
apt (2.1.10ubuntu0.1) groovy-security; urgency=high

  * SECURITY UPDATE: Integer overflow in parsing (LP: #1899193)
    - apt-pkg/contrib/arfile.cc: add extra checks.
    - apt-pkg/contrib/tarfile.cc: limit tar item sizes to 128 GiB
    - apt-pkg/deb/debfile.cc: limit control file sizes to 64 MiB
    - test/*: add tests.
    - CVE-2020-27350
  * Additional hardening:
    - apt-pkg/contrib/tarfile.cc: Limit size of long names and links to 1 MiB
  * .gitlab-ci.yml: Test on groovy, not unstable

 -- Julian Andres Klode <email address hidden> Mon, 07 Dec 2020 12:02:40 +0100

Changed in apt (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apt - 2.0.2ubuntu0.2

---------------
apt (2.0.2ubuntu0.2) focal-security; urgency=high

  * SECURITY UPDATE: Integer overflow in parsing (LP: #1899193)
    - apt-pkg/contrib/arfile.cc: add extra checks.
    - apt-pkg/contrib/tarfile.cc: limit tar item sizes to 128 GiB
    - apt-pkg/deb/debfile.cc: limit control file sizes to 64 MiB
    - test/*: add tests.
    - CVE-2020-27350
  * Additional hardening:
    - apt-pkg/contrib/tarfile.cc: Limit size of long names and links to 1 MiB
  * .gitlab-ci.yml: Test on focal, not unstable

 -- Julian Andres Klode <email address hidden> Mon, 07 Dec 2020 12:08:43 +0100

Changed in apt (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apt - 1.6.12ubuntu0.2

---------------
apt (1.6.12ubuntu0.2) bionic-security; urgency=high

  * SECURITY UPDATE: Integer overflow in parsing (LP: #1899193)
    - apt-pkg/contrib/arfile.cc: add extra checks.
    - apt-pkg/contrib/tarfile.cc: limit tar item sizes to 128 GiB
    - apt-pkg/deb/debfile.cc: limit control file sizes to 64 MiB
    - test/*: add tests.
    - CVE-2020-27350
  * Additional hardening:
    - apt-pkg/contrib/tarfile.cc: Limit size of long names and links to 1 MiB

 -- Julian Andres Klode <email address hidden> Mon, 07 Dec 2020 12:13:36 +0100

Changed in apt (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package python-apt - 2.1.3ubuntu1.1

---------------
python-apt (2.1.3ubuntu1.1) groovy-security; urgency=high

  * SECURITY UPDATE: various memory and file descriptor leaks (LP: #1899193)
    - python/arfile.cc, python/generic.h, python/tag.cc, python/tarfile.cc:
      fix file descriptor and memory leaks
    - python/apt_instmodule.cc, python/apt_instmodule.h, python/arfile.h:
      Avoid reference cycle with control,data members in apt_inst.DebFile
      objects
    - tests/test_cve_2020_27351.py: Test cases for DebFile (others not easily
      testable)
    - CVE-2020-27351
  * .gitlab-ci.yml: Fix mypy and Ubuntu version for CI
  * data/templates: Update mirror lists

 -- Julian Andres Klode <email address hidden> Tue, 01 Dec 2020 20:25:56 +0100

Changed in python-apt (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package python-apt - 2.0.0ubuntu0.20.04.2

---------------
python-apt (2.0.0ubuntu0.20.04.2) focal-security; urgency=high

  * SECURITY UPDATE: various memory and file descriptor leaks (LP: #1899193)
    - python/arfile.cc, python/generic.h, python/tag.cc, python/tarfile.cc:
      fix file descriptor and memory leaks
    - python/apt_instmodule.cc, python/apt_instmodule.h, python/arfile.h:
      Avoid reference cycle with control,data members in apt_inst.DebFile
      objects
    - tests/test_cve_2020_27351.py: Test cases for DebFile (others not easily
      testable)
    - CVE-2020-27351
  * .gitlab-ci.yml: Fix mypy version for CI
  * data/templates: Update mirror lists

 -- Julian Andres Klode <email address hidden> Tue, 01 Dec 2020 17:15:01 +0100

Changed in python-apt (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package python-apt - 1.6.5ubuntu0.4

---------------
python-apt (1.6.5ubuntu0.4) bionic-security; urgency=high

  * SECURITY UPDATE: various memory and file descriptor leaks (LP: #1899193)
    - python/arfile.cc, python/generic.h, python/tag.cc, python/tarfile.cc:
      fix file descriptor and memory leaks
    - python/apt_instmodule.cc, python/apt_instmodule.h, python/arfile.h:
      Avoid reference cycle with control,data members in apt_inst.DebFile
      objects
    - tests/test_cve_2020_27351.py: Test cases for DebFile (others not easily
      testable)
    - CVE-2020-27351
  * data/templates: Update mirror lists

 -- Julian Andres Klode <email address hidden> Tue, 01 Dec 2020 20:16:11 +0100

Changed in python-apt (Ubuntu):
status: Triaged → Fix Released
information type: Private Security → Public Security
Revision history for this message
shaun (shaggy183) wrote :

its laging and not adding my pakadges or exepting my passwords

To post a comment you must log in.