In order to cross platform, Ruby is designed to be interpreted inruntime, so Ruby code is exposed on

[Erwin Moller]

How about PHP? I think the same problem with PHP.

 

[Phillip Gawlowski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Erwin Moller wrote:
| How about PHP? I think the same problem with PHP.

1) http://jerz.setonhill.edu/writing/e-text/e-mail.htm

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgf7AAACgkQbtAgaoJTgL+AKgCeISaCwulfmDxDM9lvMUhZAYr4
WHkAn1iIXm4toAYMfwnEzhSycRJPyZO+
=gLof
-----END PGP SIGNATURE-----

 

[Phillip Gawlowski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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: http://en.wikipedia.org/wiki/Security_through_obscurity
|
| 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.

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkghVgkACgkQbtAgaoJTgL9GKQCeN4sQIEr3Vv0JgVIc4eKtWbCe
j+4An1KLZp9AL0Ir7I/r7hKqttsebTax
=SbBk
-----END PGP SIGNATURE-----

 

[Clifford Heath]

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

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.

 

[Robert Dober]

In short: Ruby makes the defense as shallow as Perl or Python.

or a C compiler for that matter
R.

 

[Eivind Eklund]

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.

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.

 

[Marc Heiler]

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.

 

[Phillip Gawlowski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgi+vwACgkQbtAgaoJTgL/ELACgjWvgi1hsZBwSs9tuMhWbiUxo
FZoAniqDmr1A1v8c/B7ByyWobd09uGO6
=6NP3
-----END PGP SIGNATURE-----

 

[Clifford Heath]

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.

 

[Clifford Heath]

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 .