You are here: Home Blog BreakingPoint Labs Blog

Toorcon X Mini Wrap-Up

On the whole, I was very happy to have attended the 10th Toorcon in San Diego, CA. Toorcon is probably my favorite small con. The attendance isn't massive but the people are generally more interested and knowledgeable in hacking and security. Not to mention that downtown San Diego is a blast and the weather is absolutely perfect. These were my highlights:

The Future of Lockpicking, datagram
I was glad to see a talk on lock picking that went beyond the realm of a simple how to or a single type attack.  Datagram didn't spend too long explaining the lockpicking techniques even though he did have some good animated visual aids. Instead, he focused a lot on how a lock vendor would react to new attacks getting media publicity. Just like in the software security world, some vendors wouldn't ever go beyond a PR response. Some vendors would add a metal plate in a certain place, much like a software patch, and others still redesigned the locks entirely. Some very interesting industry parallels.

Owning Telephone Entry Systems, Joshua Brashers
So many apartment complexes, condos, and gated communities have computerized panels that visitors can use to ask permission to gain entry. The talk outlined many different types of attacks against these types of systems. Most of these appear to be serviced by 3rd parties and allow you to remotely dial-in. And of course, default passwords are rarely changed. He showed how he was able to “back door the front gate” by adding a new entry that played a “Rick Roll” instead of calling a resident and later opened the gate. Another and more scary attack he outlined was the ability to proxy normal entry calls to his apartment using a VoIP server to perform the MiTM. This looked like it was a lot of fun.

How To Impress Girls With Browser Memory Protection Bypasses, Alexander Sotirov
This was a great talk. Although Dowd and Sotirov gave this talk at Blackhat almost two months ago. It was still a fun and entertaining talk to sit though. Alex outlined the implementations of the newer Microsoft memory protection schemes like SafeSEH, DEP, and ASLR. Then showed how and why none of them were effective in defending Internet Explorer from attacks and how much that impressed the ladies. The paper is here.

Posted by Sean Bradly (2008/10/01 13:27:21.035 GMT-5)

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);

Posted by Sean Bradly (2008/07/03 06:42:33.533 GMT-5)

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!

Posted by Sean Bradly (2007-10-22 17:05:23)