Ubuntu-security CVE-2019-18224 web page shows incorrect info about libidn2-0 status

[Srdjan Grubor]

Security page about CVE-2019-18224 (https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-18224.html) is mistakenly marking package libidn2-0 as "DNE" in 18.04 and 19.04 (possibly even for 19.10 and 20.04).

Proper listing should have it as "released" in 18.04 and 19.04 according to this page: https://usn.ubuntu.com/4168-1/

This bug is affecting downstream tooling like Trivy mistakenly marking 18.04 as still vulnerable to this CVE.

[Srdjan Grubor (sgnn7)]

This may also affect this page: https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-12290.html

[Eduardo Barretto (ebarretto)]

Hi Srdjan,

Thanks for taking the time to report this issue and help making Ubuntu better.

The USN you mentioned, applied the fix to the source package libidn2 (https://packages.ubuntu.com/source/bionic/libidn2)
You can see on the mentioned page that this source package generates multiple binary packages, including: idn2 and libidn2-0. So, on the USN page that you mentioned we are referring to those binary packages, but on the CVE page we are only dealing with source package names. So we already have the released in the lines for libidn2.

The lines that you are referring that are marked as DNE, is for the libidn2-0 source package (https://packages.ubuntu.com/source/xenial/libidn2-0), which only exists on Ubuntu Xenial (16.04) and Trusty (14.04), and that's why it is marked as DNE (Do Not Exist) in the CVE page.

So this is just a confusion between source packages and binary packages. Binary packages is what you install on a apt-get install command. Source packages is where we apply the fix, and where the binary packages will be generated from.

Hope I didn't get you more confused on this.
Thanks

[Eduardo Barretto (ebarretto)]

Also, I am not aware of this Trivy tool, but could you give us more information on what you are seeing?

[Srdjan Grubor (sgnn7)]

Hey Eduardo,
This is the Trivy tool: https://github.com/aquasecurity/trivy. It's used to scan containers for CVEs and to reproduce you can install trivy and just run "trivy -quiet ubuntu:18.04" to see the CVE flagged.

I think what is happening is that trivy scans installed packages on the system (returns libidn2-0) and then compares it to the CVE page which in this case shows as "DNE" and thus is flagged as a valid vulnerability. Do you think this sounds correct? If so, I will file the bug in relevant upstream projects.

Srdjan

[Eduardo Barretto (ebarretto)]

Hi Srdjan,

Awesome, thanks! I will give it a try.

Yes, the analysis seems correct to me. So I encourage you to file a bug on Trivy Github and let them verify what's going on. If possible, keep us updated on the outcomes of your bug report.

I appreciate it!
Thanks,
Eduardo

[Teppei Fukuda (knqyf263)]

Hi Srdjan,

I'm a developer of Trivy. In my environment, it works well. Also, Trivy looks at a source package name to detect vulnerabilities in the case of Ubuntu, so this bug should not happen. In this case, the source package name is libidn2 in Ubuntu 18.04, not libidn2-0. But I may overlooked something. Let me know the detail here, please.
https://github.com/aquasecurity/trivy/issues

[Srdjan Grubor (sgnn7)]

Hey Teppei,
Great to hear that!

After deeper looking over my logs and console buffer, I think this was a combination of a user error on my part and a UX problem in Trivy caching.

What I think might have happened:
- I scanned `ubuntu:18.04` tag at some point before the libidn2 fix went in and Trivy showed a vulnerability as "valid" correctly.
- At some point I must have pulled the new `ubuntu:18.04` tag (I'm guessing).
- I went into the container to see what `libidn2-0` version I was running and it returned a version number that I correlated to a fixed version according to USN link.
- Re-running trivy did not update the results nor tell me that the original result will be perma-cached so I posited that Trivy or the data it was pulling was at fault.
- I then went down the rabbit hole of how Trivy pulls fix data that lead me to creating this bug report.

Thanks both for looking into this though - sorry for the extra noise that wasn't needed!

Eduardo, feel free to close this issue as invalid!

Srdjan

[Teppei Fukuda (knqyf263)]

Hi Srdjan,

Thank you for the explanation. I understand your point. Now, the cache sometimes introduces such a problem. We are working on the cache improvement. Until we finish it, use --clear-cache option, please.

Best,
Teppei