Here's a snort rule to attempt detection of the new setSlice 0-day:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg: "BLEEDING-EDGE
EXPLOIT MSIE WebViewFolderIcon setSlice invalid memory copy";
flow: to_client,established; content:"WebViewFolderIcon"; nocase; content:".setSlice";
nocase; content:"0x7ffffff"; nocase; reference:url,riosec.com/msie-setslice-vuln;
reference:url,osvdb.org/27110; classtype: attempted-user; sid: 1000001; rev:1; ) 

Update: This rule is now included in the Bleeding Snort sigs.

Updated: Fixed link to ThePCSpy and added AV comparatives, an in-depth look at AV detection performance. 

You might want to think about what AntiVirus vendor you are using. Comparisons are in for AntiVirus products for both detections and performance, and the results might suprise you.

For a comparison of performance, check out this article at ThePCSpy.com.

For a detection roundup, check out the roundup at www.virus.gr.

This is starting to sound like a broken record, but there's yet another unpatched vulnerability for MSIE with a public exploit. This one was posted to the browser fun blog on July 18th, and Metasploit just released a working exploit about an hour ago.

If you are still using MSIE, its time to switch browsers. The Internet just isn't a safe place for Internet Explorer right now.

I was able to use this to compromise a fully patched Windows XP SP2 box, as you can see below:

SANS ISC has raised the InfoCon to yellow due to increasing exploitation of the MSIE VML vulnerability I wrote about yesterday. Now is the time to impliment countermeasures. One that I haven't seen other places is that the generic buffer overflow protection in McAfee AntiVirus 8.0i appears to prevent successful exploitation. It is likely that other products that provide similar HIPS functionality also will work.

Be safe out there.

If you havn't been following the news, there is yet another 0-day unpatched vulnerability in Internet Explorer. There are a few differences than with previous vulnerabilites:

• You can get this just by viewing an HTML email
• It is already widely exploited, as it is included in WebAttacker, a "commercial" multi-exploit kit

Here's what we know you can do to protect yourself:

As posted in a article by Bruce Schneier in Wired "Quickest Patch Ever", Microsoft released a patch for their DRM just three days.
According to the Zero Day Initiative, they have three vulnerabilities rated High, and one Medium, that have gone unpatched for over 80 days.
Guess we know what gets Microsoft's attention.

Last week I presented at the St. Louis Security Group, a SIG of St. Louis Unix Users Group. The presentation and demos went well, and I hope everyone enjoyed it. I've attached the PowerPoint file, other forms will be posted soon.

The presentation covers attacking networks using Metasploit and outbound HTTP sessions only. Using this technique, the attacker bypasses any intervening firewalls (and many IDSs).

The bottom line solution: defense in depth.

There's a facinating story at the "Dumb Little Man" blog called "Death by Google Calendar: How I Identified you to rob you". Following the concepts in the article, I was able to search Google Calendar for someone in St. Louis, find the person's apartment address, and where he's going to be for the next month. A crook would then go rob this guy when he's away at that wedding in a few days.

This is an example of why user security awareness education doesn't work. People know that posting personal information online is a bad idea. Because of the complexity of technology, and the many ways that it can be abused, it should be up to providers like Google to write apps that protect people. In other words, I consider this a bug in Google Calendar. There should be a warning, every time you post on a public calendar (which is the default calendar state), that this information is going to the world.