Microsoft Internet Explorer mshtml.dll createTextRange()

Unanswered Question
Mar 30th, 2006
User Badges:

Is there a signature to cover this one already because if there is my sensors are not seeing it.

I tested against my lab sensors. The exploit was successful and the sensors did not fire an alert. I ran tcpdump to make sure they were actually seeing it for verification purposes.

Any idea when a sig will be available for this? Right now I have to use Bleeding edge Snort sigs.


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)

I asked this same question a few days ago--- The answer to my post was:

Replied by: wsulym - IPS Signature Engineer, CISCO SYSTEMS - Mar 28, 2006, 11:42am PST

Currently, all exploits we've seen and tested have triggered 5477-2. 5477-2 is a generic sig catching suspicious activity in return web traffic. As of this moment, there are no plans on adding anything additional for this vulnerability.

So you're saying your test failed to make sig 5477 fire off as Cisco says it should?

If this is the case, then we are overdue for S223 by a week at least.

ntrngrusr Thu, 03/30/2006 - 18:48
User Badges:

Yes, that is exactly what I am saying. I used Metasploit for the testing. I could not get any signature to fire. Nor did my bloodhound definitions fire for Symantec AV and the exploit was successful. I did a reverse shell and it worked perfectly. I also downloaded and executed a file (calc.exe) and there was no detection by anything. The tcpdump showed the traffic went past the sensor. Not too sure if the signatures are written for the exploit or the vulnerability but from what my testing showed it did not detect it.

d-g-c Fri, 03/31/2006 - 02:37
User Badges:

I'm seeing 5477-2 firing and assumed that it was the IE exploit trigerring it, this is a concern if it's not the case. Why haven't CISCO responded to this particular threat?

I'm interested in how you tested the exploit, can you provide further info?

wsulym Fri, 03/31/2006 - 13:12
User Badges:
  • Cisco Employee,

5477-2 should fire off of this traffic, but why it's not firing could be one of a couple things.

First, retire/unretire 5477-2 (Retire, apply changes, Unretire, apply changes). Might be a config issue and this will force a rebuild of that signature in the regex tables.

Second, it could be that the sensor is seeing compressed traffic. In some instances, as in your case, the modules are defaulting to gzipping the traffic for transparent compression... browsers will transparently decompress this data. When compression is applied, the result is that we have a very high entropy return data stream very similar to an encrypted data stream, largely due to the fact that the underlying data is also mostly random itself. We are aware of this and are working on a solution that

will address it. The solution will require modification to the sensor inspection code and has been added to the enhancement list for a future



This Discussion