Maven Repository Security issues: any war stories?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Maven Repository Security issues: any war stories?

Elliotte Rusty Harold
Folks,

A colleague is preparing a presentation on general dependency security
issues. I'm not aware of any compromises of the Maven repo system such
that a malicious actor was able to push malware to client systems, but
I'm not sure it's never happened.

Does anyone know about anything like the attack on npm a couple of
years ago <https://www.trendmicro.com/vinfo/dk/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets>
that happened in the Java space?

Even if something just went a little wonky in a way that could have
been used to serve malware but wasn't, that would be almost as
interesting.

Of course, I'd love for the answer to be, "No, that's never happened
to Java, and it can't because..." I suspect we're a little more
resistant to these classes of attacks than npm because version ranges
are far less common. However, I can't think of anything that would
prevent someone from buying and compromising future versions of any
particular artifact. It's not like intelligence agencies haven't
bought entire companies before,
<https://www.washingtonpost.com/graphics/2020/world/national-security/cia-crypto-encryption-machines-espionage/>
and most open source projects could be had for a lot less.

--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven Repository Security issues: any war stories?

Elliotte Rusty Harold
On Sat, Feb 29, 2020 at 2:55 AM Slawomir Jaranowski
<[hidden email]> wrote:
>
> Hi,
>
> In maven world all artifacts have pgp signature which is created by current
> maintainer (from some time pgp signature is required on Maven Central).
>
> You can verify signatures of all your dependencies, you can also track
> which pgp key is used for specific artifact.


Do typical invocations of Maven actually do this? That is, if the
signature of a downloaded artifact doesn't match does maven fail the
build?

If the signature has changed, will Maven fail the build? Or if the
signer has changed?

If not, is there a switch that can turn this on?

There is a now well documented third party plugin to do some of this,
but it's not clear exactly how it operates. E.g. how does it find and
verify the right public key with which to verify a signature?

https://www.simplify4u.org/pgpverify-maven-plugin/

--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven Repository Security issues: any war stories?

Slawomir Jaranowski
You are right, native method from maven does not support verifying of pgp
signature.

For pgpverify-maven-plugin you can prepare configuration file which
contains mapping artifact gav to pgp key fingerprint.
Without this configuration any existing key  is good.
From some time I try to collect which key should be used to sign artifact:
https://github.com/s4u/pgp-keys-map/blob/master/resources/pgp-keys-map.list

pgpverify-maven-plugin search keys on keyserver by default:
hkps.pool.sks-keyservers.net

Maybe information about signing key should has some place in maven
dependency declaration ... but I think is topic for another discussion.
Here I only want to show some possibility to protect for situation when
owner is changed.

sob., 29 lut 2020 o 12:21 Elliotte Rusty Harold <[hidden email]>
napisał(a):

> On Sat, Feb 29, 2020 at 2:55 AM Slawomir Jaranowski
> <[hidden email]> wrote:
> >
> > Hi,
> >
> > In maven world all artifacts have pgp signature which is created by
> current
> > maintainer (from some time pgp signature is required on Maven Central).
> >
> > You can verify signatures of all your dependencies, you can also track
> > which pgp key is used for specific artifact.
>
>
> Do typical invocations of Maven actually do this? That is, if the
> signature of a downloaded artifact doesn't match does maven fail the
> build?
>
> If the signature has changed, will Maven fail the build? Or if the
> signer has changed?
>
> If not, is there a switch that can turn this on?
>
> There is a now well documented third party plugin to do some of this,
> but it's not clear exactly how it operates. E.g. how does it find and
> verify the right public key with which to verify a signature?
>
> https://www.simplify4u.org/pgpverify-maven-plugin/
>
> --
> Elliotte Rusty Harold
> [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Sławomir Jaranowski
Reply | Threaded
Open this post in threaded view
|

Re: Maven Repository Security issues: any war stories?

Hervé BOUTEMY
In reply to this post by Elliotte Rusty Harold
Le samedi 29 février 2020, 08:55:14 CET Slawomir Jaranowski a écrit :
[...]
> Of course is open question how to verify maintainer and reputation of used
> maven artifacts.
+1

with Reproducible Builds, another layer of trust is to be able to confirm you
have the sources used to produce the binary: of course, it's up to you to read
and understand the sources, no magic...

Regards,

Hervé

>
> pt., 28 lut 2020 o 20:43 Manfred Moser <[hidden email]>
>
> napisał(a):
> > The order of repositories in a pom, settings and repo manager is crucial.
> > Some companies use their own repos on top since they trust them the most.
> > I
> > have seen internal teams deploying patched version into those which then
> > essentially override the real dep from central.
> >
> > This is a feature and is used quite often .. however it also opens the
> > door for abuse on that level.
> >
> > With all sorts of repos out there you really have to check what you
> > consume. If you consume repos that are not trustworthy or just badly
> > maintained .. anything is possible including security attacks... however I
> > have not seen it in practice.
> >
> > Overall its important that you use Central and othter trusted repos first
> > and foremost..
> >
> > Manfred
> >
> > Elliotte Rusty Harold wrote on 2020-02-28 11:01 (GMT -08:00):
> > > Folks,
> > >
> > > A colleague is preparing a presentation on general dependency security
> > > issues. I'm not aware of any compromises of the Maven repo system such
> > > that a malicious actor was able to push malware to client systems, but
> > > I'm not sure it's never happened.
> > >
> > > Does anyone know about anything like the attack on npm a couple of
> > > years ago
> > > <
> >
> > https://www.trendmicro.com/vinfo/dk/security/news/cybercrime-and-digital-t
> > hreats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets>
> > > that happened in the Java space?
> > >
> > > Even if something just went a little wonky in a way that could have
> > > been used to serve malware but wasn't, that would be almost as
> > > interesting.
> > >
> > > Of course, I'd love for the answer to be, "No, that's never happened
> > > to Java, and it can't because..." I suspect we're a little more
> > > resistant to these classes of attacks than npm because version ranges
> > > are far less common. However, I can't think of anything that would
> > > prevent someone from buying and compromising future versions of any
> > > particular artifact. It's not like intelligence agencies haven't
> > > bought entire companies before,
> > > <
> >
> > https://www.washingtonpost.com/graphics/2020/world/national-security/cia-c
> > rypto-encryption-machines-espionage/>
> > > and most open source projects could be had for a lot less.
> > >
> > > --
> > > Elliotte Rusty Harold
> > > [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]