Rails - Aug 2006 - On the total nondisclosure of the 8/9/06 security vulnerability

Dear Rails team,

The handling of the recent vulnerability in Rails has proven somewhat 
problematic for us. We have recently adopted Rails as our web platform 
of choice; previously, we used J2EE. We love Rails. We hate J2EE. We 
don''t want to go back. It took a lot of effort and convincing to get
the
management teams of our various projects to sign off on the use of 
Rails. The nondisclosure policy in handling this vulnerability has 
seriously jeopardized our (and many other people''s) ability to use
Rails
in a commercial environment, so we would like to suggest that it be changed.

The core issue is that releasing a patch to fix a critical security 
vulnerability without telling anyone what the vulnerability is does very 
little good as a knowledgeable cracker can just SVN diff the new version 
with the old one and peruse that patch to have an exploit ready to go. 
(The 1.1.4 to 1.1.5 patch is under 2,000 lines, not even that long.) It 
only takes one person to do that and release it onto the net. Then, 
thousands of script kiddies will have the exploit within minutes. I am 
sure that, even as I type this, the 0-day exploit rooms on IRC are 
buzzing with prepackaged copies of exploit code for the Rails bug. Not 
disclosing the vulnerability does very little to keep the information 
out of the hands of malicious hackers; it only harms legitimate users.

As a system administrator, how can I know whether my systems have 
already been compromised when I don''t even know the general nature of 
the vulnerability? I''m not suggesting that specific exploit code ought 
to be posted, but we do need to know, at least generally, what is going 
on in order to be able to effectively deal with it.

As a business, if I don''t have any clue what the problem is, I
can''t
reassure my customers that their data has been safe, because I don''t 
know. I have to spend resources to diff the new code with the old code 
and find out exactly what the problem was, needlessly duplicating work 
that dozens or hundreds of other people and companies (and crackers) are 
simultaneously performing around the world, because of the decision to 
withhold that information. Only then can I check to see whether the 
exploit has been used on my system, potentially hours later.

Further, though the authors promise that the exploit is fixed in 1.1.5, 
how can I be sure of that if I don''t even know what the exploit was? 
Nobody is perfect. Everyone makes mistakes from time to time. If, by 
some chance, there was a mistake in the fix in 1.1.5 (or perhaps the fix 
opened up some other problem), it becomes that much harder for the 
legitimate user community to catch and solve the problem. All bugs are 
shallow to many eyes. But nobody will even discuss the original exploit 
(except crackers amongst themselves), so how can we possibly audit the 
fix? Even if, several days later, the details of the original exploit 
are released, that''s several days that our public, Internet-facing 
systems were sitting vulnerable to problems that the crackers surely 
knew about; the problem could have been fixed in minutes if the whole 
Rails developer community was looking at it.

Sun and the big J2EE app server vendors send out glossy brochures and 
sales teams to wine and dine their customers. The glossy brochures and 
the multibillion dollar brand name stamped onto the product give 
managers a warm, fuzzy feeling. It makes them feel safe, because 
(theoretically) they have someone to sue if things go wrong. Rails 
doesn''t have that. Rails is produced by a decentralized team of people 
on the Internet. While we, as technical people, recognize the technical 
benefits of Rails over something like J2EE, it took a whole lot of 
convincing to get the non-technical management people to forget about 
the Sun cheerleaders and sign off on Rails for their expensive new projects.

If our customers do not feel that their data is secure on our hosts, 
they will not host with us. Since that is how we make our livings, this 
becomes a big problem for us. The melodramatic "the sky is falling, 
UPGRADE NOW NOW NOW" tone of the 1.1.5 announcement did not help, 
either. If a customer reads this announcement, the customer will call us 
up to ask what is going on. What are we supposed to tell him -- "Uh.. I 
don''t know, the actual problem is secret, so we can''t really
tell you
whether your data has been compromised, but some guys on the Internet 
assure us that the issue is fixed now."?? We would be back on J2EE 
within the week if we do that, if we still had customers at all.

I therefore propose that full (or at least partial) disclosure be 
adopted as standard policy for future Rails vulnerabilities. Doing so 
will not give the cracking community any information that they wouldn''t
have in 30 minutes or an hour anyway -- information that the legitimate 
user community is denied for days, thus granting an advantage to the 
malicious crackers. What it will do is allow Rails to exist as a 
competitive, viable platform for commercial web development, and it will 
allow system administrators to maintain the integrity of their systems 
and their data.

I close with a quote I found at 
http://en.wikipedia.org/wiki/Full_disclosure :


     A commercial, and in some respects a social doubt has been started 
within the last year or two, whether it is right to discuss so openly 
the security or insecurity of locks. Many well-meaning persons suppose 
that the discussion respecting the means for baffling the supposed 
safety of locks offers a premium for dishonesty, by showing others how 
to be dishonest. This is a fallacy. Rogues are very keen in their 
profession, and know already much more than we can teach them respecting 
their several kinds of roguery.

     Rogues knew a good deal about lock-picking long before locksmiths 
discussed it among themselves, as they have lately done. If a lock, let 
it have been made in whatever country, or by whatever maker, is not so 
inviolable as it has hitherto been deemed to be, surely it is to the 
interest of honest persons to know this fact, because the dishonest are 
tolerably certain to apply the knowledge practically; and the spread of 
the knowledge is necessary to give fair play to those who might suffer 
by ignorance.

         -- From A. C. Hobbs (Charles Tomlinson, ed.), Locks and Safes: 
The Construction of Locks. Published by Virtue & Co., London, 1853 
(revised 1868).



-- 

--------------------------------------------------
--    Paul Legato, Senior Software Engineer     --
---       Networked Knowledge Systems          ---
----   P.O. Box 20772 Tampa, FL. 33622-0772   ----
----- (813)594-0064 Voice  (813)594-0045 FAX -----
------           plegato@nks.net            ------
--------------------------------------------------

--------------------------------------------------
-----   This email bound by the following:   -----
---- http://www.nks.net/email_disclaimer.html ----
--------------------------------------------------

Paul Legato wrote:
> Dear Rails team,
> 
> The handling of the recent vulnerability in Rails has proven somewhat
> problematic for us. We have recently adopted Rails as our web platform
> of choice; previously, we used J2EE. We love Rails. We hate J2EE. We
> don''t want to go back. It took a lot of effort and convincing to
get the
You make some good points and have valid concerns.  However, the fact 
remains that Rails is a very new framework and prone to security issues. 
The developers aren''t perfect like any of us.  Lets give credit though 
on how fast they fixed the issue.  I''m sure they dropped what they were
doing to get a patch out and I applaud them for that.


-- 
Posted via http://www.ruby-forum.com/.

We know absolutely nothing about how the vulnerability came to the 
attention of the Rails team. Looking back at the recent history of 
discovered vulnerabilities in closed-source ommercial products, roughly 
the following has been the case:

"White hats" (whatever their motivations) often discover
vulnerabilities
and bring them quietly to the attention of the affected vendors. At this 
point several responses by the vendor are possible (and all of them have 
been observed): 1) they can patch the problem, release the patch, and 
then come fully clean (including exploit details) once the patch is 
available; 2) they can quietly release a patch and hope no one catches 
on that there was a problem, or 3) they can decide to do nothing and 
hope (or pressure) the exploit discoverers to keep quiet while they 
continue to "work on it." In any case, closed-source processes are
such
that it can take days or weeks to produce a patch.

The incredible but true fact is that companies like Microsoft, Sun, 
Cisco, and others that often face this situation don''t face a lot of 
real risk from not patching their problems. The opprobrium that 
Microsoft right gets for their less-than-strict approach to security 
vulnerabilities doesn''t keep enough people from buying their products 
for them to apply more than Chairman and CEO-level lip service to the 
problem.

What has happened several times is that the reporters of a problem felt 
strongly enough about an unpatched vulnerability that they went public 
with the information. This decidedly antisocial behavior does have the 
effect of forcing the vendor''s hand, but it also makes everyone scared 
as heck for the nontrivial amount of time it takes for a vendor to 
release a patch.

But with open source software, we expect well-audited patches to new 
vulnerabilities to be released within hours of discovery. So the pattern 
of keeping quiet until the patch is available is not necessarily a bad 
one because the time is so short. But it''s essential to give some 
indication of the nature of the problem in the initial advisory! 
Otherwise no one has any way to judge their vulnerability. Applying a 
patch to a large number of servers is not something that can be done 
instantaneously, especially since it completely invalidates all your 
unit and regression testing. That means there is a significant-sized 
window of time during which a sysadmin must be able to make an 
intelligent decision whether to shut down or not.

We knew Rails is a relatively immature technology. What we have just 
discovered is that the Rails team is a relatively immature team. They 
will learn from this and get better, and/or they will partner with 
people who know better. We know they tried to reduce the level of 
problems by inhibiting the flow of information to the bad guys. But as 
many have pointed out, that doesn''t slow the bad guys down at all, 
especially when the source is open. If anything, the team should have 
given a description of the vulnerability and postponed full technical 
details for 24 hours to give people time to patch.

-- 
Posted via http://www.ruby-forum.com/.

Hm, there seem to be already proof-of-concept exploit
(found on ror2ru group: 
http://groups.google.com/group/ror2ru/browse_thread/thread/e654a6ddedc29e7e/7b90204e50bd7974
)
Short summary of claims:
vulnerability is related to very-very automagic in routing code.

E.g. for Rails 1.1.4 url like http://127.0.0.1:3000/breakpoint_client 
can easily take down your server to ever-waiting state (my app has gone 
there, when I tried).

And for Rails 1.1.5 (you say, it is fixed?) http://127.0.0.1:3000/cgi 
brings down routing totally.

Are these the only affected by "security patch" places, or we should 
expect more unknown, so-called "fixed" bugs???

Damn!
I just don''t get for what reason DHH didn''t explain
vulnerability (uhm,
it would be an interesting story on how it was found, analyzed and 
resolved).

It was a question of several hours to find and publish exploit, so who 
is really protected by that "opionated obscurity"?
Where is test code for that "patch"?
And there was already a ticket "#5408 Unhandled urls can cause loading 
of arbitrary ruby files" on Rails TRAC from 06/16 about mentioned 
issues...

And, maybe I''m wrong and that is not that security breach
"patched" in
1.1.5? How can I know? David Heinemeier Hansson, please, tell us, 
obscurity is not a way to go.

-- 
Posted via http://www.ruby-forum.com/.

dseverin wrote:
> And for Rails 1.1.5 (you say, it is fixed?) http://127.0.0.1:3000/cgi 
> brings down routing totally.
> 
One more for 1.1.5:
Two subsequent calls:

http://127.0.0.1:3000/builder/blankslate
http://127.0.0.1:3000/active_support/dependencies

put server to errors "SystemStackError (stack level too deep)" 
constantly for all further requests.

Nope, guys, the routing problems aren''t fully fixed, and one still can 
require about 500 .rb files from standard Rails vendor/* directories 
just typing some text as URL in browser.

I don''t know yet how to fight it... :(
What configuration could anyone suggest to *really* secure my 
applications?

-- 
Posted via http://www.ruby-forum.com/.

dseverin wrote:
> I don''t know yet how to fight it... :(
> What configuration could anyone suggest to *really* secure my 
> applications?
You could always setup a catch-all as your last route:
   map.connect ''*url'', :controller =>
''my_controller'', :action=>"unhandled"
and while you''re at it, implement a decent 404-handler that logs the
hits and
offers "smart" alternatives instead of a dummy 404 page ;-)

Daniel

dseverin wrote:
> dseverin wrote:
>> And for Rails 1.1.5 (you say, it is fixed?) http://127.0.0.1:3000/cgi 
>> brings down routing totally.
>> 
> 
> One more for 1.1.5:
> Two subsequent calls:
> 
> http://127.0.0.1:3000/builder/blankslate
> http://127.0.0.1:3000/active_support/dependencies
> 
> put server to errors "SystemStackError (stack level too deep)" 
> constantly for all further requests.
I''m running 1.1.5 and using those links I don''t get any
crashes.  I do
get routing errors, but no crashes.

Routing Error
Recognition failed for "/builder/blankslate"

Routing Error
Recognition failed for "/active_support/dependencies"

-- 
Posted via http://www.ruby-forum.com/.

On winxp using webrick, things don''t look good... Still breakable..

1) http://127.0.0.1:3000/builder/blankslate
Routing Error
Recognition failed for "/builder/blankslate"

2) http://127.0.0.1:3000/active_support/dependencies
SystemStackError
stack level too deep
RAILS_ROOT: ./script/../config/..

Application Trace | Framework Trace | Full Trace
F:/Programs/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/vendor/builder/blankslate.rb:48:in
`blank_slate_method_added''
F:/Programs/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/vendor/builder/blankslate.rb:48:in
`blank_slate_method_added''
F:/Programs/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/vendor/builder/blankslate.rb:48:in
`method_added''
F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4/lib/action_controller/routing.rb:688:in
`define_hash_access_method''
F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4/lib/action_controller/routing.rb:694:in
`name_route''
F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4/lib/action_controller/routing.rb:650:in
`named_route''
F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4/lib/action_controller/routing.rb:655:in
`method_missing''
#{RAILS_ROOT}/config/routes.rb:16
#{RAILS_ROOT}/config/routes.rb:1
-e:4


3) Any url:
SystemStackError
stack level too deep
RAILS_ROOT: ./script/../config/..

Application Trace | Framework Trace | Full Trace
F:/Programs/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/vendor/builder/blankslate.rb:48:in
`blank_slate_method_added''
F:/Programs/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/vendor/builder/blankslate.rb:48:in
`blank_slate_method_added''
F:/Programs/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/vendor/builder/blankslate.rb:48:in
`method_added''
F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4/lib/action_controller/routing.rb:688:in
`define_hash_access_method''
F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4/lib/action_controller/routing.rb:694:in
`name_route''
F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4/lib/action_controller/routing.rb:650:in
`named_route''
F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4/lib/action_controller/routing.rb:655:in
`method_missing''
#{RAILS_ROOT}/config/routes.rb:16
#{RAILS_ROOT}/config/routes.rb:1
-e:4

-- 
Posted via http://www.ruby-forum.com/.

Running with webrick in development mode both /cgi and those 2 requests 
generate errors on all subsequent requests.

for the .cgi one:

.../ruby/lib/ruby/1.8/cgi.rb:773
...
action_controller/routing.rb:289:in `attempt_load''

routing.rb:
 safe_load_paths.each do |load_path|
   full_path = File.join(load_path, path)
   file_path = full_path + ''.rb''
   if File.file?(file_path) # Found a .rb file? Load it up
              require_dependency(file_path)

printing ''safe_load_paths'' in attempt_load gives me all the
dirs from my
app, rails, and some ruby library dirs(!). Also the path variable is 
''cgi''.
So it just traverses all lib directories and loads the first file names 
cgi.rb, even if it''s in a ruby or rails library dir.

with safe_load_paths being defined as:

def safe_load_paths #:nodoc:
  if defined?(RAILS_ROOT)
    $LOAD_PATH.select do |base|
      base = File.expand_path(base)
      extended_root = File.expand_path(RAILS_ROOT)
      base.match(/\A#{Regexp.escape(extended_root)}\/*#{file_kinds(:lib) 
* ''|''}/) || base =~ %r{rails-[\d.]+/builtin}
    end
    ...

where File.expand_path(RAILS_ROOT) is my application dir.

This:
base.match(/\A#{Regexp.escape(extended_root)}\/*#{file_kinds(:lib) * 
''|''}/)
seems to match too much, some debugging output shows that 
file_kinds(:lib) * ''|'' returns ''app|lib''

so this is base.match(/\A/path/to/your_app/\/*app|lib/)
with no parenthesis around app|lib !
So any dir matching ''lib'' is included.

Fix:
actionpack-1.12.4\lib\action_controller\routing.rb: 276
CHANGE
base.match(/\A#{Regexp.escape(extended_root)}\/*#{file_kinds(:lib) * 
''|''}/) || base =~ %r{rails-[\d.]+/builtin}
TO
base.match(/\A#{Regexp.escape(extended_root)}\/*(?:#{file_kinds(:lib) * 
''|''})/) || base =~ %r{rails-[\d.]+/builtin}


Vulnerability fixed :)

...and I haven''t even finished my first rails app yet ;)

-- 
Posted via http://www.ruby-forum.com/.

The rails team is trying to contain damage. The fix works on everything
except for webrick. Give them some time. No one can be in production 
with
webrick..

colin wrote:
> On winxp using webrick, things don''t look good... Still
breakable..
> 
-- 
Posted via http://www.ruby-forum.com/.

John Royal wrote:
> dseverin wrote:
>> dseverin wrote:
>>> And for Rails 1.1.5 (you say, it is fixed?)
http://127.0.0.1:3000/cgi
>>> brings down routing totally.
>>> 
>> 
>> One more for 1.1.5:
>> Two subsequent calls:
>> 
>> http://127.0.0.1:3000/builder/blankslate
>> http://127.0.0.1:3000/active_support/dependencies
>> 
>> put server to errors "SystemStackError (stack level too
deep)"
>> constantly for all further requests.
> 
> I''m running 1.1.5 and using those links I don''t get any
crashes.  I do
> get routing errors, but no crashes.
> 
> Routing Error
> Recognition failed for "/builder/blankslate"
> 
> Routing Error
> Recognition failed for "/active_support/dependencies"
Same here. I''ve just tested a local webrick though, maybe a different 
config in production mode will act differently...

Jeroen


-- 
Posted via http://www.ruby-forum.com/.

s1lence wrote:
> The rails team is trying to contain damage. The fix works on everything
> except for webrick. Give them some time. No one can be in production 
> with
> webrick..
I have no crashes using these techniques under WebBrick on WinXP.


-- 
Posted via http://www.ruby-forum.com/.

Paul Legato wrote:
> little good as a knowledgeable cracker can just SVN diff the new version
> with the old one and peruse that patch to have an exploit ready to go.
Then, Paul Legato wrote:
> As a system administrator, how can I know whether my systems have
> already been compromised when I don''t even know the general nature
of
> the vulnerability? I''m not suggesting that specific exploit code
ought

Uhhh, am I missing something? You describe exactly how to figure out 
what the problem and its solution are and then you say you have no way 
to figure it out. All software has bugs, including security issues. Deal 
with it.

-- 
Posted via http://www.ruby-forum.com/.

dseverin wrote:
> E.g. for Rails 1.1.4 url like http://127.0.0.1:3000/breakpoint_client 
> can easily take down your server to ever-waiting state (my app has gone 
> there, when I tried).
This url takes down my server, running 1.1.5 and mongrel

-- 
Posted via http://www.ruby-forum.com/.

Mongrel on Windos using 1.1.5 still causes the error to occur for us as
well.

<http://127.0.0.1:3000/active_support/dependencies>

On 8/10/06, colin <Colin@no.no> wrote:
>
> On winxp using webrick, things don''t look good... Still
breakable..
>
> 1) http://127.0.0.1:3000/builder/blankslate
> Routing Error
> Recognition failed for "/builder/blankslate"
>
> 2) http://127.0.0.1:3000/active_support/dependencies
> SystemStackError
> stack level too deep
> RAILS_ROOT: ./script/../config/..
>
> Application Trace | Framework Trace | Full Trace
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1
> /lib/active_support/vendor/builder/blankslate.rb:48:in
> `blank_slate_method_added''
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1
> /lib/active_support/vendor/builder/blankslate.rb:48:in
> `blank_slate_method_added''
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1
> /lib/active_support/vendor/builder/blankslate.rb:48:in
> `method_added''
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4
> /lib/action_controller/routing.rb:688:in
> `define_hash_access_method''
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4
> /lib/action_controller/routing.rb:694:in
> `name_route''
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4
> /lib/action_controller/routing.rb:650:in
> `named_route''
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4
> /lib/action_controller/routing.rb:655:in
> `method_missing''
> #{RAILS_ROOT}/config/routes.rb:16
> #{RAILS_ROOT}/config/routes.rb:1
> -e:4
>
>
> 3) Any url:
> SystemStackError
> stack level too deep
> RAILS_ROOT: ./script/../config/..
>
> Application Trace | Framework Trace | Full Trace
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1
> /lib/active_support/vendor/builder/blankslate.rb:48:in
> `blank_slate_method_added''
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1
> /lib/active_support/vendor/builder/blankslate.rb:48:in
> `blank_slate_method_added''
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/activesupport-1.3.1
> /lib/active_support/vendor/builder/blankslate.rb:48:in
> `method_added''
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4
> /lib/action_controller/routing.rb:688:in
> `define_hash_access_method''
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4
> /lib/action_controller/routing.rb:694:in
> `name_route''
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4
> /lib/action_controller/routing.rb:650:in
> `named_route''
> F:/Programs/ruby/lib/ruby/gems/1.8/gems/actionpack-1.12.4
> /lib/action_controller/routing.rb:655:in
> `method_missing''
> #{RAILS_ROOT}/config/routes.rb:16
> #{RAILS_ROOT}/config/routes.rb:1
> -e:4
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060810/f6ad90b9/attachment.html

On Aug 10, 2006, at 10:44 AM, David Morton wrote:
> dseverin wrote:
>> E.g. for Rails 1.1.4 url like http://127.0.0.1:3000/breakpoint_client
>> can easily take down your server to ever-waiting state (my app has  
>> gone
>> there, when I tried).
>
> This url takes down my server, running 1.1.5 and mongrel
Sadly on my production xserve running Apache mod_proxy to lighttpd,  
the url:

/breakpoint_client

will hang that process indefinitely. We''re running with max-procs at  
3. I haven''t tested (nor do I really want to on my production server)  
to see if I can get all three processes to hang.

Repeatedly hammering this same server with combinations of the paths:

/cgi
/active_support/dependencies
- and -
/builder/blankslate

brings it to a deadlock.  I''m assuming this is the same essential  
issue as above. I wouldn''t know for sure though, because the server  
stops writing to the log at some point during this process. ugh.

...and I thought I was in the clear after doing the upgrade to 1.1.5  
yesterday :(

- Stephen

> I don''t know yet how to fight it... :(
> What configuration could anyone suggest to *really* secure my 
> applications?
I already had a line of code at the end of my routes to catch the entire 
URL of an umatched route and dump it into an array for further 
processing. Whenever I try those links (running Lighttpd locally with 
FastCGI) I get routing errors but no stack problems.

The line at the end of my routes.rb is:

map.with_options(:controller => ''public/pages'') do |public|
<snip>
public.connect ''*url'', :action => ''index''
end

-- 
Posted via http://www.ruby-forum.com/.

David Morton wrote:
> dseverin wrote:
>> E.g. for Rails 1.1.4 url like http://127.0.0.1:3000/breakpoint_client 
>> can easily take down your server to ever-waiting state (my app has gone
>> there, when I tried).
> 
> This url takes down my server, running 1.1.5 and mongrel

Problem also exists with Webrick, and IIRC, the default config on my dev 
machine is lighttpd. So this is a problem inside the Rails code.

Is that the same security flaw, or another one entirely?

-- 
Posted via http://www.ruby-forum.com/.

Your fix

base.match(/\A#{Regexp.escape(extended_root)}\/*(?:#{file_kinds(:lib)
*''|''})/) || base =~ %r{rails-[\d.]+/builtin}

 works for us here for both Mongrel and WEBrick.

Thanks for the solution. If the dev site were up I''d say submit it as a
patch. :)




On 8/10/06, Sander Land <sander.land@gmail.com>
wrote:
>
> Running with webrick in development mode both /cgi and those 2 requests
> generate errors on all subsequent requests.
>
> for the .cgi one:
>
> .../ruby/lib/ruby/1.8/cgi.rb:773
> ...
> action_controller/routing.rb:289:in `attempt_load''
>
> routing.rb:
> safe_load_paths.each do |load_path|
>    full_path = File.join(load_path, path)
>    file_path = full_path + ''.rb''
>    if File.file?(file_path) # Found a .rb file? Load it up
>               require_dependency(file_path)
>
> printing ''safe_load_paths'' in attempt_load gives me all
the dirs from my
> app, rails, and some ruby library dirs(!). Also the path variable is
> ''cgi''.
> So it just traverses all lib directories and loads the first file names
> cgi.rb, even if it''s in a ruby or rails library dir.
>
> with safe_load_paths being defined as:
>
> def safe_load_paths #:nodoc:
>   if defined?(RAILS_ROOT)
>     $LOAD_PATH.select do |base|
>       base = File.expand_path(base)
>       extended_root = File.expand_path(RAILS_ROOT)
>       base.match(/\A#{Regexp.escape(extended_root)}\/*#{file_kinds(:lib)
> * ''|''}/) || base =~ %r{rails-[\d.]+/builtin}
>     end
>     ...
>
> where File.expand_path(RAILS_ROOT) is my application dir.
>
> This:
> base.match(/\A#{Regexp.escape(extended_root)}\/*#{file_kinds(:lib) *
> ''|''}/)
> seems to match too much, some debugging output shows that
> file_kinds(:lib) * ''|'' returns
''app|lib''
>
> so this is base.match(/\A/path/to/your_app/\/*app|lib/)
> with no parenthesis around app|lib !
> So any dir matching ''lib'' is included.
>
> Fix:
> actionpack-1.12.4\lib\action_controller\routing.rb: 276
> CHANGE
> base.match(/\A#{Regexp.escape(extended_root)}\/*#{file_kinds(:lib) *
> ''|''}/) || base =~ %r{rails-[\d.]+/builtin}
> TO
> base.match(/\A#{Regexp.escape(extended_root)}\/*(?:#{file_kinds(:lib) *
> ''|''})/) || base =~ %r{rails-[\d.]+/builtin}
>
>
> Vulnerability fixed :)
>
> ...and I haven''t even finished my first rails app yet ;)
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060810/b7140928/attachment-0001.html

On Aug 9, 2006, at 9:49 PM, Sam Degres wrote:
> You make some good points and have valid concerns.  However, the fact
> remains that Rails is a very new framework and prone to security  
> issues.
Every bit of software on a network is prone to security issues.  I''d  
hazard a guess there are still day-0 security bugs in every available  
fully-patched TCP stack running on a machine on the Internet.

The place where it matters that Rails is "very new" is that the team  
doesn''t appear to have a routine down for dealing with this sort of  
thing.  That said, Rails has moved beyond the audience of "a small  
number of Rubyists that at least someone on the core team knows  
either in person or online".  What works for word-of-mouth amongst  
associates does not work for mass distribution.

Some personal observations*:

1. The manner of the announcement probably had as much to do with  
people''s reactions as the reaction itself.  The industry is "this
release fixes critical security bugs, and is recommended for all  
users immediately".  The industry is not used to all-caps and words  
like "MANDATORY".  While experience tells me that the team is  
hunkered down working very hard at this (and probably wrote the  
announcement as an afterthought), the announcement gives the  
impression they''re all sitting in a room screaming "OH NOES!"
and
having seizures.  The problem was exacerbated by the mystery behind  
the release:  people are used to being told "update if you rely on  
the following features" or "this is a security update for
everyone".
They aren''t used to "it''s a secret!" from people who
are normally
quite open.  It isn''t clear that the secrecy bought anything anyway:   
half the people in the channel last night seemed to be diffing the  
new release against the last, and it sounds like the script kiddies  
were already trading exploit kits last night.  Telling us what areas  
are affected wasn''t going to make the already-available exploit code  
be any more already available.

The solution is two-fold:  first, the core team needs to tighten its  
messages on things like this (should be trivial: it''s not like we  
don''t all spend too much time writing on blogs and lists anyway).   
And second, we as the community need to realize that security issues  
are a fact of life, and patches (and rapid adoption of them) are a  
necessity.

2. For all that the release was described as a "drop-in" replacement,
various people on the channel last night were pointing out breakage.   
This is both something to be avoided as much as possible and  
something that is somewhat unavoidable.  With a platform as young yet  
complex as Rails (see below for why I claim that) things will break.   
There are ways to reduce the risk and impact of this problem:  in  
code and in release process.  I''ll talk to each in turn:

2.a. Code comes in with complexity.  Rails is growing increasingly  
complex:  to some extent internally, but to a large extent based on  
the plugins, generators, engines and customizations that people build  
on top (and all through) the core distribution.  Some people have  
made that argument that Rails should add features and functionality:   
e.g. implement a login system rather than having n subtly  
incompatible ones out there to choose from.  While doing that will  
probably cut down on the problem in the short term, I suspect it will  
make things worse in the long term (while also cutting down on  
flexibility).  Nevertheless, Rails isn''t just the core distribution,  
but a platform, and for users the complexity comes in at the platform  
level.  As the platform and community grows, the number of things  
that a "minor" Rails release can break will grow faster than the core
code, and faster than it will be possible to test with the current  
resources.

I think the challenge here is to find ways to reduce the dependencies  
and gotchas between the package and the platform.  Mechanisms like  
deprecation marking are good.  "Don''t rely on this feature to
behave
like this [forever / ever]" used to be transmitted by word of mouth  
-- it should probably be more "officially" stated.  If someone has  
ideas on how to programatically manage plugin conflicts, this would  
be a good time to speak up.

2.b. Right now the release process appears to have a trunk (edge) and  
a single branch (release).  A side effect of this is that any  
security or bug fix release is going to pick up other changes that  
happened along the way.  For a team running a production app that  
hasn''t yet updated from, say, 1.1.2 to 1.1.4, the jump to 1.1.5  
becomes even riskier.  The only real way to fix this is to make the  
branching a little more complicated so as to allow very specific  
patches.  For example, the Rails core team might elect to support  
security fixes on a specific number of major and bug fix releases  
back (or a specific length of time back), and then issue security- 
only patches to that code (in addition to bug fixes).

As a more specific example (for illustrative purposes _only_):  3 bug  
fix releases and 1 major release.  As of two days ago that would be  
1.0, 1.1.2, 1.1.3 and 1.1.4.  When this security issue came up the  
team would release 1.0.0.1, 1.1.2.1, 1.1.3.1, and 1.1.4.1.  The  
final .1 would indicate a security patch-level *only*, and the patch  
for that would not include any code changes not needed for the  
security patch.  1.1.5.0, 1.1.6.0, etc. would be bug fixes, picking  
up the security patchlevel in the 1.1.x trunk, and when 1.1.5 comes  
out 1.1.2 drops off the support radar.  When 2.0 domes out the team  
could drop support for anything before 1.1.final (1 major release) or  
1.1.3 (3 bug fix releases).

to visualize this (you use a fixed-width font for mail, don''t you):
------------------------------------------------------------- top  
level trunk (features)
     \
      -------------------------------------------------------- major  
release trunk (bug fixes)
           \                       \
            initial release- *      bug fix release - * - *

	* = security release

Note that it''s only the things on the last line that actually get  
released.  With a 3-level structure like this, "edge" becomes  
confusing:  does it mean the top level trunk? the release trunk?  Or  
maybe there are two edges to freeze.  (Or, more likely, this problem  
suggests against using the example layout described here.)

Obviously, this can get pretty heinous:  multiple commits are a pain  
(and error prone if you don''t test and track stuff), and maintaining  
multiple branches is its own pile of ennui.  I''ve seen pathalogical  
cases (I''ve seen vendors who maintain up to a branch per customer.   
Security patches can take 6 *months* to get out the door while the  
vendor gets around to patching each release.  Rails'' customer needs  
are not at that point, and if they ever gets there the platform will  
have reached the point of uselessness).

I don''t think the core team has the resources to do a full blown  
legacy-support system here, but something is better than nothing.   
The challenge is finding the "something" in a way that works with  
"Getting Real".

Again, the main point is to enable security-only releases while not  
slowing down the rest.

3.  On a related note, I think network based gem installs aren''t  
really useful in a situation like this.  They''re finicky enough on  
their own - but when 100,000 people hit the server at the same time  
to download a critical release the system tends to fall over hard.   
Can we get a download page with a single downloadable file (gem?   
tgz?  also a zip for windows?) containing all the core dependencies?

* I do have some experience managing development and release for  
infrastructure software that was used by thousands of other people,  
had occasional security issues, and had complex compatibility  
requirements.  That and $.50 will not buy you a cup of coffee at  
Starbucks.

I''m no http server configuration expert but they seem pretty
configurable..
Is there not a way to band-aid the problem by hard-coding the server NOT to
access these URLs from the front-end?

At least it would stop the script kiddies.

On 8/10/06, Stephen Caudill <scaudill@gmail.com>
wrote:
>
> On Aug 10, 2006, at 10:44 AM, David Morton wrote:
>
> > dseverin wrote:
> >> E.g. for Rails 1.1.4 url like
http://127.0.0.1:3000/breakpoint_client
> >> can easily take down your server to ever-waiting state (my app has
> >> gone
> >> there, when I tried).
> >
> > This url takes down my server, running 1.1.5 and mongrel
>
> Sadly on my production xserve running Apache mod_proxy to lighttpd,
> the url:
>
> /breakpoint_client
>
> will hang that process indefinitely. We''re running with max-procs
at
> 3. I haven''t tested (nor do I really want to on my production
server)
> to see if I can get all three processes to hang.
>
> Repeatedly hammering this same server with combinations of the paths:
>
> /cgi
> /active_support/dependencies
> - and -
> /builder/blankslate
>
> brings it to a deadlock.  I''m assuming this is the same essential
> issue as above. I wouldn''t know for sure though, because the
server
> stops writing to the log at some point during this process. ugh.
>
> ...and I thought I was in the clear after doing the upgrade to 1.1.5
> yesterday :(
>
> - Stephen
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060810/f70bfbf2/attachment.html

Daniel Haran wrote:
> 
> Is that the same security flaw, or another one entirely?
Looks like a new one inadvertently introduced as part of 1.1.5.  This
patch to routing.rb should fix (and explain why):

--- routing.rb.orig     2006-08-10 12:20:12.830325000 -0500
+++ routing.rb  2006-08-10 12:20:26.043147000 -0500
@@ -273,7 +273,7 @@
             $LOAD_PATH.select do |base|
               base = File.expand_path(base)
               extended_root = File.expand_path(RAILS_ROOT)
-
base.match(/\A#{Regexp.escape(extended_root)}\/*#{file_kinds(:lib) *
''|''}/) || base =~ %r{rails-[\d.]+/builtin}
+
base.match(/\A#{Regexp.escape(extended_root)}\/*(#{file_kinds(:lib) *
''|''})/) || base =~ %r{rails-[\d.]+/builtin}
             end
           else
             $LOAD_PATH

-- 
Posted via http://www.ruby-forum.com/.

On 8/10/06, Francis Cianfrocca <garbagecat10@gmail.com>
wrote:
>
> We know absolutely nothing about how the vulnerability came to the
> attention of the Rails team. Looking back at the recent history of
> discovered vulnerabilities in closed-source ommercial products, roughly
> the following has been the case:
>
> "White hats" (whatever their motivations) often discover
vulnerabilities
> and bring them quietly to the attention of the affected vendors. At this
> point several responses by the vendor are possible (and all of them have
> been observed): 1) they can patch the problem, release the patch, and
> then come fully clean (including exploit details) once the patch is
> available; 2) they can quietly release a patch and hope no one catches
> on that there was a problem, or 3) they can decide to do nothing and
> hope (or pressure) the exploit discoverers to keep quiet while they
> continue to "work on it." In any case, closed-source processes
are such
> that it can take days or weeks to produce a patch.
>
> The incredible but true fact is that companies like Microsoft, Sun,
> Cisco, and others that often face this situation don''t face a lot
of
> real risk from not patching their problems. The opprobrium that
> Microsoft right gets for their less-than-strict approach to security
> vulnerabilities doesn''t keep enough people from buying their
products
> for them to apply more than Chairman and CEO-level lip service to the
> problem.
>
> What has happened several times is that the reporters of a problem felt
> strongly enough about an unpatched vulnerability that they went public
> with the information. This decidedly antisocial behavior does have the
> effect of forcing the vendor''s hand, but it also makes everyone
scared
> as heck for the nontrivial amount of time it takes for a vendor to
> release a patch.
>
> But with open source software, we expect well-audited patches to new
> vulnerabilities to be released within hours of discovery. So the pattern
> of keeping quiet until the patch is available is not necessarily a bad
> one because the time is so short. But it''s essential to give some
> indication of the nature of the problem in the initial advisory!
> Otherwise no one has any way to judge their vulnerability. Applying a
> patch to a large number of servers is not something that can be done
> instantaneously, especially since it completely invalidates all your
> unit and regression testing. That means there is a significant-sized
> window of time during which a sysadmin must be able to make an
> intelligent decision whether to shut down or not.
>
> We knew Rails is a relatively immature technology. What we have just
> discovered is that the Rails team is a relatively immature team. They
> will learn from this and get better, and/or they will partner with
> people who know better. We know they tried to reduce the level of
> problems by inhibiting the flow of information to the bad guys. But as
> many have pointed out, that doesn''t slow the bad guys down at all,
> especially when the source is open. If anything, the team should have
> given a description of the vulnerability and postponed full technical
> details for 24 hours to give people time to patch.
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
I completely agree with you Francis, this is a very immature on the part of
the team. And it specially hurts people like me who are trying to convince
the powers to be in my company how good RoR is. Big corporations are hooked
onto Java/C#, not that they don''t have security problems are better
languages, but they give sufficient description of the vulnerabilities and
there is one place to call for support. So for RoR to be adopted in big
corporations this kind of behaviour is going to leave a bad impression.

your thoughts???

-daya
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060810/e940eca0/attachment-0001.html

dseverin wrote:
> Hm, there seem to be already proof-of-concept exploit
> (found on ror2ru group: 
>
http://groups.google.com/group/ror2ru/browse_thread/thread/e654a6ddedc29e7e/7b90204e50bd7974
> )
We see that nondisclosure is ineffective, since crackers don''t care 
about keeping the secret.

> And for Rails 1.1.5 (you say, it is fixed?) http://127.0.0.1:3000/cgi 
> brings down routing totally.
> 
> Are these the only affected by "security patch" places, or we
should
> expect more unknown, so-called "fixed" bugs???
A few minutes ago, on the Rails weblog:

"the 1.1.5 update from yesterday only partly closed the hole (getting 
rid of the worst data loss trigger). After learning more about the 
extent of the problem, we?ve now put together a 1.1.6 release that 
completely closes all elements of the hole"

This would have been fixed in MINUTES instead of days if the 
vulnerability had been fully disclosed.

Security through obscurity is no security at all.

> And there was already a ticket "#5408 Unhandled urls can cause loading
> of arbitrary ruby files" on Rails TRAC from 06/16 about mentioned 
> issues...
> 
I noticed that TRAC was down most of yesterday. Intentionally? So that 
people couldn''t go read the old tickets?


Paul


-- 

--------------------------------------------------
--    Paul Legato, Senior Software Engineer     --
---       Networked Knowledge Systems          ---
----   P.O. Box 20772 Tampa, FL. 33622-0772   ----
----- (813)594-0064 Voice  (813)594-0045 FAX -----
------           plegato@nks.net            ------
--------------------------------------------------

--------------------------------------------------
-----   This email bound by the following:   -----
---- http://www.nks.net/email_disclaimer.html ----
--------------------------------------------------

Nick wrote:
> Daniel Haran wrote:
>> 
>> Is that the same security flaw, or another one entirely?
> 
> Looks like a new one inadvertently introduced as part of 1.1.5.  This
> patch to routing.rb should fix (and explain why):
Oy, that''s what you get with security through obscurity. Another bug.

I managed to get around the breakpoint_client hanging the entire machine 
by adding it at the top of routes.rb, which is hackish - and I don''t 
know what else is there that could be a vector of attack.

sigh :(

-- 
Posted via http://www.ruby-forum.com/.

Nick wrote:

I think we might want to modify that patch further. I don''t see why
there''s a \/* separating the RAILS_ROOT from the (app|lib) portion. It
should be \/+ right?

Modified patch below.

--- routing.rb.orig     2006-08-10 12:20:12.830325000 -0500
+++ routing.rb  2006-08-10 12:20:26.043147000 -0500
@@ -273,7 +273,7 @@
             $LOAD_PATH.select do |base|
               base = File.expand_path(base)
               extended_root = File.expand_path(RAILS_ROOT)
-
base.match(/\A#{Regexp.escape(extended_root)}\/*#{file_kinds(:lib) *
''|''}/) || base =~ %r{rails-[\d.]+/builtin}
+
base.match(/\A#{Regexp.escape(extended_root)}\/+(#{file_kinds(:lib) *
''|''})/) || base =~ %r{rails-[\d.]+/builtin}
             end
           else
             $LOAD_PATH

-- 
Posted via http://www.ruby-forum.com/.

On 8/10/06, Daniel Haran <chebuctonian@gmail.com>
wrote:
>
> Nick wrote:
> > Daniel Haran wrote:
> >>
> >> Is that the same security flaw, or another one entirely?
> >
> > Looks like a new one inadvertently introduced as part of 1.1.5.  This

*what? does this mean there is one more security hole as a result of
applying 1.1.5 ??*
> patch to routing.rb should fix (and explain why):
>
> Oy, that''s what you get with security through obscurity. Another
bug.
>
> I managed to get around the breakpoint_client hanging the entire machine
> by adding it at the top of routes.rb, which is hackish - and I
don''t
> know what else is there that could be a vector of attack.
>
> sigh :(
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060810/0d90f258/attachment.html

Apply the latest patch for your version of Rails.

http://weblog.rubyonrails.org/2006/8/10/rails-1-1-6-backports-and-full-disclosure

On 8/10/06, Daniel Haran <chebuctonian@gmail.com>
wrote:
>
> Nick wrote:
> > Daniel Haran wrote:
> >>
> >> Is that the same security flaw, or another one entirely?
> >
> > Looks like a new one inadvertently introduced as part of 1.1.5.  This
> > patch to routing.rb should fix (and explain why):
>
> Oy, that''s what you get with security through obscurity. Another
bug.
>
> I managed to get around the breakpoint_client hanging the entire machine
> by adding it at the top of routes.rb, which is hackish - and I
don''t
> know what else is there that could be a vector of attack.
>
> sigh :(
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


-- 
Thanks,
-Steve
http://www.stevelongdo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060810/8a07d921/attachment.html

Microsoft and Sun went through growing pains with their technologies as
well.  ''Jakarta'' Struts handled early vulnerabilities in much
the same
fashion.  To expect 37signals and the Rails core team to respond in the same
way a major vendor with thousands of employees, several hundred of which are
dedicated solely to security, is ludicrous.

Bugs in software happen. Period.

Coordinating the effort with shared hosting companies and getting the word
out that there was a problem that required a mandatory fix.  Due to the
particularly severe nature of the problem and its ability to cause data
loss, I think the Rails team did the best they could by waiting 24 hours to
disclose the problem.

The Rails team has shown great restraint in not getting into arguments and
flame wars and has stated very maturely to communicate future
vulnerabilities in a more open fashion.  So until you get your next
Microsoft monthly critical patch, relax people.

-Steve
http://www.stevelongdo.com

On 8/10/06, linux user <fanoflinux@gmail.com>
wrote:
>
> On 8/10/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> >
> > We know absolutely nothing about how the vulnerability came to the
> > attention of the Rails team. Looking back at the recent history of
> > discovered vulnerabilities in closed-source ommercial products,
roughly
> > the following has been the case:
> >
> > "White hats" (whatever their motivations) often discover
vulnerabilities
> > and bring them quietly to the attention of the affected vendors. At
this
> >
> > point several responses by the vendor are possible (and all of them
have
> > been observed): 1) they can patch the problem, release the patch, and
> > then come fully clean (including exploit details) once the patch is
> > available; 2) they can quietly release a patch and hope no one catches
> > on that there was a problem, or 3) they can decide to do nothing and
> > hope (or pressure) the exploit discoverers to keep quiet while they
> > continue to "work on it." In any case, closed-source
processes are such
> > that it can take days or weeks to produce a patch.
> >
> > The incredible but true fact is that companies like Microsoft, Sun,
> > Cisco, and others that often face this situation don''t face a
lot of
> > real risk from not patching their problems. The opprobrium that
> > Microsoft right gets for their less-than-strict approach to security
> > vulnerabilities doesn''t keep enough people from buying their
products
> > for them to apply more than Chairman and CEO-level lip service to the
> > problem.
> >
> > What has happened several times is that the reporters of a problem
felt
> > strongly enough about an unpatched vulnerability that they went public
> > with the information. This decidedly antisocial behavior does have the
> > effect of forcing the vendor''s hand, but it also makes
everyone scared
> > as heck for the nontrivial amount of time it takes for a vendor to
> > release a patch.
> >
> > But with open source software, we expect well-audited patches to new
> > vulnerabilities to be released within hours of discovery. So the
pattern
> > of keeping quiet until the patch is available is not necessarily a bad
> > one because the time is so short. But it''s essential to give
some
> > indication of the nature of the problem in the initial advisory!
> > Otherwise no one has any way to judge their vulnerability. Applying a
> > patch to a large number of servers is not something that can be done
> > instantaneously, especially since it completely invalidates all your
> > unit and regression testing. That means there is a significant-sized
> > window of time during which a sysadmin must be able to make an
> > intelligent decision whether to shut down or not.
> >
> > We knew Rails is a relatively immature technology. What we have just
> > discovered is that the Rails team is a relatively immature team. They
> > will learn from this and get better, and/or they will partner with
> > people who know better. We know they tried to reduce the level of
> > problems by inhibiting the flow of information to the bad guys. But as
> > many have pointed out, that doesn''t slow the bad guys down at
all,
> > especially when the source is open. If anything, the team should have
> > given a description of the vulnerability and postponed full technical
> > details for 24 hours to give people time to patch.
> > --
> > Posted via http://www.ruby-forum.com/.
> >
> >
__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>
>
I completely agree with you Francis, this is a very immature on the part
of
> the team. And it specially hurts people like me who are trying to convince
> the powers to be in my company how good RoR is. Big corporations are hooked
> onto Java/C#, not that they don''t have security problems are
better
> languages, but they give sufficient description of the vulnerabilities and
> there is one place to call for support. So for RoR to be adopted in big
> corporations this kind of behaviour is going to leave a bad impression.
>
> your thoughts???
>
> -daya
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060811/ecf47aac/attachment.html