SonicWALL update 26JAN2010 and Mootools issues.
supert3d
this in-case anyone else is going through the same unsettling couple
of hours we just went through.
Our company has a Sonic firewall. The people over at Sonic release
security updates (logical); in particular this one :
SonicWALL - MS IE mergeAttributes Function Invocation (http://
software.sonicwall.com/applications/ips/index.asp?ev=sig&sigid=3099)
This is to patch a known vunerability in; surprise, surprise Internet
Explorer :
http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-0247 (MSDN::
http://www.microsoft.com/technet/security/Bulletin/MS10-002.mspx
(21JAN2010));
Unbeknownst to me this occured at 16:00 yesterday (26th Jan 2010)
automatically.
After receiving a phone call this morning; pretty much to the affect
of : "the website is down", spiraled a series of events that ended up
with me looking for Javascript object/variable conflicts in 3rd party
supplied vendor code.
Using the savior that is Firebug (thank you Joe Hewitt and a dedicated
community) I was quickly able to isolate the problem to a Javascript
runtime error, in this particular case; the Mootools Fx() class.
Because of this 'error' Mootools failed to run/compile and thus began
a progressive series of 'domino effect' events. Mootools didn't
execute window.addEvent('domready',function(){}), our AJAX content
didn't execute and the page simply failed to load ("the website is
down") ... I began having nightmares. Was Mootools now flawed because
of some random browser update?
After quickly testing and noting that every single website I'd created
using the Mootools library was also failing on the corporate LAN I
began to feel a little light-headed. A hasty call to my wife, God
Bless my external tester, quickly calmed my nerves after confirming
everything worked perfectly outside of the LAN. OK, so it's internal
only.
More frustratingly all the code worked flawlessly in our production
environment. At this point I'm thinking firewall. "Any recent
changes?" Turns out there was one... yesterday at 16:00. OK.
I'm not sure entirely what my firewall partner-in-crime did but it
worked, altering the level of action taken on detection of this alert
seemed to re-enable the site. From what I can understand of this
threat is that if the firewall detects attempts to exploit this
Javascript vulnerability it prevents the code from executing, in this
case 'causing Mootools to fail and the website to simply 'not show
up'.
I suspect it's because of our firewall configuration where we actually
have to go outside of the firewall to come back in again. Any AJAX
requests (or in this instance Mootools' new Asset.image() class/
method). Content/Javascript is theoritically going outside of the
firewall only to come back in again, thus 'causing the Firewall to
detect this as a threat. A point possibly confirmed by the fact that
this issue was only noticeable on websites where AJAX methods had been
adopted to render data.
Anywhere; we're back in business, but I figured I'd share in case
anyone else is currently looking for answers to this particular
problem.
Sanford Whiteman
> This is to patch a known vunerability in; surprise, surprise Internet
> Explorer :
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=2010-0247 (MSDN::
> http://www.microsoft.com/technet/security/Bulletin/MS10-002.mspx
> (21JAN2010));
I don't know if "patch" is how I'd describe what these UTM devices do.
They frequently overreact + misreact. Same for those one-size-fits-all
web IPS shims. They need to be very finely tweaked to fit real apps,
and if they lack really granular controls, you have to neuter them
completely. Automatic updates, as you've also found, compound the
problem unless everyone is in on the schedule.
This issue [a] is a CVE candidate, so it should have been in an
"optional" or "aggressive" ruleset (if the device has such settings);
[b] only affects true IE 6- clients, who could be be quite effectively
filtered by User-Agent (again, if the device allowed such
adjustments); and [c] should have been an egress rule, protecting the
traffic source (see below).
> I suspect it's because of our firewall configuration where we
> actually have to go outside of the firewall to come back in again.
If you have a UTM/IPS device, you have to eat your own dog food to
best simulate hits from the outside. It is a best practice to go
through your UTM, and if you were literally going outside to come back
in ingress, that would be perfect.
But my question (or perhaps your description isn't totally clear) is
why internal users sound like they were going through through _egress_
filters instead of ingress filters. You should certainly be filtered,
but you should access the site as if you were a public user; hence,
both inside and outside users should have thought "the website is
down." It should have been _less_ obvious where the problem lay!
Also, bear in mind that everything was not fine in prod depending on
where you were coming from. It was fine if you weren't going through a
SonicWall UTM with the latest untweaked ruleset; if your wife were
behind the same kind of device, you would not have been so assured.
Many people trust Sonic for egress filtering and are still affected
unless they have made similar adjustments. But at least that's their
fault. :)
-- Sandy
Roman Land
As an ex-employee of Checkpoint (the inventors of the Firewall :P) I recommend that you log a call with SonicWall so their R&D team could look into it and make sure this is resolved on their end (where it should be since our code as far as we can tell is legit), otherwise they should tell us what exactly Mootools is doing that is illegal. (I guess that looking at the MS article might also help but I assume that its their own implementation that makes Mootools code illegal)
This kind of security detection is usually in a form of a regular expression that detects certain code combination and is obviously finding a false positive..
So I strongly advice, if your company has support with them, you should log a call with SonicWall and get to the bottom of this.. (also for the community sake :) )
Anyway, congrats on finding and fixing your issue!
Cheers
-- Roman
---
"Make everything as simple as possible, but not simpler."
- Albert Einstein