[
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.
|
I'm going to step out on a ledge here, and say, we need to let Hudson be
able to deploy artifacts to download.eclipse.org. I even have an open
request to allow Hudson to do just this, especially for Maven
artifacts. I really want Hudson to be able to deploy to
maven.eclipse.org as well.
Maven has the ability to deploy artifacts to a file system, or to a
Maven repository (like Nexus). The Nexus instance itself can be
secured, Hudson can be given it's own user id and password or other
secure method to deploy the artifacts.
I like others don't see the Cron job being any more secure.
We need to strike a balance between the needs for the ever number of
growing projects to deploy their artifacts, and do it in an automated
way WITHOUT unneeded human intervention, and the desire to make sure
that we have eclipse.org as secure as possible.
Now, if you want to provide a STAGING to type system. We could have had
Nexus PRO installed, it was offered to us by Sonatype, and it allows for
a promotion of Maven artifacts to a TEST, QA, or any other number of
repos, and then final promotion to a release directory. But Nexus Pro
was turned down by eclipse.org.
If you really want to add a STAGING system to Hudson, so that items have
to be approved before they are copied over, then this blog entry might
be useful.
http://www.blackpepper.co.uk/black-pepper-blog/How-to-create-a-deployment-pipeline-using-Hudson.html
The bottom line here is, if somebody wants to be mischeivous, they will
find a way to do it. The only safe way is to shut down Hudson, and not
provide it's functionality at all. Can't get hacked that way if it
doesn't exist.
Dave
On 09/13/2011 05:56 PM, Denis Roy wrote:
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
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
