local denial of service due to parsing bugs in arfile.cc
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apt (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
aptdaemon (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
python-apt (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
# GitHub Security Lab (GHSL) Vulnerability Report: `GHSL-2020-168`, `GHSL-2020-169`, `GHSL-2020-170`
The [GitHub Security Lab](https:/
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:/
## Product
aptd
## Tested Version
* libapt-pkg-dev: version 2.0.2ubuntu0.1
* python-apt: 2.0.0ubuntu0.
* 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:/
```c
Memb->Size -= Len;
```
Due to the integer overflow, the value of `Memb->Size` is `0xFFFFFFFFFFFF
```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 return time=1602245339
string "/org/debian/
$ dbus-send --system --type=
```
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:/
```c
StrToNum(
```
The bug is due to the use of `strtoul` in [StrToNum](https:/
```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[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(
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 return time=1602245339
string "/org/debian/
$ dbus-send --system --type=
```
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:/
```c
static PyObject *debfile_
{
PyDebFileObject *self = (PyDebFileObjec
if (self == NULL)
return NULL;
// DebFile
self->control = debfile_
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 return time=1602245339
string "/org/debian/
$ dbus-send --system --type=
```
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:/
## 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:/
CVE References
Changed in apt (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in python-apt (Ubuntu): | |
status: | New → Triaged |
information type: | Private Security → Public Security |
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