There are a fair number of people with commit access to ruby-lang. I, for example, could add a trojan to the latest version of RDoc that would rewrite the source code to every Ruby program it documented.
When was the last time you studied all the source code for RDoc to ensure it is safe?
If you want safety, then you probably shouldn't be downloading stuff off the web and running it, at least until it has been verified by a professional team of QA folks. Microsoft software, for example, must be secure for that reason.
OpenSource software has operated this way for years. Taking that fact and labeling RubyGems as flawed because of it is remarkably irresponsible. What were your motives?
Dave
···
On Aug 12, 2004, at 23:31, David Ross wrote:
Heh, I didn't say I was going to do it. I was thinking
what happened with ruby-lang.org being hacked. What
really stops someone from violently attacking more
than just one computer?
On Fri, 13 Aug 2004 13:31:58 +0900, David Ross > <drossruby@yahoo.com> wrote:
<BIGSNIP/>
> Is this pretty clear now? This scenario would work
> perfectly. There is nothing to stop someone from
> attacking. Its an open security problem.
>
IIRC both the extconf.rb and the Makefiles supplied with the gem will
be run if the gem specifies it carries extensions, so there's some
potential for abuse as root.
···
On Fri, Aug 13, 2004 at 04:17:06PM +0900, Jim Weirich wrote:
At least with RubyGems, the former attach scenarios is not available for
only gem code is run during the installation. The attacker gets no
opportunity to run as root.
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
[ummm wish i could get send hooks to change my from addr]
anyone with a brain could get malicious code into
any package available on the planet, be it debian
or whatever. the fact that ruby is so dynamic only
makes this problem worse. only thing that is
really going to stop this is a correctly sandboxed
installer which uses a non-root user to compile
and run the unit tests.
even this isn't enough. but its closer at least.
root attacks are the killer and neither rpa-base
nor gem's provide easy to use non-root installs
at the moment.
ignoring the problem and hoping people will just
forgot it was ever brought up ain't gonna help.
Alex
···
On Fri, Aug 13, 2004 at 01:44:33PM +0900, Richard Kilmer wrote:
OK...so you want to bet I can write malicious Ruby code that a QA person
would not find? I mean really, QA is fine, 'this appears to work well...no
obvious flaws' but it is NOT security. It quite silly to equate the two.
That is, unless the QA team wants to _legally guarantee_ the code they are
approving...now that is quite another matter entirely
No motive. I for one don't want to run RubyGems as
root on a server which has several customers with
credit card numbers, and then get rooted just because
someone releases a really bad gem.
Also, there is limited access to who has a commit bit
to the ruby-lang cvs. We are talking about RubyForge
here. The tought did not occur to me until someone
mentioned how gems automatically get put in the
repository automatically, this is a bad thing.
···
---------------------------------
--David Ross
--Phone: 865.539.3798
--Email: drossruby [at] yahoo.com
---------------------------------
On Aug 12, 2004, at 23:31, David Ross wrote:
> Heh, I didn't say I was going to do it. I was
thinking
> what happened with ruby-lang.org being hacked.
What
> really stops someone from violently attacking more
> than just one computer?
There are a fair number of people with commit access
to ruby-lang. I,
for example, could add a trojan to the latest
version of RDoc that
would rewrite the source code to every Ruby program
it documented.
When was the last time you studied all the source
code for RDoc to
ensure it is safe?
If you want safety, then you probably shouldn't be
downloading stuff
off the web and running it, at least until it has
been verified by a
professional team of QA folks. Microsoft software,
for example, must be
secure for that reason.
OpenSource software has operated this way for years.
Taking that fact
and labeling RubyGems as flawed because of it is
remarkably
irresponsible. What were your motives?
oh come on.
stop being stupid please people.
this is just pathetic.
Alex
···
On Mon, Aug 16, 2004 at 03:11:06AM +0900, Francis Hwang wrote:
David Ross <drossruby@yahoo.com> wrote in message news:<20040813043743.2642.qmail@web21526.mail.yahoo.com>...
> People who download shouldn't have to be cautious as
> to look at the code. It should be up to someone else.
A remarkable statement, that. Life would be a lot easier if all sorts
of things were up to somebody else, but that's not how life works.
Why can't programmers be responsible for the stuff they download?
Nobody's holding a gun to your head forcing you to install a library
as root.
I can't agree with that. That's exactly how life works. Progress and civilization are based on relying on other people to do most of the work. That lets us focus on more interesting, complex, beneficial and novel problems. Technological advancement is based on automation and simplification.
The logistics of programmers having to review all or any significant amount of the code they download is overwhelming. An trust mechanism is an absolute necessity for any non-trivial software, whether distributed as a binary file or source. That trust mechanism can be informal- indeed, the ruby community provides that somewhat. You know who people are after a while, and there are enough eyes looking and information flowing to offer a certain level of security.
I already spend too much of my time sleep deprived to have to do security audits of the library code I download (rake, ruby gems itself, DBI, and so on). And, you'd have to do it for each release. Plus, you'd need a PKI identity infrastructure, cerificates, etc. as who's to say you'd find a clever trojan or virus buried in 50 000 lines of ruby code from a non-trivial library.
"People who download shouldn't have to be cautious as
to look at the code. It should be up to someone else."
To me, this is an essential truth, similar to the fact that I shouldn't have to know how an internal combustion engine works to drive a car. Simplication and abstraction- whether in technology or security- is what got us down from the trees, so to speak.
Now what is workable is another story. I'm fond of informal implicit security where possible. This list, RubyForge, and the general Ruby Zeitgeist provide a fairly good amount of comfort. I haven't worried about downloading and installing Rake or Iowa because of that. However, having an extra bit of energy in this area does seem to be a good idea.
Regards,
Nick
Francis Hwang wrote:
···
David Ross <drossruby@yahoo.com> wrote in message news:<20040813043743.2642.qmail@web21526.mail.yahoo.com>...
People who download shouldn't have to be cautious as
to look at the code. It should be up to someone else.
A remarkable statement, that. Life would be a lot easier if all sorts
of things were up to somebody else, but that's not how life works.
Why can't programmers be responsible for the stuff they download?
Nobody's holding a gun to your head forcing you to install a library
as root.
IIRC both the extconf.rb and the Makefiles supplied with the gem will
be run if the gem specifies it carries extensions, so there's some
potential for abuse as root.
I stand corrected. I forgot about extension builds.
···
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
[ummm wish i could get send hooks to change my from addr]
anyone with a brain could get malicious code into
any package available on the planet, be it debian
Right.
We can only make it a bit more difficult.
or whatever. the fact that ruby is so dynamic only
makes this problem worse. only thing that is
really going to stop this is a correctly sandboxed
installer which uses a non-root user to compile
and run the unit tests.
even this isn't enough. but its closer at least.
root attacks are the killer and neither rpa-base
nor gem's provide easy to use non-root installs
at the moment.
I believe both allow non-root installs fairly easily. Well,
RubyGems doesn't quite because the stubs are always installed in
Config::CONFIG['sitelibdir'] (so you could if you never used stubs),
but rpa-base certainly allows non-root installs, since it's the first
thing it will ask you when you install for the first time (it then asks
you for the $prefix where it should install itself + all the packages
it manages, and won't touch anything outside besides /tmp).
However, preventing direct access to root for the malicious code only
buys you time before it can leverage some local root exploit or perform
privilege escalation by sniffing all the data it can get hold of.
In other words, you cannot guarantee total security, but that doesn't
make it any less interesting an ideal goal to strive for.
I am planning to add package/port signatures soon (so that an attack
involving replacing files in the repository cannot succeed), and will
think about ways to chroot the environment managed by rpa-base.
···
On Fri, Aug 13, 2004 at 05:26:44PM +0900, Alexander Kellett wrote:
On Fri, Aug 13, 2004 at 01:44:33PM +0900, Richard Kilmer wrote:
> OK...so you want to bet I can write malicious Ruby code that a QA person
> would not find? I mean really, QA is fine, 'this appears to work well...no
> obvious flaws' but it is NOT security. It quite silly to equate the two.
You could audit some key software components, but it takes a lot of
resources.
--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
Absolutely, exactly the same as anything downloaded off the web, or off the RAA. That's why you download from places you trust, and read code if you're suspicious. RPA, Gems, RAA, or random downloads: there is _no_ difference in security. As with all open source, security comes from folks reading and using code. I'm sure that not every line of code in the RPA offerings has been studied by a team of security experts, any more than code in the RAA or Gems has. And I, for one, am not worried by that. I look to the RPA to deliver libraries that have been verified to install and work seamlessly together: RPA is a layer on top of Gems. Gems provides the raw material, and RPA produced blessed combinations of versions that the RPA team has verified to work together.
I don't understand why the rpa folks had to reinvent the packaging wheel here: the service they offer is orthogonal to Gems, and could have used Gems as the distribution mechanism.
Cheers
Dave
···
On Aug 13, 2004, at 3:09, Mauricio Fernández wrote:
On Fri, Aug 13, 2004 at 04:17:06PM +0900, Jim Weirich wrote:
At least with RubyGems, the former attach scenarios is not available for
only gem code is run during the installation. The attacker gets no
opportunity to run as root.
IIRC both the extconf.rb and the Makefiles supplied with the gem will
be run if the gem specifies it carries extensions, so there's some
potential for abuse as root.
Or do what I do, and install everything non-root... There's nothing that says everything has to go into /usr/local: I use a non-root tree (/dt/...) and install everything there. Just make sure path and LD_LIBRARY_PATH are set in your profile, and a whole lot of install worried evaporate.
Cheers
Dave
···
On Aug 13, 2004, at 3:26, Alexander Kellett wrote:
anyone with a brain could get malicious code into
any package available on the planet, be it debian
or whatever. the fact that ruby is so dynamic only
makes this problem worse. only thing that is
really going to stop this is a correctly sandboxed
installer which uses a non-root user to compile
and run the unit tests.
[ummm wish i could get send hooks to change my from addr]
anyone with a brain could get malicious code into
any package available on the planet, be it debian
or whatever. the fact that ruby is so dynamic only
makes this problem worse. only thing that is
really going to stop this is a correctly sandboxed
installer which uses a non-root user to compile
and run the unit tests.
You don't need to run as root, only if you want to install in a system-wide
repository. Actually, RubyGems runs just great installed by a user, in
their own directories, with no r00t access at all. Its all a question of
what the target user/developer wants to do.
even this isn't enough. but its closer at least.
root attacks are the killer and neither rpa-base
nor gem's provide easy to use non-root installs
at the moment.
gem install --install-dir ~/mygems fxruby
That's not too arduous
ignoring the problem and hoping people will just
forgot it was ever brought up ain't gonna help.
Alex
I don't advocate ignoring it. I advocate in NOT giving a false sense of
security.
···
On 8/13/04 4:26 AM, "Alexander Kellett" <ruby-lists@lypanov.net> wrote:
On Fri, Aug 13, 2004 at 01:44:33PM +0900, Richard Kilmer wrote:
OK...so you want to bet I can write malicious Ruby code that a QA person
would not find? I mean really, QA is fine, 'this appears to work well...no
obvious flaws' but it is NOT security. It quite silly to equate the two.
That is, unless the QA team wants to _legally guarantee_ the code they are
approving...now that is quite another matter entirely
No motive. I for one don't want to run RubyGems as
root on a server which has several customers with
credit card numbers, and then get rooted just because
someone releases a really bad gem.
Of course, but you'd be irresponsible to run _any_ open source installed as root on such a box. I hope that you don't.
Also, there is limited access to who has a commit bit
to the ruby-lang cvs. We are talking about RubyForge
here. The tought did not occur to me until someone
mentioned how gems automatically get put in the
repository automatically, this is a bad thing.
All Gems does is remove one step from downloading the library and saying "ruby install.rb" Gems isn't anything to do with your worries. The installation of open source software (any software) is inherently dangerous, and there's ultimately no solution apart from community vigilance.
I'm surprised by people here claiming to be concerned about security who have their Ruby installation in /usr/local. If you are concerned about root installs, RUBY SHOULD NOT BE IN A ROOT-ONLY WRITABLE DIRECTORY. That's just common sense (and again is nothing to do with Gems). Move your Ruby to a directory tree writable by you, and you'll no longer need to be root to install any Ruby code: Gem, RPA, or random download.
No motive. I for one don't want to run RubyGems as
root on a server which has several customers with
credit card numbers, and then get rooted just because
someone releases a really bad gem.
That's fine; just don't single RubyGems out as any more or less
dangerous than anything else you might run as root (or non-root, for
that matter, if you value your home directory) without having examined
every line of code. I fully understand that there's no point saying
this to you; I really just want to chime in with Dave and others in
the hope of decreasing the chance that anyone will take your points at
face value.
Also, there is limited access to who has a commit bit
to the ruby-lang cvs. We are talking about RubyForge
here. The tought did not occur to me until someone
mentioned how gems automatically get put in the
repository automatically, this is a bad thing.
You've been talking on IRC for weeks or months about how uniquely
insecure you think RubyGems is -- I should say, asserting that it's
insecure, rather than really talking about it -- and have never
connected it specifically with the phenomenon of gems being put in the
repository automatically. The whole thing seems to be a bit of an
idee fixe for you, without technical basis and certainly not having
originated during this thread.
---------------------------------
--David Ross
--Phone: 865.539.3798
--Email: drossruby [at] yahoo.com
Security tip: you might want to check the From header too.
David Ross <drossruby@yahoo.com> wrote in message news:<20040813043743.2642.qmail@web21526.mail.yahoo.com>...
People who download shouldn't have to be cautious as
to look at the code. It should be up to someone else.
A remarkable statement, that. Life would be a lot easier if all sorts
of things were up to somebody else, but that's not how life works.
Why can't programmers be responsible for the stuff they download?
Nobody's holding a gun to your head forcing you to install a library
as root.
Thank you, Francis. A quite sensible reply.
Yes. I might add that, the more someone tells me that I should be happy to let someone else look after my best interests, the more suspicious I become of them.
So, I'd like to thank Mr. Ross for reminding me that people who download must be cautious, and look at the code. It cannot be up to someone else.
why do we use ruby when c is a working alternative?
why choose one distribution over another? why was
rails written in the first place when other frameworks
were already around? why rewrite vim? why discuss
modifications to ruby when it already works?
rpa-base has many advantages over gems.
stifling development by making requests for
standardization this early in the game is not
gonna do ruby as a whole any good whatsoever.
Alex
···
On Fri, Aug 13, 2004 at 09:14:25PM +0900, Dave Thomas wrote:
I don't understand why the rpa folks had to reinvent the packaging
wheel here: the service they offer is orthogonal to Gems, and could
have used Gems as the distribution mechanism.
I'm surprised by people here claiming to be concerned about security
who have their Ruby installation in /usr/local. If you are concerned
about root installs, RUBY SHOULD NOT BE IN A ROOT-ONLY WRITABLE
DIRECTORY.
How do you know that /usr/local is owned by root ?
I don't understand why the rpa folks had to reinvent
the packaging
wheel here: the service they offer is orthogonal to
Gems, and could
have used Gems as the distribution mechanism.
I often have a phrase
"Don't reinvent the wheel......... Unless its not
round"
I'm sorry, but I really doubt RubyGems is round.
Rpa-base is oval shaped right now. I am hoping batsman
will get a team together to have inspections of
software. This will not eliminate all security
problems, but it will put a big dent in the security
problems. A QA team is what is needed to inspect
software to 1) make sure it works 2) give it some
security analysis at least
Heck, I never got around to packaging anything for
batsman. I was pretty scared off by what I seen in the
library "raimbo" and the bot program "raimbot". The
source code looked horrible. Style was bad, there were
not enough checks, and the guy who wrote it must have
been sick. *Actually, he was a college kiddie trying
to program* (har har, good joke) X)
I hope batsman can make rpa-base round as he can get
it.
···
----------------------------------
-- David Ross
-- Phone: 865.539.3798
-- Email: drossruby [at] yahoo.com
----------------------------------
