-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/1070/updates-on-drew-yaos-terrible-ruby-vulnerabilities/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
irb(main):005:0> str = "A"*(2**16) ;while 1; str < ary = []; ary[0x7fffffff] = "A"
IndexError: index 2147483647 too big
Was it just the string operation that still caused the segfault on 1.8.7-p22?
I'd say IndexError is the correct(er) error to throw for the second issue - array[0x7fffffff] assignment? It's a different result to the segfault it caused on my ruby 1.8.6 (2007-09-24 patchlevel 111).
The test case does not cause a crash in the patched version of 1.8.6 that will be going out in a Mac OS X update soon. The patch that Ruby ended up with was not the same as the one that I sent them.
i = 1 << 0x1fffffff; j = i; true
j = j << 0x1fffffff; true
j = j << 0x1fffffff; true
j = j << 0x1fffffff; true
j = j << 0x1fffffff; true
j = j << 0x1fffffff; true
j = j << 0x1fffffff; true
j = j << 0x1fffffff; true
j
Break in rb_big2str, and land here:
677 while (i && j) {
(gdb) print i
$16 = 134217728
(gdb) print j
$17 = 2
("i" is the size of the bignum, "j" is the size of the target string).
defaults write com.apple.CrashReporter DialogType developer
I get for ary[0x7fffffff] = "A":
EXC_BAD_ACCESS (0x0001)
KERN_PROTECTION_FAILURE (0x0002) at 0x00705000
Thread 0 Crashed:
0 rb_mem_clear + 16 (array.c:30)
1 rb_ary_store + 212 (array.c:377)
2 rb_ary_aset + 412 (array.c:1078)
3 rb_call0 + 1196 (eval.c:5815)
4 rb_call + 612 (eval.c:6063)
5 rb_eval + 6804 (eval.c:3430)
6 eval + 1068 (eval.c:6458)
7 rb_f_eval + 468 (eval.c:6576)
8 rb_call0 + 1196 (eval.c:5815)
9 rb_call + 612 (eval.c:6063)
Just my two cents.
Still getting a seg fault on:
ruby -ve 'str = "A"*(2**16) ; loop{ str << str ; puts str.size }'
ruby 1.8.6 (2008-06-22 patchlevel 231) [i686-linux]
131072
262144
-e:1: [BUG] Segmentation fault
irb(main):001:0> ary = []
=> []
irb(main):002:0> ary[0x7ffffff] = "A"
=> "A"
irb(main):003:0> ary[0x7ffffff] = "A"
=> "A"
irb(main):004:0> ary[0x7ffffff]
=> "A"
The second one, started to trash (I expected it because of the size of the string) and I aborted it.
irb(main):006:0> while 1;str<<str;puts str.size;end
131072
262144
524288
1048576
2097152
4194304
8388608
16777216
33554432
67108864
134217728
268435456
536870912
IRB::Abort: abort then interrupt!!
from /usr/lib/ruby/1.8/irb.rb:81:in `irb_abort'
from /usr/lib/ruby/1.8/irb.rb:243:in `signal_handle'
from /usr/lib/ruby/1.8/irb.rb:66:in `start'
from /usr/lib/ruby/1.8/irb.rb:66:in `call'
from /usr/lib/ruby/1.8/irb.rb:66:in `start'
from (irb):6:in `call'
from (irb):6
from :0
And I'm using an vulnerable version.
$ ruby --version
ruby 1.8.6 (2007-09-24 patchlevel 111) [i486-linux]
On ubuntu hardy.
Is this Mac only?
If it is, the impact is much lower (production servers tend to be Linux for Ruby web applications).
Aureliano.
Can folks on this blog thread please join us in a discussion of this issue at the ruby-talk mailing list or its web-accessible thread at http://www.ruby-forum.com/topic/157034 ? I'm trying to get everyone that's been working on this talking in one place so we can best coordinate our efforts to resolve this.
Thank you.
-igal
If you see anything interesting here, you are welcome to cross-post it.
One more f in there and it will crash.
I recognize that I should be committing descriptions including the phrase "context-dependent" to cve.mitre.org instead of expressing the maximum attitude I'm allowed as an allegedly neutral party, but... Ruby is popular. Thus someone's gonna research it, and they're gonna find bugs. It's the circle of strife.
Of course, whatever replaces Ruby as the newest fad won't have any vulnerabilities at all, so we can all rest easy after this whole thing blows over.
I guest you should have to wait until Ruby developers create a valid patch. The whole code that manages arrays need a bit of review, while playing with those bugs, I've found another problem, which I reported to security@ruby-lang. So I think the best thing you can do to help Ruby community, is not providing patches but trying to spot other mistakes in the code and report them. IMHO
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ru...
http://www.blackhat.com/presentations/bh-jp-05/...
Fixing the macros (which should be replaced with functions AFAIAC) was not the right approach, which Matz knew, but he did not (nor any other member of core) choose to fix the issues in the 1.8 code. Now it is 2008 and Yao had to rediscover the problems to make something happen. Way to go ruby-core!
just wait until i go public with my javascript stuff !
Here is a pastie of my efforts: http://pastie.org/222714.
http://www.poppopret.org/code.html