RE: Verify downloaded jpi-files
-Original Message- From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci- d...@googlegroups.com] On Behalf Of Jesse Glick Sent: 27 July 2012 21:34 To: jenkinsci-dev@googlegroups.com 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 postmas...@nds.com 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 **
RE: Verify downloaded jpi-files
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: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-dev@googlegroups.com] On Behalf Of Stephen Connolly Sent: 30 July 2012 10:06 To: jenkinsci-dev@googlegroups.com 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 jn...@nds.commailto:jn...@nds.com wrote: -Original Message- From: jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com [mailto:jenkinsci-mailto:jenkinsci- d...@googlegroups.commailto:d...@googlegroups.com] On Behalf Of Jesse Glick Sent: 27 July 2012 21:34 To: jenkinsci-dev@googlegroups.commailto:jenkinsci-dev@googlegroups.com 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 postmas...@nds.commailto:postmas...@nds.com 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 **
Re: Verify downloaded jpi-files
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 forde...@gmail.com (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
Re: Verify downloaded jpi-files
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 forde...@gmail.com (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
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.
