A Few More Bugs in Ruby
We use Ruby all over the place in the BPS appliance and for our internal tools, so the latest run of vulnerabilities in Ruby discovered by Drew Yao, discussed in detail here, really caught our eye. While analyzing them, the BreakingPoint Labs team found several new unpatched bugs in Ruby's parser.
These bugs are rather low impact because they don't really appear to be exploitable and because triggering already require enough access to run arbitrary Ruby statements. So we've decided just to publish them here for your enjoyment. Breaking things is just what we like to do here.
Too much recursion when evaluating a statement
Examples:
ruby -e 'eval(“[]”*10000)' ruby -e 'eval(“+0”*8000)'
Each of these causes so many calls to rb_eval() that it eventually runs off and accesses invalid memory. The second seems to be the same crash, but through a slightly different vector and leaves the program in a slightly different state.
Program received signal SIGSEGV, Segmentation fault.
0x0805891d in rb_eval (self=3084609960, n=Cannot access memory at address 0xbf143ebc
) at eval.c:2927
#1 0x0805a45d in rb_eval (self=3084831140, n=0xb7ddbeec) at eval.c:3467
#2 0x0805a45d in rb_eval (self=3084831140, n=0xb7ddbed8) at eval.c:3467
#3 0x0805a45d in rb_eval (self=3084831140, n=0xb7ddbec4) at eval.c:3467
...
#7815 0x0805a45d in rb_eval (self=3084831140, n=0xb7db5aa8) at eval.c:3467
#7816 0x08055e6a in eval_node (self=3084831140, node=0xb7db5aa8) at eval.c:1428
#7817 0x08062649 in eval (self=3084831140, ...) at eval.c:6490
#7818 0x08062a9f in rb_f_eval (argc=1, ...) at eval.c:5691
#7820 0x080602dc in rb_call0 (klass=3084836000, ...) at eval.c:5847
#7821 0x08061965 in rb_call (klass=3084836000, ...) at eval.c:6094
#7822 0x0805a98b in rb_eval (self=3084831140, n=0xb7ddcdb0) at eval.c:3488
#7823 0x08055e6a in eval_node (self=3084831140, node=0xb7ddcdb0) at eval.c:1428
#7824 0x0805644c in ruby_exec_internal () at eval.c:1634
#7825 0x08056490 in ruby_exec () at eval.c:1654
#7826 0x080564b2 in ruby_run () at eval.c:1664
#7827 0x0805434e in main ()
at main.c:48
Extremely long syntax error causes invalid access
Examples:
ruby -e 'eval(“a”*10000000+”$”)'
ruby -e 'eval("a("*10000000)'
ruby -e 'eval("\x01!"*10000000)'
When faced with a syntax error on a huge line like this, Ruby fails to allocate enough memory for the error message and dies trying to copy the message buffer. This seems to work with just about any line with a syntax error that is around 10 megabytes in size or more. The call to “alloca()” in parse.y tries to load the huge error string onto the stack and blows up. Here's the error and the code that causes the crash:
Program received signal SIGSEGV, Segmentation fault. 0x0809bc3b in ruby_yyerror (msg=0xbfe81f68 "syntax error, unexpected $end") at parse.y:2539 In parse.y: 2538 buf = ALLOCA_N(char, len+2); 2539 MEMCPY(buf, p, char, len);
Toorcon Wrap-Up
Now that all is said and done, Toorcon 9 was a smashing success! It was well stocked on great talks and good people and, of course, the after parties were wild fun.
There was a strong theme of automated exploitation this year. Three of the talks that I saw focused on the subject. First up is Jerome Athias, who impressed everyone with his presentation's 3D graphical cinema introduction and then impressed again with his toolkit (written in an IDE called WinDev) for writing exploit modules for the Metasploit Framework in only a minute or two.
Another great talk was given by Jason Medeiros. He started off describing his methodology for detecting different types of crashes and followed up with a cool demo. He had written "from scratch" a complete debugger and heap analyzer. His program took a custom fuzzer definition and a binary as input. A few moments later, his demo generated a C exploit for the stack overflow that his fuzzer had just found.
Then there's the talk given by Nathan Rittenhouse and Johnny Cache. Their talk was focused on Byakugan, a WinDbg plugin. Byakugan is filled with goodies, but the real show stopper was the 3d-accelerated heap visualization. Nathan also gave a demo of his new Ruby replacement for pydbg, which seems to be exactly what I have been looking for. This should be posted to http://noxusfiles.com/ soon. Thanks, Nathan!