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: [email protected] [mailto:[email protected]] On
Behalf Of Stephen Connolly
Sent: 30 July 2012 10:06
To: [email protected]
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 <[email protected]<mailto:[email protected]>> wrote:
> -----Original Message-----
> From: [email protected]<mailto:[email protected]>
> [mailto:jenkinsci-<mailto:jenkinsci->
> [email protected]<mailto:[email protected]>] On Behalf Of Jesse Glick
> Sent: 27 July 2012 21:34
> To: [email protected]<mailto:[email protected]>
> 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
[email protected]<mailto:[email protected]> 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
**************************************************************************************
