Last Wednesday, Microsoft published MS03-043 bulletin about a critical vulnerability in the "Messenger Service" that supplies popup system messages.
Later on Wednessay, ISS shipped a signature for this in our intrusion detection/prevention systems. The signature is called "Win_MessengerPopup_Bo". On Thursday, we received reports that this signature was triggering due to popup spam on the Internet. Prior to the buffer-overflow bug described in MS03-043, spammers had been abusing the Messenger Service. Apparently, some of the tools used to send this spam are causing the signature's anomaly checks to trigger. The "Win_MessengerPopup_Bo" IDS signature, like most ISS signatures, is based upon a protocol-decode of the affected protocol and one or more checks for anomalies in that protocol. In particular, Win_MessengerPopup_Bo checks for two anomalies: * an anomalously long buffer * unnecessary fragmentation The "buffer" anomaly check measures the length of the buffer, and tests it against the threshold where the overflow occurs in the Messenger Service. This is typically how ISS writes signatures for our products. Rather than writing signatures based upon patterns seen in know "exploits", we decode the protocol and check for the conditions that trigger the "vulnerability". Vulnerability-based signatures allows us to ship updates to our products before hackers start using exploits, whereas other IDSs typically wait for hackers to publish exploits before they write signatures. The "frag" anomaly check looks for unnecessary fragmentation that wouldn't be produced by Windows itself, but which is likely to be produced by a hacker exploit. We put that in there just in case something went wrong with the buffer anomaly check. It's not critical to the vulnerability itself, but we put that in there because we know that hacker exploits typically cause lots of other anomalies in addition to the vulnerability they are trying to exploit. Apparently, some spammers are using unnecessary fragmentation when they send out their popup messages. I'm not sure why -- maybe it evades some firewalls that attempt to block spam arriving on port 135/udp. Regardless, customers with external ISS IDS products will see the anomaly trigger due to popup spam. This spam seems to consistently trigger with the "FRAG-LENGTH" field is equal to 1024. This field can be seen whe viewing the event "Details" on the console. (The event "details" screen shows fields that the protocol-decode engine has extracted from protocols). Customers may be interested in triggering on these anomalous spam messages, but for those that don't, we recommend that they set the tuning parameter "pam.win.messengerpopup.checkfrag=off". The signature will still trigger on the vulnerability, but this additional anomaly check won't cause it to trigger on popup spam. We aren't going to rush an update to fix this one issue -- but this will be changed in the next XPU (express update) scheduled in two weeks. More information about this can be found in our X-Force alert describing the vulnerability: http://xforce.iss.net/xforce/alerts/id/156
<<winmail.dat>>
