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

Discussion in 'Ruby' started by Erwin Moller, May 6, 2008.

  1. Erwin Moller

    Erwin Moller Guest

    How about PHP? I think the same problem with PHP.
    Erwin Moller, May 6, 2008
    #1
    1. Advertising

  2. Re: In order to cross platform, Ruby is designed to be interpreted in runtime, so Ruby code is exposed on the server. This brings a security danger which is not acceptable.

    -----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, May 6, 2008
    #2
    1. Advertising

  3. Re: In order to cross platform, Ruby is designed to be interpreted in runtime, so Ruby code is exposed on the server. This brings a security danger which is not acceptable.

    -----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-----
    Phillip Gawlowski, May 7, 2008
    #3
  4. Re: In order to cross platform, Ruby is designed to be interpretedin runtime, so Ruby code is exposed on the server. This brings a securitydanger which is not acceptable.

    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.

    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, May 7, 2008
    #4
  5. Erwin Moller

    Robert Dober Guest

    Re: In order to cross platform, Ruby is designed to be interpreted in runtime, so Ruby code is exposed on the server. This brings a security danger which is not acceptable.

    On Wed, May 7, 2008 at 9:11 AM, Phillip Gawlowski
    <> wrote:

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

    or a C compiler for that matter
    R.
    --
    http://ruby-smalltalk.blogspot.com/

    ---
    Whereof one cannot speak, thereof one must be silent.
    Ludwig Wittgenstein
    Robert Dober, May 8, 2008
    #5
  6. Re: In order to cross platform, Ruby is designed to be interpreted in runtime, so Ruby code is exposed on the server. This brings a security danger which is not acceptable.

    On Wed, May 7, 2008 at 9:11 AM, Phillip Gawlowski
    <> 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.


    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.
    Eivind Eklund, May 8, 2008
    #6
  7. Erwin Moller

    Marc Heiler Guest

    Re: In order to cross platform, Ruby is designed to be interpreted in runtime, so Ruby code is expos

    > 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/.
    Marc Heiler, May 8, 2008
    #7
  8. Re: In order to cross platform, Ruby is designed to be interpreted in runtime, so Ruby code is exposed on the server. This brings a security danger which is not acceptable.

    -----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-----
    Phillip Gawlowski, May 8, 2008
    #8
  9. Re: In order to cross platform, Ruby is designed to be interpretedin runtime, so Ruby code is exposed on the server. This brings a securitydanger which is not acceptable.

    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, May 8, 2008
    #9
  10. Re: In order to cross platform, Ruby is designed to be interpretedin runtime, so Ruby code is exposed on the server. This brings a securitydanger which is not acceptable.

    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, May 8, 2008
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Otto Wyss
    Replies:
    5
    Views:
    419
    Robert Vazan
    Sep 7, 2003
  2. lvirden
    Replies:
    10
    Views:
    564
    lvirden
    Jul 30, 2007
  3. an an
    Replies:
    0
    Views:
    84
    an an
    Feb 19, 2008
  4. Replies:
    8
    Views:
    112
    Jim Ley
    May 15, 2005
  5. abhijeet.kumar
    Replies:
    0
    Views:
    511
    abhijeet.kumar
    Nov 8, 2012
Loading...

Share This Page