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)

0 comments | Tags:

I was recently directed to Greg Hoglund's new blog, Fast Horizon.  So far the few posts he's made have been excellent reading, and I generally agree with most of what he's been saying over there.  Just recently he put up a post entitled "Whitelists are the new snake-oil" where he convincingly outlines both why blacklisting is a failing approach to stopping malware (if it ever really worked in the first place), and why the whitelisting approach that many vendors are moving toward is equally doomed to failure.  Blacklisting is the current industry standard approach to stopping malware and is used in technologies such as anti-virus and anti-spyware software.  Blacklisting is also the approach that most network security device vendors take to blocking network attacks and exploits.  While firewalls are the obvious exception to this rule as they are essentially whitelist based, the vast majority of packets that get blocked, filtered, or identified by other network security devices such as IDS and IPS systems are done so via a match against a blacklist of traffic signatures.  These signatures are analogous to fingerprints of the known malicious data that traverses the network.  The following quote from Greg's post nicely sums up the difficulties with this approach:

"Blacklisting sounds ideal, but it doesn’t work. New malware emerges daily that has no corresponding blacklist signature. The malware must first be detected, and then processed. There is always a time window where Enterprises have no defense. Recent figures suggest that the AV vendors are falling so far behind this curve that they will never catch up with the deluge of new malware arriving daily. It can take weeks for a signature to become available.

This deluge of new malware is due to several factors. First, there is more money behind malware development than ever before. Second, we weren’t really that good at capturing malware in the past. Today, new malware can be automatically collected, without human intervention. The slow trickle of malware turned into a flood as honeypot technology emerged. Sensor grids can obtain new malware samples with efficiency - they automatically ‘drive by’ (aka spidering) malicious websites to get infections and leave open ports on the ‘Net so automated scanners will exploit them. In parallel to the automated collection efforts, cybercrime has risen to epic levels. Finally, the barrier to entry has dropped for the cyber criminal. Cyber weapon toolkits have become commonly available. Anti-detection technology is standard fare. New variants of a malware program can be auto-generated. A safe bet is to expect thousands of new malware to hit the Internet per day."

What he describes happening in the malware space is also happening within the attack and exploitation landscape.  Network attacks and exploits are becoming increasingly more dynamic and harder to fingerprint for a number of reasons.  As individual exploits increase the number of targets they can attack, which usually consist of various combinations of target software, the operating system running that software, patch-levels of both the software and operating system, the hardware architecture that both are running on, and any number of other target environmental factors, identifying a single exploit or vulnerability based on it's related network traffic becomes much harder.  When you then factor in all of the evasion techniques such as data massaging, reordering, randomizing, encoding, encrypting, tunneling, and any number of others, many of which have become standard in publicly available tools such as the Metasploit Exploitation Framework, the problem gets exponentially harder and you begin to approach the number of potential variants of a single attack or exploit that the malware folks are seeing in their space.

When faced with an ever-changing hostile network environment of malicious traffic, blacklists of signatures and filters that are developed to detect this data must be equally robust, and must be tested and verified with test cases that approach the dynamic nature and variation that you would see in the wild.

For further reading on dynamic security tests, please see my previous post entitled "File Format Vulnerabilities and Dynamic Exploit Generators" from a few weeks ago.  It helps make Greg's point in that it illustrates how many variants of a malicious file must be properly detected when even only a handful of fields of data within that file can change and it still be a working file format exploit.

Posted by Dustin D. Trammell (2008/07/02 14:09:55.425 GMT-5)

0 comments | Tags:

There seem to be several conversations happening on service providers using DPI to throttle traffic.  My reaction?  What's the big deal?

This is another case of the media looking for a story that isn't there. Service providers of all sorts have been using bandwidth shaping [DPI] since the early 90's. Technologies such as Asynchronous Transfer Mode (ATM), had bandwidth shaping in their specifications and ATM was one of the core transports of service providers. UBR , CBR, VBR anyone? Why is this a surprise?

It reminds me of the Global Warming debate. Al Gore has been talking about it since the 70's - yet when he was vice president nothing got done about it. Not his fault, he's just one man. But if he were vice president now with Global Warming such a hot topic, pardon the pun, the media's pressure would bend the will of the people to solve the "issue".

Just yesterday, based on some guys figuring out what statistical packet analysis can get you, everybody went crazy again on this topic. Statistical packet analysis was around WELL before this paper. A bunch of guys from MIT started Mazu, which built a company based on this concept. Arbor is another company that leveraged this, well before Mazu did. So what's the hype? I guess it's a slow news day.

Posted by Dennis Cox (2008/07/01 13:10:00 GMT+0)

1 comments | Tags:

A few weeks ago we talked Intrusion Prevention Systems (IPS) testing and we posted up our videos and methodology.  We've gotten some great feedback from the community and will be using some of it in our next set of videos (and we are always looking for more input).  With that in the back of my head I was interested to see The Tolly Group's most recent custom test of TrustWave's Intrusion Prevention Appliance.  You can download the test summary and look at how they are going to test (full disclosure that they are using BreakingPoint in the testing).  We also have more info on security equipment testing.

Posted by Kyle Flaherty (2008/07/02 13:10:00 GMT+0)

0 comments | Tags:

Application traffic continues to grow at an astonishing pace, which certainly means many things to many people, but for Network Equipment Manufacturers (NEMs) and service providers it means that network devices must perform with all of this traffic AND do it at high-speeds of 10 gigabit per second and faster.  Today we announced a toolkit to allow for native generation of stateful proprietary application traffic (news release).  I thought I would also share a couple of graphics we've been working on to show the "application gap" that exists and what we are trying to do about it:

Legacy test vendors have been unable to meet the application traffic needs of NEMs and service providers due to their locked-down architecture. However it is critical to be able to test network equipment with stateful application traffic including business, recreational, malicious, and proprietary application traffic.

As slide 2 shows, BreakingPoint is closing the "application gap" with the release of this toolkit which allows, for the first time, native generation of stateful proprietary application traffic.  The equation becomes simple: business, recreational, malicious, and proprietary application traffic plus the ability to simulate this traffic at speeds of 10 Gigabits per second on a single interface and scale up to 160 Gigabits per second and you are talking "real-world performance testing".

Posted by Kyle Flaherty (2008/06/25 07:58:43.404 GMT-5)

0 comments | Tags: