vulnerability in libcue affects tracker-extract (GHSL-2023-197)

[kev]

Hi,

I found a bug in libcue, which is one of tracker-extract's dependencies. I want to make you aware of it because it can potentially lead to code execution in tracker-extract. If you download the attached file on Ubuntu 23.04 then (in my testing at least) it will pop a calculator. That's because tracker-extract automatically runs on new files in the ~/Downloads directory and the '.cue' filename extension triggers the libcue code path.

I have separately reported the vulnerability to the maintainer of the libcue library (https://github.com/lipnitsk/libcue). I'll also add the full details as a comment to this report.

Kind regards,

Kev

Kevin Backhouse
GitHub Security Lab

[kev (kbackhouse2000)]

# GitHub Security Lab (GHSL) Vulnerability Report, libcue: `GHSL-2023-197`

The [GitHub Security Lab](https://securitylab.github.com) team has identified a potential security vulnerability in [libcue](https://github.com/lipnitsk/libcue).

We are committed to working with you to help resolve this issue. In this report you will find everything you need to effectively coordinate a resolution of this issue 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-2023-197` as a reference).

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

## Summary

libcue is a library for parsing [CUE sheet](https://en.wikipedia.org/wiki/Cue_sheet_%28computing%29) files. A malicious file can trigger an out-of-bounds array access in the `track_set_index` function.

## Project

libcue

## Tested Version

[2.2.1](https://github.com/lipnitsk/libcue/releases/tag/v2.2.1)

## Details

### Out of bounds array access in track_set_index (`GHSL-2023-197`)

The function [`track_set_index`](https://github.com/lipnitsk/libcue/blob/1b0f3917b8f908c81bb646ce42f29cf7c86443a1/cd.c#L340-L348) does not check that `i >= 0`:

```c
void track_set_index(Track *track, int i, long ind)
{
 if (i > MAXINDEX) {
  fprintf(stderr, "too many indexes\n");
                return;
        }

 track->index[i] = ind;
}
```

If `i` is negative, then this code can write to an address outside the bounds of the array.

The value of `i` is parsed using [`atoi`](https://en.cppreference.com/w/c/string/byte/atoi) in [`cue_scanner.l`](https://github.com/lipnitsk/libcue/blob/1b0f3917b8f908c81bb646ce42f29cf7c86443a1/cue_scanner.l#L132):

```c
[[:digit:]]+ { yylval.ival = atoi(yytext); return NUMBER; }
```

`atoi` does not check for integer overflow, so it is easy to get it produce a negative number.

This is an example CUE file which triggers the bug:

```
FILE pwned.mp3 MP3
TRACK 000 AUDIO
INDEX 4294567296 0
```

The index `4294567296` is converted to `-400000` by `atoi`.

#### Impact

This issue may lead to code execution when libcue is used to parse a malicious file.

#### Remediation

Suggested fix:

```
diff --git a/cd.c b/cd.c
index cf77a18..4bbea19 100644
--- a/cd.c
+++ b/cd.c
@@ -339,7 +339,7 @@ track_get_rem(const Track* track)

 void track_set_index(Track *track, int i, long ind)
 {
- if (i > MAXINDEX) {
+ if (i < 0 || i > MAXINDEX) {
                fprintf(stderr, "too many indexes\n");
                 return;
         }
```

## GitHub Security Advisories

We recommend you create a private [GitHub Security Advisory](https://help.github.com/en/github/managing-security-vulnerabilities/creating-a-security-advisory) for this finding. This also allows you to invite the GHSL team to collaborate and further discuss this finding in private before it is [published](https://help.github.com/en/github/managing-security-vulnerabilities/publishing-a-security-advisory).

## Credit

This issue was discovered and reported by GHSL team member [@kevinbackhouse (Kevin Backhouse)](https://github.com/kevinbackhouse).

## Contact

You can contact the GH...

[Alex Murray (alexmurray)]

Thanks for the heads-up kev - nice find by the way :)

We will plan to release updates for this at the same time as upstream - can you please keep us in the loop on any proposed CRD? Also has a CVE been assigned already?

[Alex Murray (alexmurray)]

I've reassigned this to libcue since once we fix it there in Ubuntu then tracker-extract etc will be fixed as they use the library from this source package.

[kev (kbackhouse2000)]

Hi Alex,

I've emailed the maintainer of libcue, but not heard back yet. The project hasn't been updated since 2018, so I'm not sure if it's still actively maintained. I'll try to contact the maintainer again today.

I've started looking at which other distributions this might affect and discovered that it's probably every distribution that runs GNOME. Do you know if the GNOME developers will have seen this bug report already, or I should I notify them by creating a private issue on https://gitlab.gnome.org/GNOME?

Thanks,

Kev

[Alex Murray (alexmurray)]

Since libcue is not a GNOME project then I am not sure how much engagement you would get there - also I am not sure if many of the GNOME developers are in touch with their downstream distros. Also whilst tracker is one of the more prominent users of libcue, it is not the only one - e.g. in current Ubuntu 23.10:

$ reverse-depends src:libcue
Reverse-Depends
===============
* audacious-plugins [amd64 arm64 armhf ppc64el s390x]
* ffmpegfs [amd64 arm64 armhf ppc64el s390x]
* musepack-tools (for libcue2)
* tracker-extract [amd64 arm64 armhf ppc64el s390x]

but of these, tracker-extract is the only one that is installed by default, so I can understand your focus on this package, but in this case I think it is better to focus on upstream directly still if possible.

Perhaps the other option would be to bring it to the distros list (https://oss-security.openwall.org/wiki/mailing-lists/distros), especially since you already have a patch - but they have a hard 14-day disclosure deadline (ie you must disclose publicly within 14 days of disclosing to the distros list) which may not suit.

Also are Github planning to assign the CVE here?

[kev (kbackhouse2000)]

Hi Alex,

Thanks! The distros list sounds like a good option if I don't hear back from the maintainer of libcue. I'm planning to use the mailing list if don't hear anything by Monday.

Yes, GitHub will assign a CVE for this. I'll let you know the ID as soon as I have it.

Kev

[kev (kbackhouse2000)]

We have assigned CVE-2023-43641 to this vulnerability in libcue. I have not heard back from the maintainer, so I'm going to email the distros list.

[kev (kbackhouse2000)]

The distros list have received my message. We've a disclosure time of 2023-10-09T17:00:00+00:00.

[Marc Deslauriers (mdeslaur)]

This was ultimately fixed in https://ubuntu.com/security/notices/USN-6423-1

Thanks!