Skip to content
New issue

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

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

Already on GitHub? # to your account

[SECURITY] Kobalt pulls from insecure repositories by default #499

Open
JLLeitschuh opened this issue Mar 28, 2019 · 2 comments
Open

[SECURITY] Kobalt pulls from insecure repositories by default #499

JLLeitschuh opened this issue Mar 28, 2019 · 2 comments

Comments

@JLLeitschuh
Copy link

CWE-829: Inclusion of Functionality from Untrusted Control Sphere
CWE-494: Download of Code Without Integrity Check

The source files indicate that this project is resolving dependencies over HTTP instead of HTTPS. Any of these artifacts could have been MITM to maliciously compromise them and infect the build artifacts that were produced. Additionally, if any of these JARs or other dependencies were compromised, any developers using these could continue to be infected past updating to fix this.

This vulnerability has a CVSS v3.0 Base Score of 8.1/10
https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

This isn't just theoretical

POC code has existed since 2014 to maliciously compromise a JAR file inflight.
See:

MITM Attacks Increasingly Common

See:

Source Locations

  • internal val DEFAULT_REPOS = listOf<HostConfig>(
    // "https://maven-central.storage.googleapis.com/",
    HostConfig("http://repo1.maven.org/maven2/", "Maven"),
    HostConfig("https://jcenter.bintray.com/", "JCenter")
    // "http://repository.jetbrains.com/all/", // <-- contains snapshots
    // snapshots
    // "https://oss.sonatype.org/content/repositories/snapshots/"
    // , "https://repository.jboss.org/nexus/content/repositories/root_repository/"
    )

Public Disclosure

Since this is a shipped project, once this is fixed and a new release published, a CVE number will need to be assigned.

Potential for Trusting Trust Attack

Since Kobalt is used to build Kobalt, there is the potential that this vulnerability could have been used to establish a trusting trust attack.

https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

A malicious compromise of one Kobalt build could mean that a vulnerability continues to live in the compiled bytecode of the project today.

@pabl0rg
Copy link
Contributor

pabl0rg commented Mar 30, 2019

this will be fixed by #500 and a new release

@JLLeitschuh
Copy link
Author

Friendly heads up that without an audit, a CVE number will be issued on June 1st, 2019.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants