Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usage of crate parse_duration, remove_dir_all, time entails security concerns #987

Closed
Pegasust opened this issue Jun 13, 2023 · 4 comments · Fixed by #2193
Closed

Usage of crate parse_duration, remove_dir_all, time entails security concerns #987

Pegasust opened this issue Jun 13, 2023 · 4 comments · Fixed by #2193
Labels
bug Something isn't working

Comments

@Pegasust
Copy link

Describe the bug
The immediate action is to revise the usage of parse_duration crate. The security concern is minimal, but should be considered. The other crates are difficult to address since they are transitive dependencies (tantivy and and tempdir)

Steps to reproduce (if applicable)
Steps to reproduce the behavior:

% ❯ nix run nixpkgs#cargo-audit -- audit
    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
      Loaded 549 security advisories (from /Users/htran/.cargo/advisory-db)
    Updating crates.io index
    Scanning Cargo.lock for vulnerabilities (438 crate dependencies)
Crate:     parse_duration
Version:   2.1.1
Title:     Denial of service through parsing payloads with too big exponent
Date:      2021-03-18
ID:        RUSTSEC-2021-0041
URL:       https://rustsec.org/advisories/RUSTSEC-2021-0041
Severity:  7.5 (high)
Solution:  No fixed upgrade is available!
Dependency tree:
parse_duration 2.1.1
├── nucliadb_core 0.1.0
│   ├── nucliadb_vectors 0.1.0
│   │   ├── vectors_benchmark 0.1.0
│   │   └── nucliadb_node 0.1.0
│   │       └── nucliadb_node_binding 0.7.6
│   ├── nucliadb_texts 0.1.0
│   │   └── nucliadb_node 0.1.0
│   ├── nucliadb_relations 0.1.0
│   │   └── nucliadb_node 0.1.0
│   ├── nucliadb_paragraphs 0.1.0
│   │   └── nucliadb_node 0.1.0
│   ├── nucliadb_node_binding 0.7.6
│   └── nucliadb_node 0.1.0
└── nucliadb_cluster 0.1.0
    └── nucliadb_node 0.1.0

Crate:     remove_dir_all
Version:   0.5.3
Title:     Race Condition Enabling Link Following and Time-of-check Time-of-use (TOCTOU)
Date:      2023-02-24
ID:        RUSTSEC-2023-0018
URL:       https://rustsec.org/advisories/RUSTSEC-2023-0018
Solution:  Upgrade to >=0.8.0
Dependency tree:
remove_dir_all 0.5.3
└── tempdir 0.3.7
    └── nucliadb_node 0.1.0
        └── nucliadb_node_binding 0.7.6

Crate:     time
Version:   0.1.45
Title:     Potential segfault in the time crate
Date:      2020-11-18
ID:        RUSTSEC-2020-0071
URL:       https://rustsec.org/advisories/RUSTSEC-2020-0071
Severity:  6.2 (medium)
Solution:  Upgrade to >=0.2.23
Dependency tree:
time 0.1.45
└── chrono 0.4.24
    └── tantivy 0.17.0
        ├── nucliadb_texts 0.1.0
        │   └── nucliadb_node 0.1.0
        │       └── nucliadb_node_binding 0.7.6
        ├── nucliadb_relations 0.1.0
        │   └── nucliadb_node 0.1.0
        └── nucliadb_paragraphs 0.1.0
            └── nucliadb_node 0.1.0

Crate:     tempdir
Version:   0.3.7
Warning:   unmaintained
Title:     `tempdir` crate has been deprecated; use `tempfile` instead
Date:      2018-02-13
ID:        RUSTSEC-2018-0017
URL:       https://rustsec.org/advisories/RUSTSEC-2018-0017
Dependency tree:
tempdir 0.3.7
└── nucliadb_node 0.1.0
    └── nucliadb_node_binding 0.7.6

Crate:     atty
Version:   0.2.14
Warning:   unsound
Title:     Potential unaligned read
Date:      2021-07-04
ID:        RUSTSEC-2021-0145
URL:       https://rustsec.org/advisories/RUSTSEC-2021-0145
Dependency tree:
atty 0.2.14
├── env_logger 0.9.3
│   └── nucliadb_cluster 0.1.0
│       └── nucliadb_node 0.1.0
│           └── nucliadb_node_binding 0.7.6
├── env_logger 0.7.1
│   └── tracing-log 0.1.3
│       ├── tracing-subscriber 0.3.16
│       │   ├── tracing-opentelemetry 0.17.4
│       │   │   └── nucliadb_node 0.1.0
│       │   ├── sentry-tracing 0.27.0
│       │   │   └── nucliadb_node 0.1.0
│       │   ├── nucliadb_node_binding 0.7.6
│       │   └── nucliadb_node 0.1.0
│       ├── tracing-opentelemetry 0.17.4
│       └── nucliadb_node 0.1.0
└── clap 3.2.23
    └── vectors_benchmark 0.1.0

error: 3 vulnerabilities found!
warning: 2 allowed warnings found

Expected behavior
cargo audit should be clean, consider adding an audit job on CI

Configuration:
Please provide:

Output of pip list | grep nucliadb
No pip configuration necessary, this is only tracked via cargo audit

@Pegasust Pegasust added the bug Something isn't working label Jun 13, 2023
@jotare
Copy link
Contributor

jotare commented Jun 14, 2023

Hi @Pegasust. Thank you for contributing to NucliaDB!

We'll address this issues as soon as possible. Do you want to collaborate resolving them? We'll be really happy to have new contributors :)

@hermeGarcia
Copy link
Contributor

Hi @Pegasust, thanks for taking the time to write this issue!
As you said some of the dependencies are very difficult to address, not only because they are transitive, but also because updating crates like Tantivy may require to reindex old data to the newer index.
Adding cargo-audit to the CI could potentially break a lot of PRs for an error that requires to upgrade Tantivy, which would take because of reindexing.
That said this is something that we will need to address at some point!

@Pegasust
Copy link
Author

Thanks for pointing out my oversight on the need of Tantivy. I would love to collaborate on this as I get my feet wet with nucliadb.
That said, I'm have very little input on what needs to be done to have this resolved.

@jotare
Copy link
Contributor

jotare commented Jun 20, 2023

Hi @Pegasust, this issue it's kind of blocked for the moment as @hermeGarcia said. If you are interested in contributions aside from this issue, feel free to join our discord server and chat with us!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants