BreakingPoint Labs Blog

A Few More Bugs in Ruby

Sean Bradly — 2008-07-03T11:42:33Z

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

The Difficulty With Testing Blacklists

Dustin D. Trammell — 2008-07-02T19:09:55Z

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.

More Intrusion Prevention Discussion

Kyle Flaherty — 2008-07-02T13:10:00Z

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.

DPI for Bandwidth Shaping? Where's the news?

Dennis Cox — 2008-07-01T13:10:00Z

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.

Load Profiles for Layer 4-7 Traffic

Kyle Flaherty — 2008-06-27T12:25:00Z

Dennis just put together a new screencast which gives you a quick tour of load profiles for Layer 4-7 traffic. He also goes into how to create steps and loops in Layer 2/3 test components. For current BreakingPoint users, the load profiles shown in the screencast will be found in the 1.2.1 release.

Below is a preview or you can always view it in full glory in a Separate Window (it's a little over 6 min.).

Filling the Application Gap

Kyle Flaherty — 2008-06-25T12:58:43Z

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".

Faster, ActiveX! Kill, Kill!

Tod Beardsley — 2008-06-24T12:00:00Z

If you haven't thought about ActiveX Exploitation in a while, a read-through of Warlord's January 2008 article, "ActiveX - Active Exploitation" is in order. I bring this up because the next StrikePack will feature a new strike, "Analysis: Killed ActiveX Instantiation."

As the name implies, this strike iterates through the client-side ActiveX controls that Microsoft has "killed" via the kill bit mechanism, and simulates a series of evil web pages which instantiate those controls. As of today, there are 445 kill bits set on Windows XP and Vista. These are all controls that Microsoft, in no uncertain terms, has labeled as Very Bad For Internet Explorer. If you run any of these controls, your browser will crash in horrible ways, or you risk getting commands passed directly to the shell, or your browser hands over all your personal data, or some other awful desktop fate.

Instantiating these controls is easy -- just deliver an OBJECT tag with the appropriate CLSID, reference the object with your exploitastic Javascript, and you're pretty much done. Thus, you would think that blocking these controls from instantiating in the first place would be as fundamental to malware detection as any string matching Slammer or Blaster signature.

However, informal testing of a couple devices we have around the office proved this assumption to be baseless. Rather than the forty or fifty percent detection rates I was expecting, I found rates between zero and ten percent.

Admittedly, I had low expectations to begin with, so I wasn't exactly shocked. That said, if you're in the market for a fancy expensive device that claims client-side coverage, you may want consider how that gear stacks up against vendor confirmed, publicly disclosed, easy to use browser vectors.

Deep Packet Inspection (DPI) Webinar

Kyle Flaherty — 2008-06-20T13:25:11Z

NSS Labs has announced a Webinar series focused on "High-Speed Deep Packet Inspection (DPI)". The Webinar series starts on July 16th at 10am PDT with NSS Labs Chief Scientist, Bob Walder and CEO, Vik Phatak. After the first one we will certainly be discussing in more detail here on the blog and welcome you to ping us on Twitter during the webinar.

More information and registration.

When Looking Bad Makes You Good

Dennis Cox — 2008-06-19T10:00:00Z

Aren’t you afraid you’re going to make everybody look bad?

I often get asked this question when I am demonstrating the product, discussing test results, or explaining how my product works to the folks who are testing network devices. Why is it that everyone is afraid of looking bad? It seems like the whole network industry has been immersed in this fear for so long that they’re willing to do anything to look good.

Test gear companies are aware of this fear, so they’ve built their products to favor specific network equipment vendors. At the end of the day, test gear companies will do anything to ensure that their customers’ products don’t look bad – even if it means tweaking their test gear to work better with certain network equipment. My problem with this is: how will network equipment manufacturers ever know if their stuff really works if they’re not breaking their equipment?

One of the reasons why the companies I’ve been with have all been successful is because we focused on breaking our equipment. I wanted to find test gear that showed me the problems with our products; I wasn’t particularly looking for test gear that would help improve the specs on our data sheets. Obviously, that’ s not a bad thing, but it’s not the most important thing. The most important thing for us was finding the issues with our products before they were released into the field. After all, the field is the worse place to find an issue, the costs are a lot higher and the debugging time is infinitely longer.

So, my answer to the question, “Aren’t you afraid you’re going to make everyone look bad?” is no. I’m afraid of what will happen if someone installs network equipment that wasn’t properly tested. I’m afraid something terrible will happen, like a CEO not being able to access their e-mail or giant wombats overtaking the world.

What do you use your test gear for?

File Format Vulnerabilities and Dynamic Exploit Generators

Dustin D. Trammell — 2008-06-17T21:45:04Z

File format vulnerabilities make for very interesting network security device test cases. Due to their nature and how they're transported within network traffic, there are generally multiple layers of data structure, formatting, encoding, and potential obfuscation in play. Not only must you consider the file format in question's own internal structure, but quite frequently there is further embedded content within that structure. This entire file object, being it's own self-contained entity, is then potentially being sent over any number of various network transports. Because the vulnerabilities usually lie in some anomalous use of the file format's internal structure, a bad value contained within that structure, or embedded content within the file, a network security device that intends to detect this maliciousness not only needs to be able to recognize it wherever in the network packet flow it may be, but also be able to reconstruct potentially fragmented data, decode potentially encoded data, and then identify the malicious bit itself.

To better illustrate this dilemma, let's take a look at the recent ms08-033 AVI/MJPG vulnerability. AVI is essentially a RIFF file with some particular AVI-specific FourCC tagged LISTs and chunks. The vulnerability here lies in the value of the "biHeight" field within the BITMAPINFOHEADER structure, which is essentially the AVI "stream format" ("strf") chunk. This chunk is part of a "strl" LIST that describes an individual video stream contained within the file, which, along with other "strl" LISTs generally follow the main AVI header ("strh") chunk. By populating the "biHeight" field with a negative value (I had success with values -1 through -31), you can trigger the vulnerability described in the advisory and cause Windows Media Player to crash. Windows Media Player also doesn't seem to care too much about what Codec you indicate that the video stream should be processed with ("fccHandler") in the AVISTREAMHEADER. Either Windows Media Player defaults unrecognized handlers to the MJPG Codec, or it determines where to send stream data with an unrecognized handler value based on recognizing the encoding method applied to the stream data itself. Further explanation of the vulnerability can be found in a post by Mark Dowd over at ISS's Frequency X blog.

The strikes that are included in the Security component of the BPS product generally draw upon a back-end code-base that is capable of generating the various bits of data that are used during the strike's attack. For file format vulnerabilities, this back-end is usually a dynamic file generator that can generate randomized, but still valid, files of the type in question. This back-end is then coupled with individual strike descriptions which describe the parts of the attack such as various meta-data, the network connections involved, and what actual data is sent across the wire within those connections. For file format vulnerabilities, the possibilities here are endless. Due to the file being a self-contained unit, it can be sent from attacker to victim over any number of transports such as HTTP, FTP, POP3, SMTP, IMAP, peer-to-peer applications, tunneled protocols, embedded within other files, and so forth. Many of these available transports also provide for multiple types of data encoding during transport, such as SMTP's Base64, Quoted-Printable, and UUEncoded variations.

For the ms08-033 example given above, we have developed 8 different transport-and-encoding-based strikes, each of which plug into the RIFF(AVI/MJPG)-generating back-end to dynamically generate the malicious file being transferred. When you do the math on all of the permutations of the bits of data that a network security device either MUST (to properly detect the badness) or SHOULD (to avoid false positives) be included in a signature or filter for this vulnerability, not including everything else that is randomized by our RIFF-generating back-end, you end up with 1,065,151,889,408 (yes, that's just over one trillion) attack permutations, or malicious, vulnerability-triggering attacks. These attacks can be produced via the eight ms08-033 strikes that will be included in our next StrikePack. Any network security device's filters or signatures must be able to match on all of these permutations, do it reliably, and not false positive on legitimate AVI/MJPG files in order to legitimately claim coverage for this vulnerability. A daunting task indeed.