4 X Security Team

Microsoft shipped four high-priority security bulletins today with patches for at least eight code execution vulnerabilities affecting millions of Windows computer users.

The September Patch Tuesday updates, all rated “critical,” correct security flaws in the Windows Media Player, the Windows Media Encoder, Microsoft Office and the Microsoft Windows GDI+ (graphics device interface).

The GDI+ bulletin (MS08-052) documents five different vulnerabilities in the way that GDI+ handles the viewing of malformed images. It is rated critical for all supported versions of Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008 and also affects several OS components, Microsoft warned.

The risks from a successful attack are very high:

These vulnerabilities could allow remote code execution if a user viewed a specially crafted image file using affected software or browsed a Web site that contains specially crafted content.

[ SEE: Critical WMP, MS Office bugs on Patch Tuesday swat list ]Microsoft also shipped a fix (MS08-053) for a remote code execution vulnerability in the WMEX.DLL ActiveX control installed by the Windows Media Encoder 9 Series.

The vulnerability could allow remote code execution if a user views a specially crafted Web page. If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

The Windows Media Encoder bulletin is rated “critical” on supported/affected editions of Microsoft Windows 2000, Windows XP and Windows Vista. On Windows Server 2003 and Windows Server 2008, it carries a “moderate” severity rating.

The Windows Media Player 11 (WMP) software is also updated (MS08-054) to fix a remote code execution vulnerability in the way that audio-only files streamed from a Windows Media Server in a server-side playlist are handled.

An attacker could exploit the vulnerability by constructing a specially crafted audio file that could allow remote code execution when streamed from a Windows Media server using Windows Media Player 11. An attacker who successfully exploited this vulnerability could take complete control of an affected system.

The fourth bulletin (MS08-055) fixes a protocol handler flaw in the way that Microsoft Office handles URLs using the OneNote protocol handler (onenote://).

The vulnerability could allow remote code execution if a user clicks a specially crafted OneNote URL. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

Microsoft’s response to this issue provides a neat behind-the-scenes look at the company’s response process.

On the SWI team blog, Jonathan Ness explained that an external researcher reported the OneNote vulnerability as an “information disclosure” problem that required an “important” bulletin/fix.

However, as part of Microsoft’s response process, the product teams are required to audit the code to look for additional problem areas:

When we dug into the vulnerability during our ‘hacking-for-variations’ investigation, we found that OneNote used mso.dll to process parameters passed in via the protocol handler. More investigation turned up a buffer overrun vulnerability in mso.dll that could be triggered by passing arguments to the onenote:// protocol handler. Now the case’s severity rating was bumped up from Important to Critical with the effect being changed from Information Disclosure up to Remote Code Execution.

Ness said the the vulnerable MSO.dll is used by almost all versions of Office and some developer tools for shared Office functionality which means that the the MS08-055 shipped a patch for all computers with OneNote 2007 installed (the external information disclosure report) and also all computers that have Office 10, 11, or 12 (due to the internal find).

See our previous coverage of protocol handler security issues:

Command injection flaw found in IE: Or is it Firefox?

Microsoft should block that IE-to-Firefox attack vector

Mozilla caught napping on URL protocol handling flaw

Protocol abuse adds to Firefox, Windows security woes

Mozilla fixes its end of URL protocol handling saga

* Image source: Paul Keller’s Flickr photostream (Creative Commons 2.0)

[Source: zdnet]

The WordPress patching hamster wheel keeps on rolling and rolling.

According to an advisory from maintainers of the open-source blog software, WordPress 2.6.2 was released on September 8 to mitigate a new attack vector discovered by PHP security guru Stefan Esser.

From the announcement:

• Stefan Esser recently warned developers of the dangers of SQL Column Truncation and the weakness of mt_rand(). With his help we worked around these problems and are now releasing WordPress 2.6.2. If you allow open registration on your blog, you should definitely upgrade. With open registration enabled, it is possible in WordPress versions 2.6.1 and earlier to craft a username such that it will allow resetting another user’s password to a randomly generated password. The randomly generated password is not disclosed to the attacker, so this problem by itself is annoying but not a security exploit. However, this attack coupled with a weakness in the random number seeding in mt_rand() could be used to predict the randomly generated password.

[ SEE: Flaw trifecta kicks off Month of PHP bugs ]

WordPress developers said the attack is difficult to accomplish but, because of the associated risk, the patch is being released.

It’s important to note that other PHP applications are vulnerable to this class of attack.

[Source: zdnet]

The first security patch for Google’s new Chrome browser is out, fixing at least two “critical” vulnerabilities that put Windows users at risk of code execution attacks.

[ SEE: Google Chrome vulnerable to carpet-bombing flaw ]

The patch, which is rolled out automatically via Chrome’s auto-update feature, also addresses two additional security vulnerabilities — the carpet-bombing issue and a denial-of-service flaw that could lead to browser crashes and data loss.

From the release notes:

• Fixes a buffer overflow vulnerability in handling long filenames that display in the “Save As” dialog. This is a critical risk that could lead to execution of arbitrary code. See here for fix details.
• Fixes a buffer overflow vulnerability in handling link targets displayed in the status area when the user hovers over a link. This is a critical risk that could lead to execution of arbitrary code. The issue was reported privately to Google. Fix details here.
• Fixes an out of bounds memory read when parsing URLs ending with :%. This is a low risk that can be used to crash the entire browser, possibly causing loss of data in the current session. Fix information here.
• The update also changes the default Downloads directory if it is set to Desktop to ensure that Desktop cannot be the default. This mitigates the risk of malicious cluttering of the desktop (aka carpet bombing) with unwanted downloads, which can lead to executing unwanted files.

[ SEE: Google Chrome vulnerabilities starting to pile up ]

Curiously, user agent for the fully patched version of Chrome (version 0.2.149.29) is still showing WebKit 525.13 (Safari 3.1) , meaning that Aviv Raff’s two-click PC takeover vulnerability is still unpatched.

I just tested Raff’s proof-of-concept that combines two flaws — one in Safari and one in Java — and was still able to execute code without warning. Strange.

[Source: zdnet]

If you have a social networking account, you are aware that spam has moved to that media. Each social network is scrambling to deploy technologies and policies to prevent spam from becoming as endemic their platforms as it is in the e-mail space. All of the networks are being hit by a similar technique known as “friend request” spam. Two social networks in particular, Facebook and Twitter, are quickly becoming a study in contrasts in how to handle the problem.

Before we can describe how they are behaving differently, we need to define the problem. Spam is simply a message in the e-mail world that appears in the inbox without request. The content of the message contains all that is needed for the spammer to sell their product or push malware. In the social networking world, spammers will set up profiles that contain links that point to “spammy” websites, and then send out a large number of friend requests. Recipients that look at the profile behind the friend request have effectively been spammed. A small portion of these individuals will keep the spammers in business by buying whatever the spammer is selling.

Friend request spam is being controlled using many of the same techniques that are being used to combat e-mail. One class of technologies centers around actions that can be taken strictly based upon the behavior of the network connection. For example, large blocks of IP addresses, effectively the identity of the mail servers, are blacklisted by for their misbehavior with the remaining IPs being subject to strict throttling rules that are a function of the server’s recent behavior. For the social networking space, this translates to denying individuals access to the system entirely or throttling, but not banning, accounts based upon their identity.

This is where the contrast come to light for our two social networks. Facebook has taken the approach of automatically deleting accounts of suspected spammers, which they define as having a certain friend-request pattern. Twitter has decided to cap the number of following requests issued by a user, but not delete the account. Facebook took the more aggressive approach of deleting users that trip their spam detection algorithms, translating into irate new users who end up wondering what happened to their accounts.

In many ways, there is no right or wrong to anti-spam beyond what makes end users the most satisfied with their service. Some classes of users will tolerate a little spam in their inbox in exchange for an incredibly small rate of legitimate mail being incorrectly classified as spam, known as false positives. Other users are willing to tolerate a higher rate of false positives as long as their inbox is always clean. Which approach is fundamentally right or wrong is immaterial. Far more important is what will be tolerated by the community. As spam expands into this relatively new domain, all of the players in the field will have to monitor how their reaction to spam is viewed by their most important commodity, namely users and eyeballs.

[Source: zdnet]

The iPhone has vulnerabilities. In the past, some have been very serious. Sometimes, Apple takes a very long time to get them fixed.

The security hiccups have done nothing to slow down the sales and usage of the device so it just might be a good idea to go the extra mile to secure the device and reduce your risk if your iPhone gets lost or stolen.

Wired’s how-to wiki offers some valuable instructions on security your iPhone:

• 1 Enable Passcode Protection
• 2 Enable SIM PIN Protection
• 3 Enable Auto-Lock
• 4 Re-map Your Home Button
• 5 Use a Password Storing App

If you have any other ideas/suggestions, enter them in the comments or, better yet, post them to Wired’s wiki.

[Source: zdnet]

Denial of Service attacks are based upon a simple idea: generate the maximum amount of traffic using the minimum amount of work. At one time this was as simple as sending a spoofed ICMP echo packet to a broadcast address or similar shenanigans. Modern DDoS attacks rely upon the unwilling complicity of tens of thousands of end hosts to generate the traffic necessary to render a host unusable, whereby attackers will either build or purchase a botnet to generate a DDoS attack. There are other ways of generating DDoS attacks, however, that use social networking widgets or the complicity of politically active citizens, as pointed out by researchers at ICS and the ShadowServer group.

In a recently posted preprint titled “Antisocial Networks: Turning a Social Network into a Botnet”, several researchers point out the somewhat obvious: widgets on social networks can be used to launch DDoS attacks against web servers by pointing Javascript XMLHttpRequest() calls, the API call behind AJAX technologies, at a targeted webserver. Rather than compromising individual social networking accounts, an apparently innocuous widget could start propagating virally on a social network and launch the described attack at a time determined by a third party server.

[ SEE: Demo Facebook app creates DoS botnet ]

It is also possible that such a widget could directly declare its purpose. During the recent Estonian and Georgian DDoS event, a simple script was circulated that allowed the average citizen to participate in the DDoS attack. While this particular script required only a small amount of technical expertise to execute, one could easily imagine a viral widget that claimed to allow the average user to fight against a political entity using similar techniques.

At that point, why stop at DDoS? Republicans could install widgets that launched click-fraud attacks against Democrats, and Democrats could do the same to Republicans. I would expect an increase in political-oriented DDoS as the barrier to entry for DDoS drops from the moderately technical to the skill level of an average social network user.

[Source: zdnet]

Do you know what that innocent-looking Facebook app is really doing?

Researchers at the Institute of Computer Science (ICS) have created a proof-of-concept Facebook application capable of covertly herding users of the popular social network into a powerful — and malicious — botnet.

The demo application, called Photo of the Day, delivers a different image from National Geographic everyday but, behind the scenes, special code embedded into the application creates a botnet of Facebook users launching denial-of-service attacks.

In a research paper (.pdf) to be presented at this year’s Information Security Conference, the research group provided technical details of its Facebot:

• [W]e have placed special code in the application’s source code, so that every time a user views the photo, HTTP requests are generated towards a victim host. More precisely, the application embeds four hidden frames with inline images hosted at the victim. Each time the user clicks inside the application, the inline images are fetched from the victim, causing the victim to serve a request of 600 KBytes, but the user is not aware of that fact (the images are never displayed).

[ SEE: Facebook refuses to fix obvious security flaw ]While the proof-of-concept app was used to demo a denial-of-service attack scenario, the group issued a terse warning:

• [An] adversary could employ more sophisticated techniques and create a JavaScript snippet, which continuously requests documents from a victim host overtime. In this way the attack may be significantly amplified.

Interestingly, the researchers made no effort to advertise/distribute its Facebook application but was able to attract more than 1,000 users in the first few days. With a bit of effort to manipulate the viral nature of app distribution on Facebook (the inherent trust of the social network model), a malicious Facebot with tens of thousands of users can do some serious damage.

[ SEE: Web worms squirm through Facebook, MySpace ]

“We have shown that the victim of a FaceBot attack may be subject to an attack that will cause it to serve data of the magnitude of GigaBytes per day,” the group warned.

In the paper, the researchers called on Facebook and other social networks to rethink the way APIs are designed and developed:

• Providers of social networks should be careful when designing their platform and APIs in order to have low interactions between the social utilities they operate and the rest of the Internet. More precisely, social network providers should be careful with the use of client side technologies, like JavaScript, etc. A social network operator should provide developers with a strict API, which is capable of giving access to resources only related to the system. Also, every application should run in an isolated environment imposing constraints to prevent the application from interacting with other Internet hosts, which are not participants of the social network. Finally, operators of social networks should invest resources in verifying the applications they host.

* Hat tip to Dark Reading’s Kelly Jackson Higgins.

[Source: zdnet]