Ubuntu

Confusion regarding the affected binaries in USN links

Asked by Ashwitha V on 2022-03-21

Hi, I am contacting you as I came across with a confusion while going through the Ubuntu Security Notice link. Here is an example of the issue,

https://ubuntu.com/security/notices/USN-5133-1 lists:
Ubuntu 18.04
    icu-devtools - 60.2-3ubuntu3.2
    libicu60 - 60.2-3ubuntu3.2
    libiculx60 - 60.2-3ubuntu3.2
Also, when we have a look at https://packages.ubuntu.com/search?suite=all&section=all&arch=any&searchon=sourcenames&keywords=icu, the binary packages of source icu are:
bionic (libs): 60.2-3ubuntu3.2 [security]
Binary packages: icu-devtools, icu-doc, libicu-dev, libicu60, libiculx60

Here, is the vulnerability affected for all the binary packages of icu listed in the above link or is it related only to the binaries which are mentioned in USN page? If it is related to all the binaries of icu, why only 3 packages are mentioned exclusively in the above USN link. Such similar concerns are there in almost all USNs, Ex: USN-5333-2, USN-5325-1. The confusion basically arrives as the Ubuntu vendor oval adds all the binaries in the definition although the advisory lists only some particular binaries as vulnerable. Can you please help me understand this issue faced in USN advisories.

Question information

Language:: English Edit question

Status:: Solved

For:: Ubuntu Edit question

Assignee:: No assignee Edit question

Solved by:: Manfred Hampl

Solved:: 2022-03-23

Last query:: 2022-03-23

Last reply:: 2022-03-22

Link existing bug

Revision history for this message

Manfred Hampl (m-hampl) said on 2022-03-21:

The complete list of packages from the icu source is here: https://launchpad.net/ubuntu/+source/icu

Built packages
icu-devtools Development utilities for International Components for Unicode
icu-devtools-dbgsym debug symbols for icu-devtools
icu-doc API documentation for ICU classes and functions
libicu-dev Development files for International Components for Unicode
libicu60 International Components for Unicode
libicu60-dbgsym debug symbols for libicu60
libiculx60 International Components for Unicode
libiculx60-dbgsym debug symbols for libiculx60

The vulnerability is "ICU could be made to crash if it received specially crafted input."

Take the "icu-doc API documentation for ICU classes and functions" package. It contains documentations files only and no binary executable file. There is nothing in that package that could "run" by itself and it does not accept input. So it cannot be made to "crash" by specifically crafted data.
Similar with the -dbgsym packages. They only contain cross references from the instructions in the binaries to the original source code and do not contain executable code.

So these packages (and probably also libicu-dev) are not directly affected by the vulnerability. Of course it is strongly recommended to update these packages whenever the other packages they refer to are changed. If you have old versions of these packages on your system and new ones of the packages that really are affected, then this is a sign that your update processes are somewhat broken.

Revision history for this message

Ashwitha V (ashwitha-v) said on 2022-03-21:

Does that mean any security content we create should check for all binaries that can be compiled with a particular source? If yes, why only specific binaries are mentioned in USN links and not only the source or all the binaries of this source?

Revision history for this message

Manfred Hampl (m-hampl) said on 2022-03-21:

I guess it is more a strategic decision whether you check only for the vulnerable binaries or also for other non-executable packages built from a vulnerable source. I don't see much benefit from one option over the other.

Revision history for this message

Ashwitha V (ashwitha-v) said on 2022-03-22:

Actually need still more clarification regarding this issue. For example, https://ubuntu.com/security/notices/USN-3891-1 mentions libsystemd0 and systemd. And https://ubuntu.com/security/notices/USN-3855-1 mentions only systemd. So does this mean, for USN-3891-1, we need to update both libsystemd0 and systemd but for USN-3855-1, upgrading only systemd package will fix the vulnerabilities? Actually, https://packages.ubuntu.com/search?suite=all&section=all&arch=any&searchon=sourcenames&keywords=systemd mentions a lot of other binaries for the source systemd. Yes, we understand that you previously mentioned that upgrading only few binaries might break the package dependency. But here, we are concerned mainly on resolving the security issue and if a binary is having dependency on some other binary it would automatically upgrade the other one. So, is it sufficient if we upgrade the mentioned binaries in USN links for fixing the security issues by ignoring other binaries?