On Jan 16, 2007, at 14:11, Paul Duncan wrote:
> Easy is certainly subjective, but there are a couple
ways to "fix" the
> documentation hole:
>
> * RubyGems could pre-generate documentation and just
copy it into
> place (I don't like this solution; it makes gems
significantly
> larger).
> * RubyGems should create an initial documentation
directory
> elsewhere, then drop root permissions (maybe even
chroot() as well)
> and generate the documentation as a user with no
privileges in the
> safe location, then move the generated documentation
into place.
>
> The second option is preferrable, and it's actually a
lot easier to
> implement than it sounds. I have a half-working patch
that I can
> clean
> up and submit if there's any interest. Basically it
just creates a
> copy
> of the source in a temporary directory, then forks a
child
> process which chroot() itself and drops it's
permissions before
> generating any documentation. The parent waits for the
child to exit,
> then copies the generated documentation into place.
Can you post this one to the tracker?
> Unfortunately that doesn't really fix much of anything,
because it
> only
> closes off the huge security hole in documentation
generation. It
> doesn't prevent a malicious user from trojaning an
existing gem and
> adding files or replacing legitimate code with pretty
much
> whatever they want.
>
> The _really_ bad news is this type of attack became a
whole lot easier
> once RubyGems started using mirrors. Instead of
worrying about a
> malicious user breaking into one machine
(rubyforge.org), we now
> have to
> worry about them breaking into N machines, where N is
the number of
> Gem mirrors.
>
> The only way to completely eliminate this type of
attack would be to
> force gem authors to sign their gems, create an author
certificate
> distribution mechanism (or tie it to some sort of
existing trust
> mechanism like X.509 or PGP keyservers [1]), remove all
the unsigned
> gems from the Gem repositories, and (finally) enable
signature
> checking
> by default in RubyGems.
>
> Frankly, I don't see all of that (or any of it, really)
happening any
> time soon.
Could we mitigate that by including a list of SHA1s of
packages on
the rubyforge gem server, and use it to validate packages
from mirrors?
> The idea behind all the above steps is to assume the
contents of
> packages can and eventually will be tinkered with, and
to provide a
> way
> for users to be reasonably certain that nothing fishy
has happened to
> packages once they're out of the authors' hands and on
the Gem
> repositories.
--
Eric Hodel - drbrain segment7.net - http://blog.segment7.net
I LIT YOUR GEM ON FIRE!
_______________________________________________
Rubygems-developers mailing list
Rubygems-developersrubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-develope
rs
|