Verify downloaded jpi-files

[Fredrik Orderud]

(Forwarded posting https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/2v8csoO0cxE )

In my corporate environment, we are working behind a firewall that returns "nice" HTML webpages with detailed error instructions instead of a plain "connection refused" error in situations of invalid PROXY settings.

We have experienced several times that Jenkins servers with improper PROXY settings will download jpi-files for plugin updates containing just "error HTML webpage" content. Jenkins doesn't seem to detect this, and instead tries to install the corrupted plugin. What then happens is that the plugin upgrade fails, and the plugin gets _uninstalled_ altogether. Any job-configuration related to the accidentally uninstalled plugin then also seems to be removed, which is pretty serious.

Would it be possible to add some sort of integrity-verification to downloaded jpi-files prior to install them, so that we avoid accidentally uninstalling plugins?


Thanks in advance,
Fredrik Orderud

[nicolas de loof-2]

update center (http://updates.jenkins-ci.org/download/plugins/) don't includes md5 / sha1 checksums afaik, but this would be a good addition for your use case and many others to avoid broken installations due to errors during plugin download.

2012/7/27 Fredrik Orderud <[hidden email]>

(Forwarded posting https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/2v8csoO0cxE )

In my corporate environment, we are working behind a firewall that returns "nice" HTML webpages with detailed error instructions instead of a plain "connection refused" error in situations of invalid PROXY settings.

We have experienced several times that Jenkins servers with improper PROXY settings will download jpi-files for plugin updates containing just "error HTML webpage" content. Jenkins doesn't seem to detect this, and instead tries to install the corrupted plugin. What then happens is that the plugin upgrade fails, and the plugin gets _uninstalled_ altogether. Any job-configuration related to the accidentally uninstalled plugin then also seems to be removed, which is pretty serious.

Would it be possible to add some sort of integrity-verification to downloaded jpi-files prior to install them, so that we avoid accidentally uninstalling plugins?


Thanks in advance,
Fredrik Orderud

[Fredrik Orderud]

Verifying a MD5/SHA1 hash would of course be a "bullet proof" solution, but a simpler check against the in-built JAR/ZIP-file CRC-32 checksum would probably be good enough in most situations. I'm pretty sure that a CRC-32 check is triggered by just attempting to open the file.


kl. 14:35:57 UTC+2 fredag 27. juli 2012 skrev nicolas de loof følgende:

update center (http://updates.jenkins-ci.org/download/plugins/) don't includes md5 / sha1 checksums afaik, but this would be a good addition for your use case and many others to avoid broken installations due to errors during plugin download.

2012/7/27 Fredrik Orderud <[hidden email]>

(Forwarded posting https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/2v8csoO0cxE )

In my corporate environment, we are working behind a firewall that returns "nice" HTML webpages with detailed error instructions instead of a plain "connection refused" error in situations of invalid PROXY settings.

We have experienced several times that Jenkins servers with improper PROXY settings will download jpi-files for plugin updates containing just "error HTML webpage" content. Jenkins doesn't seem to detect this, and instead tries to install the corrupted plugin. What then happens is that the plugin upgrade fails, and the plugin gets _uninstalled_ altogether. Any job-configuration related to the accidentally uninstalled plugin then also seems to be removed, which is pretty serious.

Would it be possible to add some sort of integrity-verification to downloaded jpi-files prior to install them, so that we avoid accidentally uninstalling plugins?


Thanks in advance,
Fredrik Orderud

[Jesse Glick-4]

On 07/27/2012 08:58 AM, Fredrik Orderud wrote:
> a simpler check against the in-built JAR/ZIP-file CRC-32 checksum would probably be good enough in most situations

Even simpler: check if the file starts with 0x50 0x4b 0x03 0x04, the ZIP magic. If not, it is some junk like an error page which should be treated like a 404 or other
connection error.

File a bug or open a pull request; hudson.model.UpdateCenter.UpdateCenterConfiguration.postValidate could easily do this, I think.

[Fredrik Orderud]

I've now registered:
https://issues.jenkins-ci.org/browse/JENKINS-14616

kl. 22:33:36 UTC+2 fredag 27. juli 2012 skrev Jesse Glick følgende:

On 07/27/2012 08:58 AM, Fredrik Orderud wrote:
> a simpler check against the in-built JAR/ZIP-file CRC-32 checksum would probably be good enough in most situations

Even simpler: check if the file starts with 0x50 0x4b 0x03 0x04, the ZIP magic. If not, it is some junk like an error page which should be treated like a 404 or other
connection error.

File a bug or open a pull request; hudson.model.UpdateCenter.UpdateCenterConfiguration.postValidate could easily do this, I think.

[Nord, James]

> -----Original Message-----
> From: [hidden email] [mailto:jenkinsci-
> [hidden email]] On Behalf Of Jesse Glick
> Sent: 27 July 2012 21:34
> To: [hidden email]
> Subject: Re: Verify downloaded jpi-files
>
> On 07/27/2012 08:58 AM, Fredrik Orderud wrote:
> > a simpler check against the in-built JAR/ZIP-file CRC-32 checksum
> > would probably be good enough in most situations
>
> Even simpler: check if the file starts with 0x50 0x4b 0x03 0x04, the ZIP magic. If
> not, it is some junk like an error page which should be treated like a 404 or
> other connection error.
>
> File a bug or open a pull request;
> hudson.model.UpdateCenter.UpdateCenterConfiguration.postValidate could
> easily do this, I think.

Isn’t this a security issue - I thought the update.json was signed to make it hard to prevent installing malicious components (but this just prevents the main Jenkins site update from being forged - which is no protection at all)
As it stands you don’t need to do anything complex just some dns hijacking of a mirror (or attack a mirror, or be an evil mirror) and then you can just replace whatever hpi you want (pick a popular one like git or svn) then you can serve up any arbitrary code that gets executed?

I guess the update.json needs to include the signatures of components as well for this to work (with 3rd party update sites).

To be honest I thought I recalled a discussion that this was already done :-(

/James

________________________________


**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the [hidden email] and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

[stephenconnolly]

The update metadata includes the signature of the metadata as well as the sha1 sums of all the downloads, so that gives plenty of security.... though I agree somebody could use that injection trick to create a plugin with a matching sha1 to the sha1 in the metadata... but I suspect that it would be a lot of effort... and keep in mind that if it is a popular plugin that will get updated more frequently so the effort will be wasted... and the non-popular plugins will be less likely to get uptake

On 30 July 2012 09:50, Nord, James <[hidden email]> wrote:

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]
> [hidden email]] On Behalf Of Jesse Glick
> Sent: 27 July 2012 21:34
> To: [hidden email]
> Subject: Re: Verify downloaded jpi-files
>
> On 07/27/2012 08:58 AM, Fredrik Orderud wrote:
> > a simpler check against the in-built JAR/ZIP-file CRC-32 checksum
> > would probably be good enough in most situations
>
> Even simpler: check if the file starts with 0x50 0x4b 0x03 0x04, the ZIP magic. If
> not, it is some junk like an error page which should be treated like a 404 or
> other connection error.
>
> File a bug or open a pull request;
> hudson.model.UpdateCenter.UpdateCenterConfiguration.postValidate could
> easily do this, I think.

Isn’t this a security issue - I thought the update.json was signed to make it hard to prevent installing malicious components (but this just prevents the main Jenkins site update from being forged - which is no protection at all)
As it stands you don’t need to do anything complex just some dns hijacking of a mirror (or attack a mirror, or be an evil mirror) and then you can just replace whatever hpi you want (pick a popular one like git or svn) then you can serve up any arbitrary code that gets executed?

I guess the update.json needs to include the signatures of components as well for this to work (with 3rd party update sites).

To be honest I thought I recalled a discussion that this was already done :-(

/James

________________________________


**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the [hidden email] and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

[Nord, James]

the json that I retrieved from my commercially supported version contained zero hashes, the JSON I have just pulled from retrieved from the default update site (http://updates.jenkins-ci.org/update-center.json) did contain hashes.

 

So not a Jenkins issue (sorry for causing any confusion on the list)

 

Regards,

 

                /James

 

 

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Stephen Connolly
Sent: 30 July 2012 10:06
To: [hidden email]
Subject: Re: Verify downloaded jpi-files

 

The update metadata includes the signature of the metadata as well as the sha1 sums of all the downloads, so that gives plenty of security.... though I agree somebody could use that injection trick to create a plugin with a matching sha1 to the sha1 in the metadata... but I suspect that it would be a lot of effort... and keep in mind that if it is a popular plugin that will get updated more frequently so the effort will be wasted... and the non-popular plugins will be less likely to get uptake

On 30 July 2012 09:50, Nord, James <[hidden email]> wrote:

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]
> [hidden email]] On Behalf Of Jesse Glick
> Sent: 27 July 2012 21:34
> To: [hidden email]
> Subject: Re: Verify downloaded jpi-files
>
> On 07/27/2012 08:58 AM, Fredrik Orderud wrote:
> > a simpler check against the in-built JAR/ZIP-file CRC-32 checksum
> > would probably be good enough in most situations
>
> Even simpler: check if the file starts with 0x50 0x4b 0x03 0x04, the ZIP magic. If
> not, it is some junk like an error page which should be treated like a 404 or
> other connection error.
>
> File a bug or open a pull request;
> hudson.model.UpdateCenter.UpdateCenterConfiguration.postValidate could
> easily do this, I think.

Isn’t this a security issue - I thought the update.json was signed to make it hard to prevent installing malicious components (but this just prevents the main Jenkins site update from being forged - which is no protection at all)
As it stands you don’t need to do anything complex just some dns hijacking of a mirror (or attack a mirror, or be an evil mirror) and then you can just replace whatever hpi you want (pick a popular one like git or svn) then you can serve up any arbitrary code that gets executed?

I guess the update.json needs to include the signatures of components as well for this to work (with 3rd party update sites).

To be honest I thought I recalled a discussion that this was already done :-(

/James

________________________________


**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the [hidden email] and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

 

[stephenconnolly]

And that commercially supported version does not currently contain hashes because it serves the content directly and checks the hash behind the scene... though we will be adding hashes shortly ;-) 

On 30 July 2012 11:00, Nord, James <[hidden email]> wrote:

the json that I retrieved from my commercially supported version contained zero hashes, the JSON I have just pulled from retrieved from the default update site (http://updates.jenkins-ci.org/update-center.json) did contain hashes.

 

So not a Jenkins issue (sorry for causing any confusion on the list)

 

Regards,

 

                /James

 

 

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Stephen Connolly
Sent: 30 July 2012 10:06

To: [hidden email]
Subject: Re: Verify downloaded jpi-files

 

The update metadata includes the signature of the metadata as well as the sha1 sums of all the downloads, so that gives plenty of security.... though I agree somebody could use that injection trick to create a plugin with a matching sha1 to the sha1 in the metadata... but I suspect that it would be a lot of effort... and keep in mind that if it is a popular plugin that will get updated more frequently so the effort will be wasted... and the non-popular plugins will be less likely to get uptake

On 30 July 2012 09:50, Nord, James <[hidden email]> wrote:

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]
> [hidden email]] On Behalf Of Jesse Glick
> Sent: 27 July 2012 21:34
> To: [hidden email]
> Subject: Re: Verify downloaded jpi-files
>
> On 07/27/2012 08:58 AM, Fredrik Orderud wrote:
> > a simpler check against the in-built JAR/ZIP-file CRC-32 checksum
> > would probably be good enough in most situations
>
> Even simpler: check if the file starts with 0x50 0x4b 0x03 0x04, the ZIP magic. If
> not, it is some junk like an error page which should be treated like a 404 or
> other connection error.
>
> File a bug or open a pull request;
> hudson.model.UpdateCenter.UpdateCenterConfiguration.postValidate could
> easily do this, I think.

Isn’t this a security issue - I thought the update.json was signed to make it hard to prevent installing malicious components (but this just prevents the main Jenkins site update from being forged - which is no protection at all)
As it stands you don’t need to do anything complex just some dns hijacking of a mirror (or attack a mirror, or be an evil mirror) and then you can just replace whatever hpi you want (pick a popular one like git or svn) then you can serve up any arbitrary code that gets executed?

I guess the update.json needs to include the signatures of components as well for this to work (with 3rd party update sites).

To be honest I thought I recalled a discussion that this was already done :-(

/James

________________________________


**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the [hidden email] and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************