Feature Request: treat JavaScript like other plugins

[Alan Baxter]

That reads as though in this particular case aspirant believes that JS needs to be blocked before navigating to the plugin, if the plugin is to possibly work to aspirant's satisfaction.

Hm, I didn't read it that way. I could be wrong, but I got the impression that aspirant wants to allow JavaScript on all sites and allow plugins only on sites that are in the whitelist, such as the Netflix site. http://forums.informaction.com/viewtopi ... 073#p11073

[Giorgio Maone]

I can see the value of this proposal and, incidentally, it will be possible in the context of the main change planned in 2.x serie, i.e. granular per-site permissions with configurable defaults.

[Tom T.]

Install one of the free products by Comodo for protection against all buffer overflow errors: Internet Security or Comodo Firewall, see http://www.comodo.com/home/free/free-protection.php
Go to the menu Defense+|Advanced|Image Execution Control Settings|Detect shellcode injections to confirm it is enabled.

I didn't see such a menu choice on the page that was linked.

My opinion of Comodo is dropping more:

Comodo Firewall Pro introduces the next evolution in computer security: Default Deny Protection (DDP™). What is DDP? Most security programs maintain a list of known malware, and use that list to decide which applications and files shouldn't access a PC. The problem here is obvious. What if the list of malware is missing some entries, or isn't up to date? DDP fixes this problem to ensure complete security. The firewall references a list of over two million known PC-friendly applications. If a file that is not on this safe-list knocks on your PC's door, the Firewall immediately alerts you to the possibility of attacking malware.

A proper firewall blocks all unsolicited traffic, including applications, "knocking on your door". It alerts you of the attempt, unless you tell it not to do so.
Since I'm not running a Web server, I can't imagine any reason I'd ever want any unsolicited traffic.

As far as applications trying to run at a site that you've chosen to visit, hence "solicited", yes, this is pretty much a function of NS as well. But they admit the problem with their own approach: Relying on a third-party blacklist OR a third-party whitelist is unreliable. As you and I have agreed, each user's needs and security preferences are different -- and no such list can be constantly up-to-date. Many, many attempts have been made to take the user out of this decision-making loop, including having NoScript connect to, or include, such automatic decision-making for you. To those people, I would ask to watch, or re-watch, the 1985 movie, "WarGames". Taking people out of the loop is a bad idea. Computer users, drivers, pilots, all of life require individual decisions based on individual circumstances. NS allows you to forfeit that control, and that's your choice. I don't want my firewall "deciding", I want it asking -- *especially* when an app inside the machine is requesting outbound access. Although ZoneAlarm isn't perfect, it gives me that control, per application, per occasion (or permanent permission for applications such as your browser).

I saw some of the forum material on their BO protection and superiority to DEP. Also, many complaints of it causing problems, which happens to all apps. There was a mistake when someone said that Windows allows some known apps to bypass DEP. Only if you configure it that way, or if it's configured that way by default. My suggestions above subject *every* process to DEP, AFAIK, per MS, IIRC.

I d/l and ran the BO Tester. It didn't do anything, so I assume that I'm safe from all of its attacks, even without Comodo. If it wasn't even able to run the tests, I must be even safer.

I have no connection to ZoneLabs either, and use the free version. I'm sure that Comodo has some good features and many satisfied users. Neither is a substitute for NoScript; both a firewall and NS, and AV, are part of good "defense in depth" -- combined with safe surfing practices. Cheers.

[Tom T.]

I can see the value of this proposal and, incidentally, it will be possible in the context of the main change planned in 2.x serie, i.e. granular per-site permissions with configurable defaults.

Which is exactly what I told the OP a number of messages ago:

If you are referring to being able to whitelist plugins on a site-specific basis, that is a feature that has been on the to-do list for a long time, and I believe will be in whenever NS 2.0 comes out.

[Grumpy Old Lady]

That reads as though in this particular case aspirant believes that JS needs to be blocked before navigating to the plugin, if the plugin is to possibly work to aspirant's satisfaction.

Hm, I didn't read it that way. I could be wrong, but I got the impression that aspirant wants to allow JavaScript on all sites and allow plugins only on sites that are in the whitelist, such as the Netflix site. http://forums.informaction.com/viewtopi ... 073#p11073

No, no, no, no .....
Yes. Apologies for the interruption.
I will now return you to your normal programming - the march to a plugin blocker for the 21st Century :-)

[Aspirant]

I could be wrong, but I got the impression that aspirant wants to allow JavaScript on all sites and allow plugins only on sites that are in the whitelist, such as the Netflix site.

You understand my desire.

I can see the value of this proposal and, incidentally, it will be possible in the context of the main change planned in 2.x serie, i.e. granular per-site permissions with configurable defaults.

I don't want to put any pressure on your kind volunteer efforts, but when do you expect to release the 2.x series? I wait patiently...

I didn't see such a menu choice on the page that was linked.

Sorry for my ambiguity. The menu is inside either of the mentioned Comodo applications.

A proper firewall blocks all unsolicited traffic, including applications, "knocking on your door". It alerts you of the attempt, unless you tell it not to do so. Since I'm not running a Web server, I can't imagine any reason I'd ever want any unsolicited traffic.

I agree with you, and I set the Comodo firewall to "Custom Policy Mode" to achieve this. Comodo aims the default "Safe Mode" toward inexperienced users. I used to use Zone Alarm, but I find Comodo's firewall to be more powerful and flexible. The self protection aspect is very important to me too. See http://www.matousec.com/projects/proact ... esults.php
The CEO of Comodo says that the reason his firewall doesn't reach 100% in the above test is because he has an ethical problem with making his product pass those 3% artificial tests that have no benefit for the user.

My suggestions above subject *every* process to DEP, AFAIK, per MS, IIRC.

The Comodo forum moderator, in referenced post above, indicated that non-Microsoft processes must opt-in to DEP, regardless of the user settings. Do you have any evidence, say from the Event log, that DEP works on a non-Microsoft application that performs a buffer overflow?

I d/l and ran the BO Tester. It didn't do anything, so I assume that I'm safe from all of its attacks, even without Comodo. If it wasn't even able to run the tests, I must be even safer.

The download is an installer. After installing, run the tester from the Start Menu on an admin account. The Comodo application has separate GUI and tester executables. The GUI will indicate pass or fail for each of the 3 types of buffer overflow. If the tester executable is blocked by security software, the GUI will indicate that the test passed. If something on your PC blocked application installation or running of the GUI, I see no evidence that the same something will block the 3 types of buffer overflow.

Neither is a substitute for NoScript; both a firewall and NS, and AV, are part of good "defense in depth" -- combined with safe surfing practices.

I agree.

[GµårÐïåñ]

I have tried to stay out of this discussion for the most part but since I see Netflix mentioned over and over, I wanted to add. I use Netflix and other than the problem that re-arranging the queue will time out as unresponsive with NS in place, there is no other issue. I have mitigated the problem by extending the script timeout which is asinine but it still happens here and there and when it doesn't, I to wait a ridiculously long time for it to complete. I have brought this up several times with several builds and always told its not NS but usually with a future release of NS it gets fixed and then later it shows up again with a new release. I consider it an annoyance and move on but this particular Netflix issue listed here, I am not seeing it.

[Aspirant]

...this particular Netflix issue listed here, I am not seeing it.

I use Windows XP Pro SP3. Do you use Vista? Good that you added your data point so that others know better about how to reproduce the problem.

[Tom T.]

A proper firewall blocks all unsolicited traffic, including applications, "knocking on your door". It alerts you of the attempt, unless you tell it not to do so. Since I'm not running a Web server, I can't imagine any reason I'd ever want any unsolicited traffic.

I agree with you, and I set the Comodo firewall to "Custom Policy Mode" to achieve this. Comodo aims the default "Safe Mode" toward inexperienced users.

100% backwards. Since the overwhelming majority of users never change defaults on anything, defaults should protect novice users most of all. ZA does this. Once again, there might be a five-minute learning curve, but you don't get something for nothing -- including security.

My suggestions above subject *every* process to DEP, AFAIK, per MS, IIRC.

The Comodo forum moderator, in referenced post above, indicated that non-Microsoft processes must opt-in to DEP, regardless of the user settings. Do you have any evidence, say from the Event log, that DEP works on a non-Microsoft application that performs a buffer overflow?

The Comodo forum moderator isn't too well-informed. Will you take Microsoft's word for it?
http://support.microsoft.com/kb/875352
Note that the *default* is what you said -- which is also what *I* said, that DEP was off or defaulted to less-than-full. Note the option on the linked page to "Opt-Out" and "Always On". Will you now agree with my statements, and if so, please enlighten the Comodo moderator?

I d/l and ran the BO Tester. It didn't do anything, so I assume that I'm safe from all of its attacks, even without Comodo. If it wasn't even able to run the tests, I must be even safer.

The download is an installer.

I'm not that stupid. Despite being a forum moderator and support person here, I do actually know the difference between an installer and the application that it installs, but thanks for offering the insight anyway.

After installing, run the tester from the Start Menu on an admin account.

I chose not to create a Start shortcut, but ran it directly from the exe in the Programs folder, since I didn't plan to keep it around anyway.

The Comodo application has separate GUI and tester executables.

That's very strange design. Why doesn't the GUI start the tester? The GUI for every program I can think of has the controls to start the necessary exe's.

The GUI will indicate pass or fail for each of the 3 types of buffer overflow. If the tester executable is blocked by security software, the GUI will indicate that the test passed. If something on your PC blocked application installation or running of the GUI, I see no evidence that the same something will block the 3 types of buffer overflow.

OK, given that they made the GUI functionless, except as a display, will try again. Note that the Steve Gibson tool to which I pointed you has GUI and tester executable combined.

Neither is a substitute for NoScript; both a firewall and NS, and AV, are part of good "defense in depth" -- combined with safe surfing practices.

I agree.

FINALLY!

[Tom T.]

OK, d/l *and installed* BO test, just as before, and this time I let it make its Start menu entry.

BTW, in the Agreement, I clicked on the "Privacy Policy" link, and got a broken-link message. That's scary.

Anyway, it did exactly as before. A box was presented, with the checkblock "run all tests" checked. There was a "test" button, which, presumably, starts the "test". I clicked it, and nothing happened.

In the Programs folder, there is BO Tester.exe, which *does* open the GUI, which *does* apparently allow the user to start the tests, as expected.
There is also botester32.exe, presumably the actual executable of the tests, and which presumably is started by clicking "Test" on the GUI. It's only 3.5 Kb -- very nice and lightweight. Since the GUI wouldn't activate it, I tried 2-clicking it myself -- nothing.

Tried running it from Start/Run command line, and when that didn't work, tried opening an actual command prompt. I could successfully open the GUI, but not the actual botester32.exe.

I must tell you that this machine has had more than 90% of Windows XP deleted from it, getting rid of what's useless and obsolete (like the setup instructions for Win 3.1 from 1991 that you'll find in %windir%\system --- *really*! ), and what I don't need, keeping all functionality that I need, which is everything, really. Lot of bloat in there. But by cutting the Windows folder from 2700 MB to 275 MB, it also cuts the attack surface by 90%. Perhaps some files or libraries needed by botester are among the deleted (I'd have thought they'd have made it self-supporting.) Perhaps said libraries were also vulnerable to the buffer overruns, or were needed to execute them. To be truly fair, when I drag the untrimmed, back-up machine out of its box to get the October MS Updates, I'll try to remember to run BO Tester on it.

But it brings up another interesting point. There are two ways to improve your defenses:
The one everyone looks at is building more walls around your attack surface -- firewalls, AV, DEP, NS, Sandboxie -- all good.

But the other side of the coin is reducing your attack surface, so that you have less to defend in the first place. Cutting Win as much as I did certainly isn't for everyone. But using 3.7 Mb Foxit reader vs. 368 MB Adobe reader, getting old version 2.0 of Foxit without native JS support, or disabling JS in Adobe if you must have Adobe (why?), removing JS support from Open Office text docs, and all other support for embedded executables, deleting all screensavers (obsolete when CRT tubes went out, anyway,) etc.... The less you have to be attacked, the less defense you need, and/or the fewer vulnerabilities you'll have. Food for thought.

Cheers,
Fellow aspirant to knowledge

[Aspirant]

The Comodo forum moderator, in referenced post above, indicated that non-Microsoft processes must opt-in to DEP, regardless of the user settings.

I incorrectly paraphrased Tyler Durden, the Comodo forum moderator, above. He says (I added the italics) at https://forums.comodo.com/frequently_as ... 237.0.html

DEP mode by default is OptIn

There was a mistake when someone said that Windows allows some known apps to bypass DEP. Only if you configure it that way, or if it's configured that way by default.

The Comodo forum moderator isn't too well-informed. Will you take Microsoft's word for it?
http://support.microsoft.com/kb/875352
Note that the *default* is what you said -- which is also what *I* said, that DEP was off or defaulted to less-than-full. Note the option on the linked page to "Opt-Out" and "Always On". Will you now agree with my statements, and if so, please enlighten the Comodo moderator?

Thanks for the Microsoft link. I don't see anything wrong about what Tyler Durden said. I found more info at http://en.wikipedia.org/wiki/Data_Execution_Prevention
In the explanation of the OptOut setting, it says:

Also note that Windows silently disables DEP for certain executables, such as those packaged with ASPack.

Users who control DEP with the System dialog box in Control Panel only have options of OptIn and OptOut. If the user modifies the Boot.ini settings instead to get AlwaysOn to avoid Windows silently disabling DEP for certain executables, then the user cannot whitelist legitimate executables with buffer overflows. I have encountered a few of them.

http://en.wikipedia.org/wiki/Buffer_overflow says (with my clarification added):

Executable space protection [such as DEP] does not generally protect against return-to-libc [buffer overflow] attacks

Note that the Comodo's Defense+ component does protect against return-to-libc, and their tester tests this type of attack.

I too have reduced the attack surface of my PCs by disabling unused services. See http://www.blackviper.com/WinXP/servicecfg.htm
However, removing 90% of the Windows files and using default-deny for JavaScript with NoScript does not provide sufficient protection against return-to-libc attacks for my comfort.

[Tom T.]

If the user modifies the Boot.ini settings instead to get AlwaysOn to avoid Windows silently disabling DEP for certain executables, then the user cannot whitelist legitimate executables with buffer overflows. I have encountered a few of them.

I never have, but if I did, I'd demand that the vendor fix the issue and code the program properly, rather than requiring me to weaken my defenses by opting this particular app out of DEP. If the vendor refused, I'd find another vendor. There's always one.

Also note that Windows silently disables DEP for certain executables, such as those packaged with ASPack.

http://support.microsoft.com/kb/261146

Computer Stops Responding (Hangs) When Opening a Large Local File
SYMPTOMS
If you installed TCP/IP, and you open a large file from your hard disk, the computer does not respond (hang). It may also take a long time for the computer to find a Local Area Network (LAN) resource.

CAUSE
This issue can occur if your computer is infected with the Dunpws.bz virus (also known as a trojan). This virus is a 32-bit portable executable (PE) trojan that is designed to retrieve dial-up network password information and send it to a preconfigured address by using TCP/IP over the Internet. This trojan may have been received in a compressed format if you are using the ASPack utility.

This (rather dated article), as well as said DEP exception, sounds like a good reason not to use the ASPack utility, ever. Thank you for warning us all against it.

I too have used BlackViper's page, and find it excellent.

None of this changes the fact that globally allowing JavaScript opens you to many, many more attacks totally unrelated to buffer overflows, DEP, etc, as has been demonstrated.

However, we are now completely off-topic to NoScript, and several users and mods are regarding your posts as spamming for one particular product. Please discontinue this, or the posts will be deleted as spam.

If you have questions pertaining to NoScript, other than the philosophical argument that is closed, of course you are welcome to post them.

Thank you for your continued interest in NoScript.