What are the facts?
- A service resurrection attack is when access to a dead service, such as an expired domain or other abandoned resource, grants some degree of access or(or perceived access) to another resource.
- In Maven Central, software packages and related artifacts are organized into namespaces (referred to as groupId).
- The Java convention is to use domain names as part of the namespace.
- Maven Central requires a proof of namespace control in order to register or recover publish access to a namespace.
- There are two types of proof that are currently accepted.
- One type of proof is ability to add a DNS record to the domain.
- Another type of proof is to create a public SCM repository.
- About 80% of all new projects use a public SCM URL as the type of proof.
- Maven Central coordinate reference
- Software packages and related artifacts are published once to Maven Central - they are unable to be altered by publishers after they have been published.
Why is this important?
- A bad actor may be able to introduce malicious code into other software applications.
How?
- An SCM organization/account or DNS settings can be modified by a bad actor.
- The bad actor requests and receives publish access to Maven Central by demonstrating proof of namespace control.
- New versions of an existing software packages can be published to that namespace.
- Any software applications which 1) depend on the latest version of the existing software package; and 2) are rebuilt may execute the malicious code.
Examples
Reasons this is not a really big deal
- The risk is generally very low: best practice for Java applications is to specify versions for dependencies. If this is the case, then a newer version of dependencies will not be incorporated into an application.
- Maven Central provides other information, such as PGP signatures, which allows users to validate provenance of software packages they depend on.
- Maven Central provides assertions about control over a namespace and other information about software packages it hosts. But there are no implied guarantees about code quality or suitability to purpose of these packages: it is the responsibility of downstream quality and security toolchains to make this determination.
What might be done?
- If a revalidation of namespace occurs, Maven Central can make this information readily accessible to downstream quality & security toolchains.
- Maven Central can lock namespaces following a period of inactivity, and require revalidation in order to reuse it. Note this does not prevent a bad actor who controls the namespace from revalidating it.
- Better determine the scope of the problem. For instance, what percentage of packages in Maven Central published in the last 3 years include dependencies without valid, semantic version information? How many revalidations are performed on an annual basis? How many expired domains are associated with active namespaces?