lshell component is not maintained and has pending CVEs

[Bruce Jones]

Folks,

As I was looking at the upstream patches, I looked into the status of lshell and noticed there was an existing open issue[0] which referenced
2 CVEs:

  - CVE-2016-6902 - remote authenticated users can break out of a limited shell and execute arbitrary commands.
  - CVE-2016-6903 - lshell 0.9.16 allows remote authenticated users to break out of a limited shell and execute arbitrary commands.

These are related, and there is a potential fix, but issue 150 [3] seems to indicate the patch is not complete. The maintainer has expressed that he not able to do anything about this as of May this year. Additionally lshell is python2 based and would need to be converted to python3.

I went so far as proposing a very simple change to their README.md to fix a bad link and it stalled in their travis tox check.

Sau!

[Bruce Jones (brucej)]

Email from Dean Troyer:
> What alternatives do we have for this functionality?

Alternatives in increasing levels of commitment to lshell:
* replace it
* fork the project and fix the CVEs and continue
* adopt the project and take over maintenance as a stand0-alone project should the existing maintainer be interested in doing so[0]

I am specifically not listing 'do nothing' as active CVEs must be addressed...

dt

[0] OpenStack has done this on occasion when a dependency goes dormant and the maintainer has no interest in continuing and the cost of converting outweighs the perceived cost of maintenance and ownership.

[Ken Young (kenyis)]

On 2018-09-27, 9:02 PM, "Xie, Cindy" <email address hidden> wrote:

    Is LShell and ibsh specific to CentOS or it applicable for other OS? Say for example, can we look for alternatives that Ubuntu or ClearLinux is using for the similar functionality?
    Thanks. - cindy

[Ken Young (kenyis)]

I want to limit the discussion here to the security exposure and the CVEs. Any build or multiOS concerns need to be handled separately and can be discussed openly on the mailing list.

The CVEs in question are:

- CVE-2016-6902: Base Score 9.0 HIGH Vector: (AV:N/AC:L/Au:S/C:C/I:C/A:C)
https://nvd.nist.gov/vuln/detail/CVE-2016-6902

- CVE-2016-6903: Base Score 9.0 HIGH Vector: (AV:N/AC:L/Au:S/C:C/I:C/A:C)
https://nvd.nist.gov/vuln/detail/CVE-2016-6903

Given the base vector score of 9.0 and the access vector is network with low complexity, these CVEs need to be evaluated further.

My understanding is that this software has limited use during config_controller (This needs to be confirmed). It is not running in general and does not sit on an open port on the OAM interface. The open ports on this interface were reviewed as part of the Threat Model and the SAFE review. Given that network access is not provided, these threats do not exists in a running titanium system. The only way to access the shell is on the system itself which means you already have access to the system.

Ken Young Opinion:
1/ This issue is low priority.
2/ Should not drive an immediate fix because of these CVEs

[Bruce Jones (brucej)]

Ken, I think I agree with your analysis - which as you say needs to be confirmed. But I'm not sure I agree with your conclusion.

Regardless of the technical merits, I'm not sure either of our companies would want it known that we are supporting software with known HIGH CVEs. I am very sure my company does not want that.

I think we need to look into what problem this is trying to solve and how we might otherwise solve it. I don't think we can treat that analysis as a low priority issue. I think we should continue to investigate until we know what the scope of the work is. If this turns out to be an easy fix, I'd sleep better at night once we make it. If it turns out to be a major change, we'll need to have to have some hard conversations...

[Ken Young (kenyis)]

Bruce,

This will be a good discussion on Monday. To be clear, I am saying its low because I would much rather invest in findings from static analysis and push the banned c function agenda. This is not a drop your tools and address it problem like Spectre / Meltdown.

Let discuss Monday morning.

/KenY

[Saul Wold (sgw-starlingx)]

Ken,

Thanks for digging deeper into this, I feel we need to be open the the Multi-OS discussion here from the standpoint of can we drop lshell in favor or something else like a cut-down busybox or toybox rather than trying to address a fix, even if we are not doing an immediate fix it would not be an immediate replacement.

From the security standpoint, what functionality (limited as it is) is lshell providing that could be replaced?

I may join call on Monday morning.
Sau!

[Ken Young (kenyis)]

Saul,

My goal here is to have the right conversation with the right audience. If you are concerned about the package is no longer maintained, then this is a great conversation for the nondistro call. If you have multiOS concerns, then please bring it up on the MultiOS forum when it is created.

I have a full agenda on Monday and I want to focus on security and exposures.

Regards,
Ken Y

[Ken Young (kenyis)]

The outcome of the discussion of the VMT this morning concluded that fixing this issue due to the

1/ security concerns was not immediately warranted. The likelihood of an attacker exploiting these exposures is remote.
2/ fact that the package is no longer maintained is more pressing. How uregent this issue needs to be addressed should be discussed on Wednesday morning on the Distro Non-Openstack Sub-project call. Bruce raised a launchpad to make this issue visible:

https://bugs.launchpad.net/starlingx/+bug/1795451

We can discuss the package status openly. We need to keep the CVEs quiet during this process.

[Bruce Jones (brucej)]

Update: Reviews to address this bug are posted and linked in LP 1795451.

[Cindy Xie (xxie1)]

As bug 1795451 has been fixed, we can change this bug as "invalid".

[Cindy Xie (xxie1)]

or maybe "won't fix".

[Ken Young (kenyis)]

Set to "Won't Fix" from a security perspective. Happy to see this was fixed in the non-openstack distro.