* Eric Hodel ([EMAIL PROTECTED]) wrote: > On Jan 12, 2007, at 22:58, Paul Duncan wrote: > > * Eric Hodel ([EMAIL PROTECTED]) wrote: [snipped] > >> RubyGems does not check installation paths for gems before writing > >> files. > > > > The potential security problems with RubyGems are actually much worse > > than that. Documentation and tests are executed as the user doing the > > install (which, as you said, is usually root). That means I can embed > > arbitrary Ruby code in either the documentation template and it will > > usually be run as root. For example: > > I don't think there's an easy way around this one.
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.
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.
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.
[1] Debian uses PGP to do this, although they're not nearly as strict
about unsigned packages as they should be, especially in lieu of the
multiple attacks on Debian servers in the last several years.
> --
> Eric Hodel - [EMAIL PROTECTED] - http://blog.segment7.net
--
Paul Duncan <[EMAIL PROTECTED]> OpenPGP Key ID: 0x82C29562
http://www.pablotron.org/ http://www.paulduncan.org/
signature.asc
Description: Digital signature
_______________________________________________ Rubygems-developers mailing list Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
