Ensuring artifact integrity with artifact pinning

[Andrew Todd <at...@auspicacious.org>]

Hello all,

I am considering writing a Maven plugin to help improve confidence in the
integrity of the Maven artifacts used by a project. I'm looking for
feedback on this idea before I start working on it, hopefully this winter.

Here's a brief overview of what I have in mind.

Maven, like many other package and artifact managers, doesn't offer
particularly strong protections against the compromise of artifacts. The
situation has improved somewhat in the last few years, as more people have
paid attention to the problem. When the central repository enabled HTTPS
for everyone, it was a big step forward -- it's now much harder for someone
to deliver a malicious package to you by intercepting your Web traffic, for
instance. Central also requires code signing when artifacts are uploaded,
which helps prevent the uploading of malicious artifacts somewhat.

However, it's my understanding that there's no useful way for Maven clients
to check those signatures -- not to mention that there's still other ways
that a malicious or malformed package could be served to a Maven client.
And any dependency in your application is a potential attack vector.

You may have heard of Certificate Pinning:
https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning, which adds a
trust-on-first-use aspect to HTTPS certificates (and was not quite the
right solution for the problem it was helping to solve; it's now
deprecated).

What I propose is a similar idea, but for Maven artifacts. When this plugin
is enabled, each Maven build will generate a manifest of all artifacts that
that build depends on, along with the hashes for all of those artifacts.
This manifest could be committed into source control alongside the POM
file. From that point on, the artifact is considered "pinned" to that hash
value. If the plugin observes that any of the hashes it has already pinned
have changed, the build will fail until a developer investigates and
corrects the problem.

Aside from improving trust, using this plugin could also help troubleshoot
"works on my machine" errors with more transparency into the actual
artifacts used in the build than is present in current tools such as mvn
help:dependency-tree.

Of course, this wouldn't work for SNAPSHOTs. I'm not sure how much more
improvement can be made there. This plugin would also be inappropriate for
environments where artifacts are routinely overwritten -- which is really
not a good idea anyway. With more work the plugin could be configured to
ignore specific artifacts.

In the future, this plugin could also support publishing the manifest
alongside your artifact in Central, so that someone else who depends on
your artifact can determine that all transitive dependencies have been
retrieved identically to how they were by the original developer.

With a lot more support in the longer-term, this could move in the
direction that Certificate Transparency has, towards public logs:
https://en.wikipedia.org/wiki/Certificate_Transparency

These measures, if adopted widely by Maven users, could help detect
unexpected changes to artifacts in Central early, as well as help expose
build stability problems. Building trust in computing is an incremental
problem, and this would help move things a little in the right direction,
in a backwards-compatible fashion.

I'd like to hear your thoughts and suggestions -- not to mention hearing if
you'd be interested in adopting such a tool. Obviously there's a number of
details to hammer out.


Thanks,
Andrew

Re: Ensuring artifact integrity with artifact pinning

[Andrew Todd <at...@auspicacious.org>]

Thanks for the pointers. It's also worth noting that Google's build tool
Bazel allows users to list an artifact sha1 as part of the artifact
definition, although it's not particularly automated. They consider it
important: "It is a security risk to omit the SHA-1 as remote files can
change."
https://docs.bazel.build/versions/master/be/workspace.html#maven_jar

On Wed, Nov 21, 2018 at 4:01 AM Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:

> It’s an idea I also started a while back, but the problem is, it is not
> really a good security as long as you do the checksum Test before executing
> any plugins, which is a bit hard to do.
> You find some older sample code here
> https://github.com/ecki/lockdep-maven-plugin
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> ________________________________
> Von: Robert Scholte <rf...@apache.org>
> Gesendet: Dienstag, November 20, 2018 7:48 PM
> An: Maven Users List
> Betreff: Re: Ensuring artifact integrity with artifact pinning
>
> Hi,
>
> seems related to MNG-6026[1].
>
> thanks,
> Robert
>
> [1] https://issues.apache.org/jira/browse/MNG-6026
>
>
> On Tue, 20 Nov 2018 12:26:54 +0100, Andrew Todd <at...@auspicacious.org>
> wrote:
>
> > Hello all,
> >
> > I am considering writing a Maven plugin to help improve confidence in the
> > integrity of the Maven artifacts used by a project. I'm looking for
> > feedback on this idea before I start working on it, hopefully this
> > winter.
> >
> > Here's a brief overview of what I have in mind.
> >
> > Maven, like many other package and artifact managers, doesn't offer
> > particularly strong protections against the compromise of artifacts. The
> > situation has improved somewhat in the last few years, as more people
> > have
> > paid attention to the problem. When the central repository enabled HTTPS
> > for everyone, it was a big step forward -- it's now much harder for
> > someone
> > to deliver a malicious package to you by intercepting your Web traffic,
> > for
> > instance. Central also requires code signing when artifacts are uploaded,
> > which helps prevent the uploading of malicious artifacts somewhat.
> >
> > However, it's my understanding that there's no useful way for Maven
> > clients
> > to check those signatures -- not to mention that there's still other ways
> > that a malicious or malformed package could be served to a Maven client.
> > And any dependency in your application is a potential attack vector.
> >
> > You may have heard of Certificate Pinning:
> > https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning, which adds a
> > trust-on-first-use aspect to HTTPS certificates (and was not quite the
> > right solution for the problem it was helping to solve; it's now
> > deprecated).
> >
> > What I propose is a similar idea, but for Maven artifacts. When this
> > plugin
> > is enabled, each Maven build will generate a manifest of all artifacts
> > that
> > that build depends on, along with the hashes for all of those artifacts.
> > This manifest could be committed into source control alongside the POM
> > file. From that point on, the artifact is considered "pinned" to that
> > hash
> > value. If the plugin observes that any of the hashes it has already
> > pinned
> > have changed, the build will fail until a developer investigates and
> > corrects the problem.
> >
> > Aside from improving trust, using this plugin could also help
> > troubleshoot
> > "works on my machine" errors with more transparency into the actual
> > artifacts used in the build than is present in current tools such as mvn
> > help:dependency-tree.
> >
> > Of course, this wouldn't work for SNAPSHOTs. I'm not sure how much more
> > improvement can be made there. This plugin would also be inappropriate
> > for
> > environments where artifacts are routinely overwritten -- which is really
> > not a good idea anyway. With more work the plugin could be configured to
> > ignore specific artifacts.
> >
> > In the future, this plugin could also support publishing the manifest
> > alongside your artifact in Central, so that someone else who depends on
> > your artifact can determine that all transitive dependencies have been
> > retrieved identically to how they were by the original developer.
> >
> > With a lot more support in the longer-term, this could move in the
> > direction that Certificate Transparency has, towards public logs:
> > https://en.wikipedia.org/wiki/Certificate_Transparency
> >
> > These measures, if adopted widely by Maven users, could help detect
> > unexpected changes to artifacts in Central early, as well as help expose
> > build stability problems. Building trust in computing is an incremental
> > problem, and this would help move things a little in the right direction,
> > in a backwards-compatible fashion.
> >
> > I'd like to hear your thoughts and suggestions -- not to mention hearing
> > if
> > you'd be interested in adopting such a tool. Obviously there's a number
> > of
> > details to hammer out.
> >
> >
> > Thanks,
> > Andrew
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: Ensuring artifact integrity with artifact pinning

[Bernd Eckenfels <ec...@zusammenkunft.net>]

It’s an idea I also started a while back, but the problem is, it is not really a good security as long as you do the checksum Test before executing any plugins, which is a bit hard to do.
You find some older sample code here https://github.com/ecki/lockdep-maven-plugin

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: Robert Scholte <rf...@apache.org>
Gesendet: Dienstag, November 20, 2018 7:48 PM
An: Maven Users List
Betreff: Re: Ensuring artifact integrity with artifact pinning

Hi,

seems related to MNG-6026[1].

thanks,
Robert

[1] https://issues.apache.org/jira/browse/MNG-6026


On Tue, 20 Nov 2018 12:26:54 +0100, Andrew Todd <at...@auspicacious.org>
wrote:

> Hello all,
>
> I am considering writing a Maven plugin to help improve confidence in the
> integrity of the Maven artifacts used by a project. I'm looking for
> feedback on this idea before I start working on it, hopefully this
> winter.
>
> Here's a brief overview of what I have in mind.
>
> Maven, like many other package and artifact managers, doesn't offer
> particularly strong protections against the compromise of artifacts. The
> situation has improved somewhat in the last few years, as more people
> have
> paid attention to the problem. When the central repository enabled HTTPS
> for everyone, it was a big step forward -- it's now much harder for
> someone
> to deliver a malicious package to you by intercepting your Web traffic,
> for
> instance. Central also requires code signing when artifacts are uploaded,
> which helps prevent the uploading of malicious artifacts somewhat.
>
> However, it's my understanding that there's no useful way for Maven
> clients
> to check those signatures -- not to mention that there's still other ways
> that a malicious or malformed package could be served to a Maven client.
> And any dependency in your application is a potential attack vector.
>
> You may have heard of Certificate Pinning:
> https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning, which adds a
> trust-on-first-use aspect to HTTPS certificates (and was not quite the
> right solution for the problem it was helping to solve; it's now
> deprecated).
>
> What I propose is a similar idea, but for Maven artifacts. When this
> plugin
> is enabled, each Maven build will generate a manifest of all artifacts
> that
> that build depends on, along with the hashes for all of those artifacts.
> This manifest could be committed into source control alongside the POM
> file. From that point on, the artifact is considered "pinned" to that
> hash
> value. If the plugin observes that any of the hashes it has already
> pinned
> have changed, the build will fail until a developer investigates and
> corrects the problem.
>
> Aside from improving trust, using this plugin could also help
> troubleshoot
> "works on my machine" errors with more transparency into the actual
> artifacts used in the build than is present in current tools such as mvn
> help:dependency-tree.
>
> Of course, this wouldn't work for SNAPSHOTs. I'm not sure how much more
> improvement can be made there. This plugin would also be inappropriate
> for
> environments where artifacts are routinely overwritten -- which is really
> not a good idea anyway. With more work the plugin could be configured to
> ignore specific artifacts.
>
> In the future, this plugin could also support publishing the manifest
> alongside your artifact in Central, so that someone else who depends on
> your artifact can determine that all transitive dependencies have been
> retrieved identically to how they were by the original developer.
>
> With a lot more support in the longer-term, this could move in the
> direction that Certificate Transparency has, towards public logs:
> https://en.wikipedia.org/wiki/Certificate_Transparency
>
> These measures, if adopted widely by Maven users, could help detect
> unexpected changes to artifacts in Central early, as well as help expose
> build stability problems. Building trust in computing is an incremental
> problem, and this would help move things a little in the right direction,
> in a backwards-compatible fashion.
>
> I'd like to hear your thoughts and suggestions -- not to mention hearing
> if
> you'd be interested in adopting such a tool. Obviously there's a number
> of
> details to hammer out.
>
>
> Thanks,
> Andrew

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Ensuring artifact integrity with artifact pinning

[Robert Scholte <rf...@apache.org>]

Hi,

seems related to MNG-6026[1].

thanks,
Robert

[1] https://issues.apache.org/jira/browse/MNG-6026


On Tue, 20 Nov 2018 12:26:54 +0100, Andrew Todd <at...@auspicacious.org>  
wrote:

> Hello all,
>
> I am considering writing a Maven plugin to help improve confidence in the
> integrity of the Maven artifacts used by a project. I'm looking for
> feedback on this idea before I start working on it, hopefully this  
> winter.
>
> Here's a brief overview of what I have in mind.
>
> Maven, like many other package and artifact managers, doesn't offer
> particularly strong protections against the compromise of artifacts. The
> situation has improved somewhat in the last few years, as more people  
> have
> paid attention to the problem. When the central repository enabled HTTPS
> for everyone, it was a big step forward -- it's now much harder for  
> someone
> to deliver a malicious package to you by intercepting your Web traffic,  
> for
> instance. Central also requires code signing when artifacts are uploaded,
> which helps prevent the uploading of malicious artifacts somewhat.
>
> However, it's my understanding that there's no useful way for Maven  
> clients
> to check those signatures -- not to mention that there's still other ways
> that a malicious or malformed package could be served to a Maven client.
> And any dependency in your application is a potential attack vector.
>
> You may have heard of Certificate Pinning:
> https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning, which adds a
> trust-on-first-use aspect to HTTPS certificates (and was not quite the
> right solution for the problem it was helping to solve; it's now
> deprecated).
>
> What I propose is a similar idea, but for Maven artifacts. When this  
> plugin
> is enabled, each Maven build will generate a manifest of all artifacts  
> that
> that build depends on, along with the hashes for all of those artifacts.
> This manifest could be committed into source control alongside the POM
> file. From that point on, the artifact is considered "pinned" to that  
> hash
> value. If the plugin observes that any of the hashes it has already  
> pinned
> have changed, the build will fail until a developer investigates and
> corrects the problem.
>
> Aside from improving trust, using this plugin could also help  
> troubleshoot
> "works on my machine" errors with more transparency into the actual
> artifacts used in the build than is present in current tools such as mvn
> help:dependency-tree.
>
> Of course, this wouldn't work for SNAPSHOTs. I'm not sure how much more
> improvement can be made there. This plugin would also be inappropriate  
> for
> environments where artifacts are routinely overwritten -- which is really
> not a good idea anyway. With more work the plugin could be configured to
> ignore specific artifacts.
>
> In the future, this plugin could also support publishing the manifest
> alongside your artifact in Central, so that someone else who depends on
> your artifact can determine that all transitive dependencies have been
> retrieved identically to how they were by the original developer.
>
> With a lot more support in the longer-term, this could move in the
> direction that Certificate Transparency has, towards public logs:
> https://en.wikipedia.org/wiki/Certificate_Transparency
>
> These measures, if adopted widely by Maven users, could help detect
> unexpected changes to artifacts in Central early, as well as help expose
> build stability problems. Building trust in computing is an incremental
> problem, and this would help move things a little in the right direction,
> in a backwards-compatible fashion.
>
> I'd like to hear your thoughts and suggestions -- not to mention hearing  
> if
> you'd be interested in adopting such a tool. Obviously there's a number  
> of
> details to hammer out.
>
>
> Thanks,
> Andrew

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org