Sometime back we had come across this interesting vulnerability posted by a Chinese researcher in his blog, claiming to have found a zero day vulnerability in php 5.2.3.

We got a chance to dig a bit deeper into this and were able to reproduce the vulnerability based on the information provided in the blog. After investigation, we found that this vulnerablility affects not only verion 5.2.3 but also version 5.2.5. It is a heap overflow which can be triggered when a web server with PHP receives a malformed URI request, it can be a simple request like “GET /index.php/aa HTTP/1.1″ . Successful exploitation of this can result in arbitrary code execution with the privileges of the WEB Server.

This happens because the author misplaced the bracket resulting in miscalculation of the buffer which can result in a heap overflow. So fixing this issue is also simple viz: In \sapi\cgi\cgi-man.c do a grep for: “ptlen + env_path_info ? strlen(env_path_info) : 0;” , and replace this with “ptlen + (env_path_info ? strlen(env_path_info) : 0); ”

This is one of the classic examples of small human errors (which can sometime be even typos) that can result in vulnerabilities.

We had reported this issue to PHP dev team almost immediately after we had come to know about this issue in the wild and they’ve just come out with a patch for this. We highly recommend users to update with the latest version of PHP 5.2.6 released . This patch besides this issue, fixes a host of other security related fixes, some of which we deem as critical. This specific issue affects FastCGI packages of PHP.

This issue has been given the identifier CVE-2008-0599.

We shall continue to monitor this threat and update if we come across anything malicious.

The latest Microsoft ActiveX flaw disclosure looks like a silently patched issue.

The flaw, disclosed by US-CERT, was not part of Microsoft’s MS07-069 Security Bulletin released in December of 2007. The CVE ID (CVE-2007-6255) is not listed in Microsoft’s Bulletin at the time of this writing and is still in the reserved state on MITRE’s CVE Web site.

The vulnerability affects an ActiveX control used to play games on the MSN Games site. When exploited, it would allow for code execution at the rights level of the victim because of improperly processing a crafted “host” parameter.

The workaround for those who have not installed the patch is…

Bingo! Set the kill bit. You’ll want to disable the ActiveX object from loading using this class id: E5D419D6-A846-4514-9FAD-97E826C84822.

This is one of those cases where the moment you hear about the vulnerability, there is a patch available already. This, of course, is better than the alternative. Most of you should have the patch already installed.

I’m not going to get into the “Why weren’t we notified?” issue, I just wanted to call attention to this on the off-chance there is anyone who isn’t patched.

Late on Thursday Microsoft released an advisory about a new privilege escalation vulnerability affecting IIS and SQL Server on Windows XP, 2003, Vista, and Server 2008.

It’s likely that this is the same flaw discussed by Cesar Cerrudo in his talk, “Token Kidnapping”, at the HITB Security Conference 2008 in Dubai. Cerrudo had discovered a privilege-escalation vulnerability earlier, and said in March, “Design weaknesses can be abused on Windows XP, Vista, Internet Information Services 7 and Windows Server 2003 and 2008”.

So what is known about this flaw? A malicious local user who has authentication could execute specially crafted code to raise his privilege level to LocalSystem. IIS and SQL Server are the main attack vectors. But other vectors are possible, such as Microsoft Distributed Transaction Coordinator (MSDTC) on Windows Server 2003.

While the vulnerability is limited to a local privilege escalation, IIS’s susceptibility is concerning. The Web server is widely used on the Internet, and is a top pick by Web-hosting providers. We might see Web-hosting providers targeted, and — this is scary -– their clients’ Web sites breached. As Microsoft stated in its advisory, “Hosting providers may be at increased risk from this elevation of privilege vulnerability.” However, no exploitation has been observed at this time.

The next Patch Tuesday is May 13. Sysadmins, please heed to Microsoft’s suggested workarounds for IIS until then -– or more to the point, until Microsoft patches this vulnerability.

Finally, a bit of speculation (hat tip to Kevin Beets). One attack vector for this vulnerability uses the SeImpersonateClient privilege. The MSDN page for privilege constants states:

Windows XP/2000: This privilege is not supported. Note that this value is supported starting with Windows Server 2003, Windows XP SP2, and Windows 2000 SP4.

Microsoft did not say that Windows 2000 or Windows 2000 SP4 are vulnerable. But curiously, they did say Windows XP SP2 is. If Service Pack 2 for Windows XP introduced this vulnerability in that operating system, might Service Pack 4 for Windows 2000 not have done the same for Windows 2000?

Some news is in circulation regarding a recently disclosed (and patched) vulnerability in Adobe’s Flash. The attack used dereferenced NULL pointers, which were believed to be very hard to exploit.

The findings were first revealed in a paper called “Application-Specific Attacks: Leveraging the ActionScript Virtual Machine,”(pdf) by Mark Dowd. The paper described a new technique for causing exploitable memory corruption vulnerability in Adobe’s Flash. Whilst the technique has targeted the ActionScript Virtual Machine for Win32/Intel platform, it’s understood that the attack could be carried out on any other platforms where Flash is available. The real question is whether this attack can be more generic to target dereferenced NULL pointers in general!

It is possible to do so, but it’s not that easy. There are certain conditions an exploit of this type has to satisfy before reaching the ultimate goal. Dowd used some wacky techniques to inject malicious ActionScript byte code into Flash runtime (basically by crafting an SWF with something to trigger the vulnerability and point the execution to another loaded-in-memory part of the file that had the malicious content). Then he forced malloc() to fail by trying to allocate some huge memory chunk. When malloc() failed, it returned NULL.

(OK, at this step a program trying to access a NULL pointer would basically crash, and something to check for malloc() return value is necessary to prevent that crash.)

In this case, Flash didn’t check for malloc() failure and did some pointer arithmetic operation to add the value of the pointer (NULL here) to some offset. Now, this “offset” was controllable, and this is where Dowd had preloaded his malicious content. (Don’t get too excited, folks. There were quite a few other conditions that Dowd’s exploit had to meet before loading his payload. But I’m eliminating a lot of details to present the overall picture). So now we have a pretty successful and reproducible exploit on Flash ActionScript VM. It even bypassed Vista’s ASLR because Vista’s Flash was compiled with the runtime security bit off.

Now, scaling this attack against native code is more difficult in spite of the success it had against ActionScript VM. We will still be looking for a controllable offset and a place to preload our payload. Nevertheless, it is still a neat discovery when taking into consideration the level of complexity needed to load the malicious payload.

This discovery reflects a trend that it is possible to circumvent runtime security countermeasures such as ASLR and the like by targeting other environments with higher privileges running on top of the native platform. And if you’re involved in any secure development lifecycle, you’d better go and check your code!

There was an interesting article in InformationWeek this morning about a couple of security researchers who have presented the possibility of using offensive technologies to go after hackers. The most recent was Joel Eriksson from Bitsec, who presented at RSA last week about exploiting security holes in remote-access Trojans.

The article also brings up a five-year-old example of an earlier attempt at offensive technology to be used against hackers. In this case, Tom Liston created a tool called LaBrea (after the tar pits) that would ensnare computers which were being used to attack it either intentionally or due to worm infection.

There are plenty of people within the security industry who would like to be able to employ these tactics. The urge to take a pound of flesh for the late nights and weekends spent dealing with malware attacks is certainly understandable. But I know very few people in this industry who actually think it’s a sound idea, or worth the potential legal trouble.

Just as there are few locales where it is legal for you to shoot an intruder in your home, there are few locales where it is legal for you to attack those who intrude on your computer. Even in those locales where it is not illegal to attack an intruder, you must take into consideration the possible court costs. It’s highly likely the survivor (either the intruder or a family member) will sue you, and it will take some time with a lawyer to defend yourself against these charges. It’s entirely possible that a hacker or a worm-infected user would do likewise.

This is still assuming that your case was reasonably clear-cut, that it was genuinely a hacker or worm infection that was coming after you. It could just as easily be used as a sort of alternate flavor of Denial of Service attack–spoof the traffic or exploit a machine for the purpose of making it a target.

The general computing population is not particularly knowledgeable about the inner workings of their machines; some say there should be licensing such as for driving a car. It’s my opinion that there would first have to be this sort of licensing, and then a permit akin to a “Concealed Carry Permit” before this could be considered a good idea.

The Internet is a scary enough place without adding even more unskilled attackers.

Last week we discussed the fact that Microsoft credited three different researchers for reported CVE-2008-1087 during our monthly Patch Tuesday podcast. The fact that several independent researchers reported the issue suggested that others may not be far behind. This CVE pertains to the Microsoft Graphics Rendering Engine, which has a history of exploitation. In fact, McAfee’s Exploit-WMF detection for MS06-001 exploits was one of the top reported detections around the time that a patch was released. An exploit toolkit was released prior to the patch, which helped contribute to the number of exploits floating around. History may be repeating itself, though out of sequence.

Last Friday the first MS08-021 exploit was discovered in the field, three days after the issue was patched; and though it was not widespread, the discovery of the exploit did highlight the fact that attackers were actively working with exploit code. Today a basic exploit toolkit was posted publicly; and while this new toolkit is primitive, it may very well lead to “one-ups-manship” and the distribution of a more powerful tool.

Given the fact that a patch was released prior to this recent exploit activity it is unlikely that MS08-021 attacks will reach the level of MS06-001 attacks. However, there are still many many vulnerable systems out there, and we’ve seen prevalent exploits that have lasted for years after the issue was patched.

No, it’s not a Massive Ordnance Air Blast Bomb, thankfully. But could users of Apple software feel that it’s really that bad? January 2007 is the Month of Apple Bugs (MoAB), in which a new Apple-related vulnerability is announced for every day of the month.

The first two MoAB bugs affect Apple Quicktime and VLC Media Player respectively. If exploited, both bugs would allow remote code execution — however user interaction is needed.

MoAB is a project similar to November 2006’s Month of Kernel Bugs (MoKB). The bugs released during the MoKB affected software from a gamut of vendors, including Apple, Linux, Microsoft, NetGear, and others. In both projects, security researchers announce previously-unknown bugs in selected software in order to raise awareness about the state of security in these software products.

While many MoKB bugs remain un-patched and the software they affect remain vulnerable, Apple users affected by MoAB can thank Landon Fuller for some temporary relief. Landon, a system architect, has promised to develop unofficial patches for software affected by MoAB bugs.

The researchers at McAfee Avert Labs will continue to follow MoAB closely, so keep reading!

Well, we’ve seen the first of the promised bugs for Apple and Apple products as a part of the “Month of Apple Bugs“. And perhaps unsurprisingly, the first bug is also applicable to Windows as well, being a buffer overflow vulnerability for QuickTime. There’s also some saying that this may be rather difficult to implement.

So in short, this month of bugs that’s supposed to take Mac fans down a peg…also exposes holes in Windows. And maybe it works, maybe it doesn’t. Way to start it off with a bang, there!

As a Mac fan who realizes Apple software is written by humans just like any other software, which will inevitably have the occasional bug, perhaps I’m not the demographic they’re looking to deflate. But really, I think you’d be hard pressed to find even the most rabid Mac fan who believes Apple software is 100% bulletproof. That’s just plain deluded. I think most Mac users at this point are of the opinion that it’s more akin to the risk of mosquito bites in August at Crater Lake, versus in January at the South Pole. There’s just a lot more nasty critters flying around the Windows environs than the OS X environs for the time being.

But even from a strictly researcher perspective, I am curious to see what this month brings up, both in terms of exploits and the discussion around them. Expect to see lots more here on that subject as things progress!

Apparently not! On December 20, a new zero-day exploit for Microsoft Windows operating systems was released. This exploit targets a weakness in the Client Server Run-Time Subsystem, and allows local privilege escalation or denial of service.

Microsoft has acknowledged this vulnerability and admitted that its newest operating system, Windows Vista, is vulnerable.

Keep reading for more on exploits released this holiday season. Happy holidays!

In the week leading up to 12 December 2006, two new Microsoft Word zero-day vulnerabilities became public (Word I, Word II). Microsoft’s December Patch Tuesday fell on December 12, but this cocktail of Microsoft’s patches did not include fixes for the two new Word flaws. To make matters worse, on December 12, a third zero-day Word flaw was released (Word III).

Although one could argue that the December 12 release of a new Microsoft flaw was only a coincidence, it fits the trend of the disclosure of Microsoft vulnerabilities on or just after a Patch Tuesday. November’s trend-fitter, a vulnerability in Microsoft Active Directory, did not include a public proof-of-concept; this month’s trend-fitter, however, does have a public proof-of-concept.

So the Word zero-day trio has a window of exposure of at least a month. Please stay secure as we continue to protect our customers against such attacks.

This Patch-Tuesday, Microsoft patched 11 vulnerabilities. Among the patched vulnerabilities are two that can be remotely exploited by an anonymous user, MS06-074 SNMP Buffer Overflow Vulnerability and MS06-077 Remote Installation Service Vulnerability. The Windows SNMP Service and Remote Installation Service are not default installed which greatly reduces the attack surface.

The vulnerability in Visual Studio, exploited in the wild, has been addressed in this month’s patch cycle.

The update of our graphs of last month is found below. The top graph shows that Microsoft almost hit one hundred critical vulnerabilities for 2006. The year is not over and Microsoft may provide out-of-cycle patches for the current 0-Day Word vulnerabilities.

Malware authors have been pro-active in including exploit code for almost every new vulnerability reported into bots with utmost professionalism. Apart from the numerous Microsoft windows vulnerabilities where exploit code has been methodically incorporated into bot code, McAfee Avert Labs is seeing a trend where popular applications from software vendors are being targeted. In recent weeks we have seen bots that target vulnerabilities or weak passwords in the following applications:

Famatech Remote Admin http://vil.nai.com/vil/content/v_140984.htm
Symantec Antivirus http://vil.nai.com/vil/content/v_140978.htm

Although the vulnerabilities in the above software are dated and patches available, bot authors still found them enticing enough to target machines running vulnerable versions of the these software applications.

Other popular software applications with vulnerabilities that have been targeted by bots in the recent past include:

• CA BrightStor
• Dameware
• MySQL
• WU-FTP
• VNC

Most of the major software vendors like Adobe, Microsoft and Oracle now follow a monthly patching cycle and administrators have their hands full in ensuring that every machine on the network is patched. Sadly, most administrators do not have the flexibility to deploy patches immediately to machines on the network for policy reasons. For example, the organization could be using legacy software which could break if a new service pack was applied and keeping these legacy applications running takes precedence over applying the latest hot fixes. In rare cases a fix could break something else in the operating system or adversely affect other applications. Administrators need more time to first deploy these hot fixes in a test environment and QA them properly before deploying them to the entire enterprise.

Given the trend where malware authors are expanding their attack horizon by targeting vulnerable software applications, it wouldn’t be surprising if an exploit directed at popular instant messaging (IM) clients should surface. IM is popular both in consumer and corporate networks and an exploit that gives remote shell on a machine running an instant messenger would be stunningly effective.

That being said, it will be interesting to wait, watch and revisit this topic if and when an instant messenger remote shell exploit surfaces.

Introduction

Let’s assume we need to do the dataflow analysis in a particular execution path in a certain binary. In order to collect as much data as possible, we should single-step a certain execution path, save registers values in each step, and then do some analysis. If we have all registers values, we can deduce values assigned to/from memory locations, by looking at instructions semantics.

Available methods

Let’s focus on the first stage: single-stepping. We have the following methods:
Method 1. win32 API debugging facilities
We can do it in an “official” way, that is:

• attaching a debugger
• forcing single-stepping by setting TF bit in eflags
• collecting register values each time on return from WaitForDebugEvent()

However, it is hopelessly slow, because a context switch is necessary after each instruction, and the debugger needs to issue a few system calls to retrieve context and resume execution.

Method 2. In-process EXCEPTION_SINGLE_STEP trapping
A better way is to trap EXCEPTION_SINGLE_STEP not in the debugger, but in the analyzed process itself. We can set up a SEH, and in the SEH handler collect necessary data, and later resume the execution. We can inject into a process a dll which will do the necessary preparations. The “sha1sum_test.exe” binary, if given a second argument, will execute the critical loop with TF set in eflags, and an exception handler will be called after each instruction.The speed gain is about x10 in comparison with the previous solution. Still, exception dispatching both in kernel and in userspace components imposes significant overhead.
Visit http://www.cybertech.net and you can find more advanced implementations.
Maybe it would be more efficient to implement a fast path in the kernel exception handler (just collect register values and resume execution).

A faster solution

Method 3. [purely in] User Mode Single Stepping
Why do we need TF at all ? If the instruction at address X is about to be executed, we can overwrite the next instruction with “jmp our_handler“. (we will need to make the .text segment writable first). our_handler should

1. switch to a temporary stack; save the registers with pusha+pushf
2. restore the overwritten instructions
3. move the saved registers values to some storage
4. compute where the current instruction transfer the execution; let it be the address X’
5. overwrite X’ with “jmp our_handler“
6. restore registers with popf+popa; restore eriginal esp; return to the next instruction

The tough part is 4. We need the following:

• for instructions which do not transfer control (so, anything besides jmp/jxx/call/loop/ret), we need to know an instruction length. It is easy: we can compute all instructions lengths *before* running a program, store it in some file, which will be subsequently mmapped accessible by our_handler.
• for jmp/ret/loop/”call fixed_addr” we need to add the jump offset to the current address - easy.
• for jxx instructions, we need to consult eflags whether the execution is altered or not - doable.
• if we face a computed call/jump, we could disassemble it on the fly and deduce the target, but it is complicated due to variety of addressing modes of 386. The easier way is to trap to debugger, which will single-step the problematic instruction, and later resume software tracing. The overhead should be small because computed calls/jumps are relatively rare. And we can still simulate the most frequent cases, say “call eax”.
  Additionally, this approach helps when our disassembler cannot recognize a particular instruction.

Implementation

The above functionality has been implemented in “umss” project, in McAfee labs. The package contains the following components:

• umss.cpp: it is supposed to write a map of instructions lengths. It uses the “boomerang” project (http://boomerang.sourceforge.net/). In fact, if we just need to get instructions lengths, any disassembly library would do; however, boomerang is unmatched when it comes to analyse instructions semantics (the said analysis is still to be implemented).
• inject.dll: it is a library to be injected into any process. It implements single-stepping. If it does not know how to handle a particular instruction, it jumps to “\xcc”, and the attached debugger takes care of it.
• tracer.cpp. It implements the rest of the required functionality.

In order to collect some benchmarks, a simple program was written which runs a loop a given number of times. It can be traced with umss, or, if given two arguments, trace itself with method II. Results:

• native run (without any tracing):
  ret=-787054544, time=0.047312ms, loops/ms=211361.374858
• tracing with EXCEPTION_SINGLE_STEP handler (two arguments given to the test program):
  ret=-787054544, time=1085.968872ms, loops/ms=9.208367
• ordinary tracing with WaitForDebugEvent():
  ret=-787054544, time=9999.467773ms, loops/ms=1.000053
• umss:
  ret=-787054544, time=95.365204ms, loops/ms=104.860050

As we see, umss method is about 10 times faster then exception handler, and over 100 faster than the ordinary debugging.
All the execution times were obtained with disabled storing of register values (only the overhead of tracing was important). Anyway, in umss the log file is memory mapped, so especially in case of a SMP (or dual-core) system the performance impact imposed by disk writes should be minimal.Additionally, in order to improve the efficiency, we do not want to trace through library calls (well, it should be configurable which dll we want to trace). If inject.dll observes that the execution leaves the .exe segment, it will overwrite the return address location with its own handler and execute t he library function without tracing; when the library function returns, tracing resumes.

Currently the umss package is in early stage, just enough to confirm usability of the approach and conduct benchmarks. It should be straightforward to implement simple enhancements:

• implement more computed jump/call instructions
• currently only a single executable section map is supported
• implement injecting the dll upon LOAD_DLL_DEBUG_EVENT of a library we want to trace
• perhaps optimize inject.dll better. The interesting part is that it should execute only ca 80 own instruction (per each instruction in the traced process) in a typical case, yet the performance hit is x2000. Probably the parallelism of Pentium is affected, as well as memory caches efficiency.
• finally, implement the crucial part: flow analysis

The umss package can be downloaded from Sourceforge umss download page

This week, Secunia and SecurityFocus published advisories on a Microsoft Windows Active Directory vulnerability. Reportedly, a remote attacker could deny service to vulnerable machines by exploiting this vulnerability.

Not much more is public about this flaw. Nonetheless, the flaw’s publication date is conspicuous: it was published on November 14, which coincides with Microsoft’s November Patch Tuesday.

I’ve called attention before to what may be a trend for vulnerability disclosure. Security researchers might be releasing Microsoft vulnerabilities on or just after a Patch Tuesday to maximize the vulnerabilities’ window of exposure. The November 14 Windows Active Directory vulnerability is yet another curve-fitter in this trend!

This month, Microsoft has patched 13 vulnerabilities. Among them is one that can be used to create a worm targeting Windows 2000 systems. The MS06-070 Workstation Service vulnerability can be remotely exploited without user interaction. On Windows 2000, no authentication is needed when sending traffic to this service. Details on this vulnerability have been published.
The vulnerabilities in Internet Explorer DirectAnimation.PathControl AxtiveX object and in XML Core Service, both exploited in the wild, have been addressed in this month’s patch cycle.
The update of our graphs of last month is found below. The graphs show that Microsoft is continuing the trend of patching a large number of critical vulnerabilities each month.

The threat landscape is constantly changing, and our technology must adapt and change as well. Long gone are the days when malware authors were primarily novice coders (or script kiddies). Today we see evidence of the rise of organized crime in malware creation, where development teams are creating malicious software, testing it, automating its production and release. Sophisticated techniques such as polymorphism, the recurrence of parasitic infectors, rootkits, and automated systems with cycling encryption releasing new builds constantly are becoming more prevalent. Furthermore, it is difficult to remember the last time I worked on a sample that was not packed or encrypted, or obfuscated in some attempt to disguise its nefarious purpose. There are many examples, but some stand out in my mind: w32/Stration, w32/Bacalid, and w32/Polip.

The increase in sophistication signals an acceleration of the ongoing arms race between malware authors and security research organizations. IT Organizations must constantly upgrade, patch and deploy the latest software and fixes to keep their networks secure. The release of the 5100 AV Engine by McAfee is a major weapon in the arsenal of McAfee customers for fighting malware. The 5100 engine has upgraded capabilities which allow Avert Labs researchers to more effectively detect new malware generically, or old malware that has been obfuscated. Our internal testing data indicates that the 5100 engine may provide as much as 30% improved detection performance over the 4400 engine. This 30% is provided by the 5100 engine’s capability to deobfuscate the malicious code.

This is proactive detection, provided by McAfee’s newest weapon in the fight against malware.

Avert strongly recommends anyone using McAfee AntiVirus or AntiSpyware products to upgrade to the latest engine.

Further Information and Engine Download Here

Microsoft recently posted Security Advisory (927892) for a critical vulnerability in Microsoft XML Core Services. This vulnerability was discovered in the field and allows for remote code execution. This equates to another means for drive-by attacks via Internet Explorer. Exploitation is not believed to be wide spread at this time, but we can expect exploit code to become public early in the week at which point exploitation will pick up exponentially.

Workarounds include setting the kill bit for the XMLHTTP 4.0 ActiveX Control and modifying Internet Explorer’s security settings. For more information, see:
http://www.microsoft.com/technet/security/advisory/927892.mspx

McAfee Avert Labs is currently analyzing this threat.

In my last blog entry I talked about the consequences of Microsoft’s policy of releasing security updates only once a month. Is this encouraging exploit writers to release zero-day Microsoft exploits soon after a month’s Patch Tuesday to maximize the vulnerability’s window of exposure? Yesterday, on 24 Oct 2006, exploit code was released for a Microsoft Internet Explorer (IE) vulnerability. This proof-of-code code could cause denial-of-service (DoS) in IE. Avert Labs is investigating this exploit further.

Patch Tuesday next month falls on November 14. So this IE bug’s potential window of exposure is at least three weeks…

It was only a matter of time, but the first security ISV has publicly announced a product that bypasses PatchGuard. Authentium, announced today that their Authentium ESP Enterprise Platform can bypass PatchGuard. In a world where less than 1% of known threats exploit the kernel in a way that PatchGuard will block, and where only 15 of 264 (less than 6%) Microsoft vulnerabilities from 2004-2006 would have been protected by PatchGuard, according to our calculations, I’m not sure whether to laugh or cry.

Patchguard is an attempt to close a software hole with more software. As Joanna Rutkowska has amply proven, there is no software-only solution to the rootkit problem. Hardware solutions, like Intel’s Vanderpool or AMD’s Pacifica are required to harden PatchGuard to the point it cannot be broken, but they will not be widely spread in the field for years to come. And in closing one small hole, it’s opening a host of others, like those addressed by the behavioral, anti-rootkit technology, and HIPs features we, and other vendors, have been working on for years. Arguably, our solutions are not immune to this same problem, the difference being that instead of one solution from a newbie security vendor, consumers today can deploy multiple solutions from many seasoned vendors to create a layered defense strategy, even at a desktop level.

So in the meantime, MS is going to try to put their fingers in the dike of PatchGuard holes, which are more valuable to security vendors than to malware authors, who can just avoid the kernel structures MS is trying to protect. In many ways, this is the final manifestation of the logical conclusion I came to when Greg Hoglund first announced his NT rootkit: We are, and always have, been locked in an arms race with the malware authors and hackers. Microsoft has just taken away our most effective weapons.

Microsoft is putting McAfee, Authentium, Symantec, Sunbelt and the rest of the security community in the interesting position of having to tell our customers that we can’t protect them beyond a reactive AV signature without “hacking” their operating system. So if we can’t protect them, and Microsoft can’t protect them (and won’t let us), what are consumers and enterprises to do? Right now, security vendors and Microsoft are in a very public standoff. It will be interesting to see what happens when Microsoft’s own customers chime in on this issue. What do you think?

Today Microsoft patched 26 vulnerabilities, a record high since their monthly patch cycle started. Among the patched vulnerabilities are the 0-Day vulnerabilities in Word and PowerPoint that have been used in targeted attacks against large enterprises. The vulnerability in the WebViewFolderIcon ActiveX object that allows for Internet Explorer drive-by-install and drive-by-download attacks, has been patched as well. None of today's patched vulnerabilities has been tagged as a worm candidate.

The anticipated remediation of the vulnerability in the DirectAnimation.PathControl ActiveX object in Internet Explorer did not see the light yet.

The update of our graphs of last month is found below. The graphs show that Microsoft has continued the trend of patching a large number of critical vulnerabilities each month.

To follow up on my Another Day, Another 0-day post; today (Sep 27, 2006), Microsoft has released a security advisory for this vulnerability:

Microsoft Security Advisory (925984)
Vulnerability in PowerPoint Could Allow Remote Code Execution

The following versions of PowerPoint are affected:

• PowerPoint 2000
• PowerPoint 2002
• PowerPoint 2003
• PowerPoint 2004 for Mac
• PowerPoint v. X for Mac

CVE-2006-4694 was assigned for this vulnerability on Sep 11, 2006.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4694

Today Microsoft patched 3 vulnerabilities. The vulnerability that is rated important, (MS06-052) “Vulnerability in Pragmatic General Multicast (PGM) Could Allow Remote Code Execution “, can be remotely exploited without user interaction. However only Windows XP systems that have the non default Microsoft Queuing Service (MSMQ) installed are vulnerable. Administrators who have installed MSMQ are highly recommended to install the MS06-052 patch as soon as processes allow. The other two vulnerabilities require user interaction for an attack to succeed.

The update of our graphs of last month is found below. The graphs show that September is usually a month with a few or no patches.

MySpace is full of people who'd like you to try their wares. If it's music or comedy, so much the better. Beware, though, as you may also get something more nefarious. In addition to the two MySpace viruses this year, there are now two reports of MySpace being used to increase installations of adware.

The most recent report is of an ad that was placed on MySpace, which used the WMF exploit which was patched in January (MS06-004), to install adware. Earlier this month, it was found that another company had created profiles on MySpace in order to increase installs of their adware.

Again, we run into the difficulties in balancing functionality and security. There's really nothing to prevent profiles being created for questionable purposes. And in further searching, it actually appears that at some point in the past there were quite a few sites that were linking to Zango downloads, not just those connected to video clips. One such member's page is very clear about his intentions - he's part of the affiliate program, and he's trying to make some money.

Unfortunately, this behavior is explicitly forbidden in the MySpace Terms of Use Agreement. His account has apparently been terminated since posting that request for downloads. Other users have been more fortunate (perhaps they took it down before they were caught, but not before Google could index it!) while links to adware downloads have been removed from their profiles, the rest of their profile is still available.

Also in the Terms of Use Agreement is the caveat that MySpace may require you to download software or content in order to participate in certain services. The update to the video player could be considered one of these things. It could be considered quite confusing for certain users to know which downloads for video players are legitimate, and which are unapproved.

An epic transformation in the world of security is upon us. Today, we released the first issue of our semi-annual security magazine Sage. We will leverage this communication vehicle to deliver meaningful and sometime raw content to the masses. We take our responsibility to protect the public from malicious malcontents very seriously and will not shy away from difficult content or taboo topics. Instead, we will share with the world our day-to-day fight and let you decide how important the concepts being broached are to you.

The premiere issue examines the use of open source by the malware writing community. We show the pivotal role that code sharing and full disclosure have played in the evolution of the threat environment, and we anticipate a surge in malware quality and reliability as the malware writers become more professional. Though open source cannot be blamed for how some unsavory individuals may choose to use its tools, techniques, and methodologies, the movement should acknowledge that there are dangers associated with some of its fundamental beliefs.

Sage is meant to be a forum for thought leadership and serious discourse on topical security issues. By drawing on the Labs wealth of data and expertise, and writing challenging security articles, we hope to provoke important discussion about the digital battlefield we have found ourselves in.

Get Sage now from the McAfee Threat Center site:

http://www.mcafee.com/us/threat_center/white_paper.html

Four variants of working Linux/Exploit-PRCTL code has been made available to the Internet over the past 4 days. All of these variants takes advantage of a bug in core dump file handling within Linux Kernel 2.6 that enables local non-privileged users to write into the cron.d folder which they would not normally have write access to. For those unfamiliar with the Linux operating system, the cron.d folder is the Windows Task Scheduler equivalent where tasks or files residing within will be executed on a schedule. To make it relevant, tasks executed in this folder will have privileges of the cron service user - typically root.

This is not the first malware to exploit a Linux kernel vulnerability to gain escalated privileges. But it must be one of the most potent ones in a long while. Despite being limited to only local users, running one of the many vulnerable PHP scripts on a Linux web server could mean quick remote access for those with a malicious intent. One would expect it to be very popular with hackers and PHP worm authors.

Linux 2.6 users should update to the Linux 2.6.17.4 stable release.

Today Microsoft addressed 18 vulnerabilities of which 14 are rated critical. One of the critical vulnerabilities, (MS06-035) Mailslot Heap Buffer Overflow vulnerability, can be remotely exploited by an anonymous user on Windows 2000 SP4 and Windows XP SP1. This vulnerability is the only worm candidate among the patched vulnerabilities today.
The update for our graphs of last month is found below. The top graph shows that this year Microsoft has already addressed more critical vulnerabilities than in the whole of 2005. The bottom graph shows that the number of important vulnerabilities has not changed significantly.

McAfee Avert Labs has given three of the vulnerabilities patched today a rating of High while the others have received a rating of Medium. The ones with a McAfee rating of High are the worm candidate, (MS06-035) Mailslot Heap Buffer Overflow vulnerability, and the Excel and Office vulnerabilities for which exploit code has been published, (MS06-037) Excel Malformed File Vulnerability and (MS06-038) Office Malformed String Parsing Vulnerability.

No need to remind you to review your deployments now!

If you have the feeling that Microsoft could be addressing more critical vulnerabilities, you may be right. Avert Labs has counted the number of vulnerabilities rated Critical and Important over the last 2 1/2 year and plotted them cumulative by year:
The top graph shows that this year Microsoft has already addressed as many critical vulnerabilities as in the whole of 2005. The bottom graph shows that the number of important vulnerabilities has not changed significantly.

Last week we wrote that we may see the start of a vulnerability growth trend fueled by bounty programs and organized crime. While too early to tell, the statistics indicate that Microsoft seems to be addressing an increasing number of critical vulnerabilities.

Last week, Microsoft announced that it had received a single report for a new 0-day vulnerability involving Excel. A malicious spreadsheet was attached to an e-mail and sent to a targeted victim. Various information is available from Microsoft and an interesting FAQ is also available on the Securiteam blog:
http://blogs.technet.com/msrc/archive/2006/06/16/436174.aspx
http://www.microsoft.com/technet/security/advisory/921365.mspx
http://blogs.securiteam.com/?p=451

Today, this threat has been deemed Low-Profiled due to media attention. FrSIRT has also posted an announcement at http://www.frsirt.com/english/advisories/2006/2361.

According to various reports, the original file is named okN.xls. Supposedly when a user opens the file the software unexpectly closes and some binary files are dropped in the Windows System directory as well as the system root directory.

I have studied a sample. It had a 127,488 byte size. On my French system, the file had a long name with semi-graphical ASCII characters possibly of Asian origin. After I renamed the file and opened it on an English Microsoft Excel 2000 version running on a Windows 2000 environment, the expected exploit did not occur. The filename visible on the left and high corner of the window indicated to me that the file was partially loaded, but no spreadsheet was visible. When I attempted to close Excel, I received an application error message saying some memory address could not be read. I made another test on a Windows XP-PRO (French) environment and with Excel 2002. This time an error message appeared and the file could not be loaded.

My colleagues also tested the file in a Japanese environment with the same disappointing results. We suspect that the exploit is more specifically crafted for Excel 2003 running on a specific OS version. It perhaps uses hardcoded return EIP offsets.

Despite these problems, the XLS file and its embedded downloader are detected as downloader-AWV.dr and downloader-AWV.

Over the past few years we have seen a shift in the primary motivations behind the creation of viruses and trojans.  Personal challenge, peer praise, and prank value used to be main driving factors in the creation of malware.  Today, it's money.

So are we seeing the start of a similar trend in vulnerability land?

Yesterday, Microsoft released 12 patches to cover 21 vulnerabilities.  Brian Krebs blogged that iDefense paid out the advertised $10k to hacker who discovered one of the critical vulnerabilities.  He also states notes that "software flaws identified or purchased by TipppingPoint and iDefense made up 6 of the 21 flaws".  Both iDefense and TippingPoint have publicized vulnerability research incentive programs.

In the past, there has been a perception among some vulnerability researchers that iDefense and other companies will not pony up the promised prize for their work.  Now that this is happening in a public way (see below), others may be more encouraged to try and cash in on the opportunity.  It's a little early to say that this is the start of a vulnerability growth trend, driven by money, but the ingredients are there.

iDefense Vulnerability Contributor Program awards paid:

• Q4 2005 $41k paid in VCP awards
• Q3 2005 $39k paid in VCP awards
• Q1 2005 $21k paid in VCP awards
  

Introduction

We should start with a description of C++ virtual functions implementation; fortunately, there are many articles (particularly this one) which explain it well. Some advanced issues, for instance the multiple inheritance implementation, are described here .
Short summary: if a C++ class contains at least one virtual function, then for each object of this class, the memory chunk allocated for this object contains a pointer to this class virtual function table (vftable for short). On x86 architecture, if the ecx register points to the object variable (so, ecx equals "this" pointer), then a call to this object's third virtual function can be implemented like this:
mov eax, [ecx] ; load eax with a pointer to vftable
call [eax+8] ; call the third function in the table


Why bother to detect vftables?

There are a couple of reasons why detection of vftables can be useful for binary analysis:

• Because vftables can be stored within .text segment, a disassembler may try to treat it as code. Particularly, IDA sometimes does this; as a result, it produces functions containing weird opcodes, for instance:
  sbb (byte_7D3939FF-7D393A7Dh)[ebp], bh
arpl [edx-79D682D4h], ax
If we knew what regions are occupied by vftables, we could instruct IDA not to disassemble them.
• Another usage is related to binary matching of different versions of the same code ( here you can learn more on what binary matching/binary diffing is about). From now on, we assume the debugging symbols are not available.Let's assume that we have already matched a certain number of functions from binary A with functions from binary B (say, we have matched functions with identical bodies, or with identical sets of called imported functions). If
  • a certain function funcA from binary A is present in only one vftable vftA,
  • a certain function funcB from binary B is present in only one vftable vftB,
  • we have already matched funcA with funcB

  then we may safely assume that vftA and vftB refer to the same class; therefore, we may match all members of vftA with respective members of vftB. Similarly, if we have matched class constructors, we can match all members of respective (referenced in the constructor) vftables.The above method has some advantages when compared with other matching algorithms. Particularly, it can reliably match functions which have few/none distinguishing features - all we need is its offset in vftable.

How to locate vftables?

In order to locate a vftable, we may use the fact that the vftable address is explicitely used in a constructor - as a part of object initialization, a constructor stores vftable address within the memory chunk allocated for an object. Therefore, the algorithm looks like this:
simple_vft_loc:

• find all occurrences of "mov [reg+small_const_offset], some_const_val"
• for each "some_const_val",
  • check whether it is a correct address within a binary boundaries
  • If so, extract the DWORD pointed to by some_const_val; let's name it FPTR.
  • Check whether FPTR is a valid pointer into an executable segment, and if it points into something resembling code, not data

  If all above steps succeed, then assume "some_const_val" is a beginning of vft, and a "mov" instruction referencing it belongs to a constructor.

Does it really work?

In order to test the above algorithm, let's run it on a binary for which the debugging symbols are available: this way, we will be able to compare this algorithm's results with .pdb file contents. In case of VC compilers, C++ mangled names of vftables start with "??_7″ prefix, so we can easily extract all vftable entries from the output of any .pdb parser.We have chosen mshtml.dll for our test drive (I bet some of you share the idea that it makes sense to examine this particular binary in some detail). For mshtml.dll version 6.0.3790.2577, mshtml.pdb contains 886 vftable names; they point to 763 different vftables. Simple_vft_loc outputs 768 addresses which are supposed to be vftables. It turned out that 28 vftables were not detected ("false negatives"); mostly because some static objects variables contain a preinitialized vftable pointer (so, the vftable pointer is not set by a constructor, it is set by the linker). On the other hand, 33 addresses were "false positives": they pointed to variables which were not actually vftables, they just happened to start with a function pointer.

As we see, the false negative ratio is below 4%. Moreover, it is very probable that in a binary we would match our mshtml.dll with, the matching vftable would not be detected as well. Therefore, vftable detection false negatives should not impair the matching algorithm.

The false positive ratio is similarly low. Again, it should not lead to errors in binary matching - instead of matching vftable entries, we will match entries in other structures containing function pointers.

The simple_vft_loc algorithm was integrated in the "funcmatch", a binary matching tool, and so far, its performance is very satisfactory.

Other tables of functions?

Another common construction containing function pointers is a RPC dispatch table. An approach very similar to the above, using dispatch table detection, was implemented in the funcmatch tool as well.

The SANS Institute issued an update to its list of the Top 20 Internet security vulnerabilities. Even if Internet Explorer and Microsoft dominate the list, the institute warned about significant security flaws in Mozilla Firefox and Mac OS X.

The study also notices continuing discovery of multiple zero-day vulnerabilities. One possible explanation is that cyber crime has become so lucrative that huge sums of money are being spent to sponsor research to find more flaws. Many vulnerabilities being found make their way into zero-day attacks often utilizing zombies with lucrative adware, spyware or other potentially unwanted program downloads.

Another trend is a rapidly spreading scourge of successful spear-phishing attacks, especially among defense and nuclear energy sites. SANS spoke about disciplined attackers located in hostile nation-states and targeting US, British, and Canadian government agencies, contractors, and companies.

Today Microsoft patched 23 vulnerabilities of which 15 are rated critical. One of the critical vulnerabilities, (MS06-040) Service Server vulnerability, can be remotely exploited by an anonymous user on all Windows operating systems and has been labeled a worm candidate.
The update of our graphs of last month is found below. The top graph shows that this year Microsoft has already addressed more critical vulnerabilities than in 2004 and 2005 combined. The bottom graph shows that the number of important vulnerabilities has not changed.

This month 11 patched vulnerabilities were already public or were already exploited in-the-wild prior to today's announcements. Among them is the vulnerability in Powerpoint that was exploited in targeted attacks in mid-July.

No need to remind you to review your deployments now!

Once again, in the name of “software security”, exploit code has been posted publicly that targets an unpatched Microsoft Internet Explorer (IE) vulnerability. This has been labeled as a 0-day exploit, but the first public release of this vulnerability happened on July 18, during a well known vulnerability researcher’s “Month of Browser Bugs” bloganza. The original proof of concept code posted to the blog resulted in IE crashing. The code released yesterday and today allows for the execution of arbitrary code.

I contend that a public exploit released 2+ months after the initial 0-day attack can not be considered a 0-day.

Of course in the real world, it doesn’t make much difference. As I write this blog entry, Microsoft hasn’t yet acknowledged this threat, but I suspect that we will see some information soon, only 72+ days after the 0-day attack was made public. Call it a 0-day, or call it a 72nd-day, either way users are still vulnerable.

That said, the odds of being attacked by this threat were extremely low two days ago. Now that exploit code has been served up on a platter for the bad guys to use, we can expect many attacks for some time to come.

Why is it that some vulnerability researchers feel victorious upon the release of a vendor patch, when it comes at the expense of so many innocent victims? Or maybe this really isn’t about making software more secure.