wake of the RoR sql injection vulnerability

92 views
Skip to first unread message

Iain Duncan

unread,
Jan 9, 2013, 11:58:32 AM1/9/13
to pylons-...@googlegroups.com
Just curious as to whether anyone has seen changes in interest in Pyramid/SQLAlchemy in the wake of the Ruby on Rails SQL injection vulnerability, or if anyone has any thoughts on it. Or worse, if it's going to tar other ORM using stacks with the same brush.

This is pure conjecture, and should be taken with a giant grain of salt, but I wonder whether the monolithic, almost closed-garden nature of the RoR ecosystem contributed to the situation compared to the situation in Python. Of course that could just be a big confirmation bias on my part. Would welcome thoughts from those more experienced than me.

iain

Chris McDonough

unread,
Jan 9, 2013, 12:14:32 PM1/9/13
to pylons-...@googlegroups.com
On Wed, 2013-01-09 at 08:58 -0800, Iain Duncan wrote:
> Just curious as to whether anyone has seen changes in interest in
> Pyramid/SQLAlchemy in the wake of the Ruby on Rails SQL injection
> vulnerability, or if anyone has any thoughts on it. Or worse, if it's
> going to tar other ORM using stacks with the same brush.

The most recent vulnerability
( https://groups.google.com/forum/?fromgroups=#!
topic/rubyonrails-security/61bkgvnSGTQ ) might allow for SQL injection
as a side effect, but it's actually much worse than just that. It
allows for arbitrary Ruby code execution on the host. Constructing a
request that did the Ruby equivalent of "os.system('rm -rf ' +
os.path.expanduser('~'))" is possible for any unpatched host, regardless
of authentication status of the request or how carefully you had written
your own application.

So I don't think you can in any way associate this with "ORM". Maybe
past critical rails bugs were related to the ORM, this one is unrelated.

> This is pure conjecture, and should be taken with a giant grain of
> salt, but I wonder whether the monolithic, almost closed-garden nature
> of the RoR ecosystem contributed to the situation compared to the
> situation in Python. Of course that could just be a big confirmation
> bias on my part. Would welcome thoughts from those more experienced
> than me.

Only the people who added the bugs can really know.

- C



Chris Calloway

unread,
Jan 9, 2013, 12:41:53 PM1/9/13
to pylons-...@googlegroups.com
On 1/9/2013 11:58 AM, Iain Duncan wrote:
> This is pure conjecture, and should be taken with a giant grain of salt,
> but I wonder whether the monolithic, almost closed-garden nature of the
> RoR ecosystem contributed to the situation compared to the situation in
> Python. Of course that could just be a big confirmation bias on my part.
> Would welcome thoughts from those more experienced than me.

Some bias as Python ecosystems have received some back-splatter from the
recent hacking of wiki.python.org. (Yeah, I know that was Moin, but
explain that to managers and check writers.) Weird coincidence that it
happened at about the same time as the RoR vulnerability exposure.

--
Sincerely,

Chris Calloway http://nccoos.org/Members/cbc
office: 3313 Venable Hall phone: (919) 599-3530
mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599

Iain Duncan

unread,
Jan 9, 2013, 1:27:39 PM1/9/13
to pylons-...@googlegroups.com
Thanks!
Iain



--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to pylons-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.


Malthe Borch

unread,
Jan 9, 2013, 2:16:40 PM1/9/13
to pylons-...@googlegroups.com
On 9 January 2013 18:14, Chris McDonough <chr...@plope.com> wrote:
> The most recent vulnerability
> ( https://groups.google.com/forum/?fromgroups=#!
> topic/rubyonrails-security/61bkgvnSGTQ ) might allow for SQL injection
> as a side effect, but it's actually much worse than just that. It
> allows for arbitrary Ruby code execution on the host. Constructing a
> request that did the Ruby equivalent of "os.system('rm -rf ' +
> os.path.expanduser('~'))" is possible for any unpatched host, regardless
> of authentication status of the request or how carefully you had written
> your own application.

Similar to the 2007 vulnerability on Plone 2.5 / 3.0:

http://plone.org/products/plone/security/advisories/cve-2007-5741

Interpreted languages ...

\malthe

Wyatt Baldwin

unread,
Jan 9, 2013, 11:31:12 PM1/9/13
to pylons-...@googlegroups.com

What does this have to do with interpreted languages? Can't this type of thing happen with any language? Seems like it has more to do with the framework rather than compiled vs interpreted or static vs dynamic.

Some related HN discussion: http://news.ycombinator.com/item?id=5029296

Malthe Borch

unread,
Jan 10, 2013, 3:49:35 AM1/10/13
to pylons-...@googlegroups.com
On 10 January 2013 05:31, Wyatt Baldwin <wyatt.le...@gmail.com> wrote:
> What does this have to do with interpreted languages? Can't this type of
> thing happen with any language? Seems like it has more to do with the
> framework rather than compiled vs interpreted or static vs dynamic.

It can happen with any language, but it happens more often with an
interpreted language, probably because it's arguably easier to pull it
off (if by mistake).

\malthe
Reply all
Reply to author
Forward
0 new messages