How about PHP? I think the same problem with PHP.
Erwin Moller wrote:
How about PHP? I think the same problem with PHP.
1) Email Tips: Top 10 Strategies for Writing Effective Email -- Jerz's Literacy Weblog (est. 1999)
2) If the security of your application hinges on somebody not getting
the source code, your application wasn't written properly.
See also: http://en.wikipedia.org/wiki/Security_through_obscurity
- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com
Youth is a period of missed opportunities without the glory of knowing what
~ was missed.
~ -- Cyril Connolly, "Journal and Memoir" 1983
Phillip Gawlowski wrote:
2) If the security of your application hinges on somebody not getting
the source code, your application wasn't written properly.
See also: Security through obscurity - Wikipedia
Not intending to feed the original troll, but your answer is only
partly correct. Ruby injection is likely easier and more powerful
than object-code injection onto a system that has no compiler. That's
why many sensitive production systems allow no development tools to
be installed. It's called "defense in depth". IMO Ruby does make the
defense shallower... but not too shallow.
Erwin: if it's not acceptable to you, then don't use it.
But don't bother complaining here, because it's not likely to change.
Clifford Heath wrote:
Phillip Gawlowski wrote:
2) If the security of your application hinges on somebody not getting
the source code, your application wasn't written properly.
See also: Security through obscurity - WikipediaNot intending to feed the original troll, but your answer is only
partly correct. Ruby injection is likely easier and more powerful
than object-code injection onto a system that has no compiler. That's
why many sensitive production systems allow no development tools to
be installed. It's called "defense in depth". IMO Ruby does make the
defense shallower... but not too shallow.
If I'm able to read source code in a, hopefully, protected directory,
I'm not going to bother with code injection.
I'd be doing something like
$ passwd
Type the new password for root:
If I have physical access to the machine or access to the programs
installed there, I'm going to hunt for known issues and exploit those
(ala Metasploit).
Also: How has introduced an issue that wasn't there already with, say,
Perl, Tcl, or PHP (go through a list of PHP functions that you should
close *at least* one of those days. Fun)?
Or with a hexeditor. Heck, download one from someplace, if you are able
to see the sources of a Ruby app.
There's security, and then there's security theater.
Ah production server should only run what's needed, anyway. That is the
main reason not to have dev tools running on them (though, have fun
trying to remove all text editors on a *NIX machine, and the Shell which
probably is Turing complete): Reducing the exposed surface area.
In short: Ruby makes the defense as shallow as Perl or Python.
- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com
~ - You know you've been hacking too long when...
...you hear your alarm, but can't seem to get fully awake until you
successfully page your left arm back in from swap space.
or a C compiler for that matter
R.
···
On Wed, May 7, 2008 at 9:11 AM, Phillip Gawlowski <cmdjackryan@googlemail.com> wrote:
In short: Ruby makes the defense as shallow as Perl or Python.
--
http://ruby-smalltalk.blogspot.com/
---
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein
I agree with reducing exposed attack surface. I have a different way
of thinking about what constitute attack surface, though: I think in
terms of available security capabilities.
In terms of this, a compiler is equivalent to a file write to a file
where you can set the x (execute) bit, plus a few megabytes of
diskspace. Unless you restrict these, compiler access is a VERY minor
hurdle.
So - consider it against convenience. I'd rather have my production
machines easy to deal with for me (which makes it more likely that I
maintain them in a way that block attacks) than adding such a minor
hurdle for attackers. I'll add other, major hurdles instead, like
putting a non-breakable chroot around processes that are
network-accessible and could likely contain flaws.
Eivind.
···
On Wed, May 7, 2008 at 9:11 AM, Phillip Gawlowski <cmdjackryan@googlemail.com> wrote:
There's security, and then there's security theater.
Ah production server should only run what's needed, anyway. That is the
main reason not to have dev tools running on them (though, have fun
trying to remove all text editors on a *NIX machine, and the Shell which
probably is Turing complete): Reducing the exposed surface area.
Phillip Gawlowski wrote:
...
A lot of stuff that completely failed to address my comment, which was
about code injection, not about someone stealing your source code.
If I'm able to read source code in a, hopefully, protected directory,
I'm not going to bother with code injection.
Completely disagree there. As soon as I see that mongrel's running,
I have a plan of attack.
I'd be doing something like
$ passwd
Type the new password for root:
If you already have shell access, yes. But security's already broken
then.
Also: How has introduced an issue that wasn't there already with, say,
Perl, Tcl, or PHP (go through a list of PHP functions that you should
close *at least* one of those days. Fun)?
It hasn't. It's introduced different versions of the same thing,
but all of these are easier than the equivalent attacks on object
code.
My code ran NASDAQ and a number of banks' Internet services for over a
decade. I was a contributor to OpenSSL years before it had that name.
I also did the first open source CA server, long before openca or openid.
I have a little experience with this stuff, even if it's not what I care
for any more.
Or with a hexeditor. Heck, download one from someplace, if you are able
to see the sources of a Ruby app.
If you have the app to begin with. If you only have a web interface,
you don't have the app yet. You need to inject code to get it, or to
do worse.
In short: Ruby makes the defense as shallow as Perl or Python.
Agree. But that's shallower than an object-code only system.
I'd rather have my production machines easy to deal with for me
(which makes it more likely that I maintain them in a way
that block attacks) than adding such a minor hurdle for attackers.
Totally agree with you. 
···
--
Posted via http://www.ruby-forum.com/\.
Clifford Heath wrote:
Phillip Gawlowski wrote:
If I'm able to read source code in a, hopefully, protected directory,
I'm not going to bother with code injection.Completely disagree there. As soon as I see that mongrel's running,
I have a plan of attack.
Sorry, I mis-read. I agree with this one. I thought you said you
wouldn't bother with injection *unless* you could read the code :-).
Clifford Heath wrote:
If I'm able to read source code in a, hopefully, protected directory,
I'm not going to bother with code injection.Completely disagree there. As soon as I see that mongrel's running,
I have a plan of attack.
Well, of course. But to exploit something, it has to be exposed first.
And once something is exposed, almost all bets are off. Sanitize your
input from injection attacks, make sure CSRF and XSS won't hurt you, and
keep your server (for lack of a better term for an exposed service) up
to date on security patches, too.
However, if an attacker doesn't see the source because it is compiled it
object code/ byte code, or because the server only emits HTML, the
barrier to exploiting the system is about the same.
I'd be doing something like
$ passwd
Type the new password for root:If you already have shell access, yes. But security's already broken
then.
Yeah, but to read the sources of a Merb, Rails, or Ruby-CGI application,
I'll have to have shell access already (unless, of course, I hand over
my source code, and neglected to code software safe in the first place).
In that, it doesn't differ from running IIS or Apache, PHP or Perl. All
these packages have to be written safe, sane, and secure. That IIS and
Apache are compiled to object code is, in this regard, an implementation
detail.
It hasn't. It's introduced different versions of the same thing,
but all of these are easier than the equivalent attacks on object
code.
Object code adds one step to the process: Disassemble the binary.
No language is inherently secure or insecure, be it interpreted or
compiled. It's the coding that is secure or insecure.
(I currently work on a Rails app that I wouldn't dare putting online,
since there is next to no input sanitation (?) of input going on.
Or with a hexeditor. Heck, download one from someplace, if you are able
to see the sources of a Ruby app.If you have the app to begin with. If you only have a web interface,
you don't have the app yet. You need to inject code to get it, or to
do worse.
Of course. But you always have to sanitize input. No matter how the end
product is run. The attack vector more depends on what the application
does, rather on what the application is written in.
In short: Ruby makes the defense as shallow as Perl or Python.
Agree. But that's shallower than an object-code only system.
By half an inch, maybe. And it is easier to write a secure application,
IMO, if there is no need to hunt down corrupted pointers, too. 
- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com
~ I'm just very selective about the reality I choose to accept.
~ --- Calvin