Hi, 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 On Wed, Jan 27, 2010 at 10:21 PM, supert3d <[email protected]> wrote: > OK, interesting little issue we came across today. Figured I'd share > 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<http://www.microsoft.com/technet/security/Bulletin/MS10-002.mspx%0A%2821JAN2010> > )); > > 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. > > > > > > > -- --- "Make everything as simple as possible, but not simpler." - Albert Einstein
