The meaning of a package being "insecure"

Development
1

I’m not sure how “insecure” applies in that case. For example there is no expectation to mark bash as insecure because it is unsafe for untrusted input :stuck_out_tongue: But for this I mean “insecure because upstream updates are not available” not any fundamental lack of security in the package itself.

2

I’m not sure how “insecure” applies in that case. For example there is no expectation to mark bash as insecure because it is unsafe for untrusted input :stuck_out_tongue: But for this I mean “insecure because upstream updates are not available” not any fundamental lack of security in the package itself.

Would you consider the Bash version with (undocumented) Shellshock insecure? Ghostscript has -dSAFER mode that tries to make it a safe «only access the input and the output files» program. This seems to even be the default mode now. It has seen so many holes, that even a new re-designed implementation (which they seem to have since a recent version 9.50) would need quite a bit of time to be trusted as actually safe.

3

| 7c6f434c Great contributor
September 26 |

  • | - |

Would you consider the Bash version with (undocumented) Shellshock insecure?

This is getting really off topic. Feel free to start another thread and tag me. I’d be happy to discuss what marking a package insecure should mean.

4

I split this off into its own topic.

5

Thanks, sorry if i missed it the first time, I’m still new to discourse.

You strike on a a good point “insecure” can mean different things. Right
now in nixpkgs a package is considered if it has “knownVulnerabilities
https://nixos.org/manual/nixpkgs/stable/#chap-packageconfig”. This
seems like the best option to me, however there is some discretion here.
(what if a vulnerability is considered by the maintainer to be a non-issue?)

I can think of two main use cases for insecure packages:

  1. Informing users that this package has known vulnerabilities.
  2. Informing users that this package is expected to have vulnerabilities.

I think your ghostscript falls into the 2 example. The software is of a
questionable security stance but as far as the maintainers know there
are no current vulnerabilities. However due to the likely presence of
unknown vulnerabilities it isn’t recommended to run on untrusted inputs
(without some form of sandboxing).

Shellshock falls into the other example. The vulnerability was known
(and there was a patch available). In this case I think the best action
is to package the new version (or apply the patch). However if that
can’t be done for some reason then marking insecure makes sense.

I think the last scenario is there are known vulnerabilities, but no
patch available. For example this software may be unmaintained upstream.
In that case I think marking the package insecure is an obvious choice.

I see broken and insecure derivations very similarly. Maintained
packages should not have either (at least for long). In that case (1) I
think the current setup is ideal.

Another major problem with 2 is now we are implying that the maintainer
is a good judge of the security of a package. If we mark ghostscript for
example then there becomes an implication that the packages we haven’t
marked are secure. I don’t think we should get into that business. (If
we do we can maybe add a “dangerous” flag)

···

On 9/26/20 10:24 AM, Ryan Mulligan via NixOS Discourse wrote:

[ryantm] ryantm https://discourse.nixos.org/u/ryantm Great contributor
September 26

I split this off into its own topic.

6
7

I think the last scenario is there are known vulnerabilities, but no
patch available. For example this software may be unmaintained upstream.
In that case I think marking the package insecure is an obvious choice.

sway has memory corruption crashes under relatively reasonable
use conditions. For months. Across upstream releases. I am not sure if
they are assigned CVEs, but, I mean, known memory corruption. Does this
count?

I think some image libraries with CVEs for everything had some fuzzed
crashes triaged/debugged for many weeks (with a release in-between).

I see broken and insecure derivations very similarly. Maintained
packages should not have either (at least for long). In that case (1) I
think the current setup is ideal.

I would say, known upstream-blessed patches should be applied. We
actually have no clear policy on whether to include all upstream
acknowledged CVEs into «knownVulnerabilities» even… I guess all the
patched ones? I know that in Nixpkgs it is a lot of work to get a
non-binary classification working (including but not limited to,
recognising the three-side nature of known-good/known-bad/unclear).
This is why I am opposed to any removal policy based on the assumption
that «insecure» marking is applied according to a consistent policy,
at least until such a policy is formally approved as an RFC and then
consistently used for a year.

3 Likes
8

I don’t feel comfortable answering this either way. I think I would lean towards “insecure”. But I don’t know how I would encode that in a formal rule. I think in general image libraries are expected to work with untrusted images so that would be my logic. Of course this also depends on what the library claims. Agreed