[Rubygems-developers] Need to release 0.9.1 due to security exploit
drbrain at segment7.net
Wed Jan 17 21:16:59 EST 2007
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
> * 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
> up and submit if there's any interest. Basically it just creates a
> 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
> 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 ), remove all the unsigned
> gems from the Gem repositories, and (finally) enable signature
> 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
> 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
Eric Hodel - drbrain at segment7.net - http://blog.segment7.net
I LIT YOUR GEM ON FIRE!
More information about the Rubygems-developers