Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Why allowing Hudson to write to your downloads is a Bad Idea.

On 2011-09-13 21:57, Denis Roy wrote:
If someone exploits Hudson, I doubt they are going to actually run your build job. All they need to do is upload content and new checksums directly to the downloads area to replace your most recent release. That would raise no red flags :)

But does that matter really? Let's say all projects create some kind of promotion script that copies the Hudson output from some folder to the download area. The sum of all those promotion scripts will give the Hudson account the opportunity to get just about anything promoted to any destination. Still no red flags.

I think we have to trust Hudson and the plug-ins that we install. If we don't, then we will need very thorough checks of all material that we promote to the download area at all times. Just removing the ACL will not increase the security.

Regards,
Thomas Hallgren


Denis


On 09/13/2011 03:48 PM, Igor Fedorenko wrote:
Denis,

Can you elaborate on the suggested promotion job approach? What are the
security advantages of forcing extra layer of automation in this
particular case? I am not a security expert, but if Hundon instance gets
compromised and changed to produce "bad" artifacts with "good"
signatures and checksums, wouldn't the promotion job make these
bad artifacts available from download.e.o?

--
Regards,
Igor

On 11-09-13 3:28 PM, Denis Roy wrote:
While we're in a security-conscious frame-of-mind...


Many projects allow the Hudson user account to write to their download
directories. Projects use one of these two ways to do this:

1. They add an ACL on their download directory that allows the Hudson
Build user to write there.

2. They chmod 777 their downloads directory, thus allowing everyone full
access to their downloads directory.


Most of you understand that #2 is a clear violation of any kind of
security we hope to maintain here at Eclipse. *Don't do it. Please ask
us for alternatives.*


While #1 may seem like a better option, it has implications. Allowing
Hudson to alter downloads means that other committers can alter your
downloads via a Hudson job. I am not worried about this since I trust
our committers.

The issue is about *trusting a public-facing application* (Hudson) *and
all its plugins*, each of which may contain security vulnerabilities. If
unauthorized control of Hudson was achieved, downloads could be replaced
with compromised ZIP and JAR files.

As Hudson can sign on behalf of the Eclipse Foundation, compromised
downloads would appear authentic with digital signatures and valid
checksums. A keystroke logger could leak sensitive credentials to a
third party. This is how unauthorized root access begins. Far-fetched?
Not at all.

The above is not a stab at Hudson, Winstone or any other specific
software -- all software may contain a vulnerability, including the
Apache webserver and the Linux Kernel.

Hence, I *strongly* recommend you use a promotion job on
build.eclipse.org which publishes known-good content from Hudson. A
simple script which reads a state from Hudson, runs some sanity checks
and wget's files and saves them in the downloads directory is a great start.


I appreciate your taking the time to read this. My goal is not to
encumber you with senseless, counter-productive dogma, but to strike a
balance between security and convenience... with a slight bias towards
security :-)

Denis


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



Back to the top