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 09/13/2011 04:31 PM, Thomas Hallgren wrote:
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

If we assume that Eclipse Member companies are currently downloading your binaries from the Indigo release stream and packaging them into their commercial applications, then preventing Hudson from altering those Indigo binaries after-the-fact really matters. I think it does, anyway. If you disagree, I'd like to better understand how.

In my original email, I was suggesting that you perform some kind of validation that the build output you are about to copy is sane, where 'sane' can be as simple as 'weekly builds run at 10:00am on Wednesday, don't copy anything else'.

When Indigo was released, the Hudson build output wasn't just placed up for downloads without many eyeballs scrutinizing it. This sanitization may not be required for nightly or weekly builds, but for official releases to be consumed by the general public, as a consumer I would be disappointed if projects didn't ensure their binaries were safe.


I think we have to trust Hudson and the plug-ins that we install.
Of course we do. We also trust Linux, the Apache web server and all the other software packages that are on Eclipse.org. But realistically, that doesn't mean those packages cannot be exploited in ways unknown to us today by someone, somewhere, who is just waiting for an opportunity to cause us harm.


If we don't, then we will need very thorough checks of all material that we promote to the download area at all times.

As Eclipse enters embedded, runtime and server markets, doing that would be a bad idea? Does no one run a network sniffer to see if Eclipse, or any other software, is sending out random data to the world? Surely I'm not the only one who periodically examines my personal network traffic to see what I'm saying...?


Just removing the ACL will not increase the security.

That is incorrect. As I've explained, removing the ACL (ie, not allowing Hudson to write to the general downloads area at all) will limit the scope of any damage to that of a single committer's account running a publication process. Since your publication process doesn't involve overwriting files created in the past, the beginning of any potential damage would be easy to discern and have a clear point-in-time.

Of course, if committers insist their promotion script simply copy $A to $B without any validation whatsoever, then we should just chmod 777 the entire downloads area and be done with it. But if something breaks, don't ask me to fix it :-)

All in all, this discussion illustrates that implementing a centralized publishing process would go a long way in solving these potential problems...


Denis




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





Back to the top