[RESOLVED] ABE re-enabled on restart after disabling

[ssj100]

I probably should have given step by step instructions as to how to reproduce the issue from the start. Anyway, here it is:

1. Windows XP, SP3, 32-bit, Administrator account. No other software installed except Firefox 8.0.1.
2. Install the Firefox add-on NoScript
3. Navigate to the NoScript ABE settings
4. Click Disable (for SYSTEM)
5. Click OK
6. Close Firefox
7. Open Firefox
8. Navigate to the NoScript ABE settings again
9. Notice that the setting has become enabled (for SYSTEM)

[Tom T.]

I probably should have given step by step instructions as to how to reproduce the issue from the start.

Um, yeah, that would have been *really* helpful. And saved many hours of my time (and yours). And it's actually requested in that big, all-upper-case title,
"PLEASE READ THIS FIRST! -- FORUM RULES AND GUIDELINES"
above the top of each of the forums. More than 25,000 users have read it, and probably about the same number haven't.
(I added the bold to "FIRST" here for emphasis.)

11) When reporting a problem or possible bug, please be sure to include in your first post:
a) The address or addresses (URL) where this occurs,
b) the exact steps we need to follow to reproduce your problem....

Anyway, here it is:

1. Windows XP, SP3, 32-bit, Administrator account. No other software installed except Firefox 8.0.1.
2. Install the Firefox add-on NoScript
3. Navigate to the NoScript ABE settings
4. Click Disable (for SYSTEM)
5. Click OK
6. Close Firefox
7. Open Firefox
8. Navigate to the NoScript ABE settings again
9. Notice that the setting has become enabled (for SYSTEM)

Utterly different. The post gave every indication that you were unchecking "Enable Abe". You weren't "disabling ABE", you were disabling *that one (or more) System rule*. Which *still* leaves ABE enabled for USER rules -- try it yourself. (Even if you don't have any user rules.)

Giorgio may weigh in on this, but it's clear from the ABE FAQ that that default System rule was *crucial* to the WAN-LAN protection that is a major purpose of ABE. So if you needed to disable it for testing purposes, IMHO it was quite proper of Giorgio to restore it at the next session, in case you forgot to.

Should you choose to disable ABE altogether, by unchecking the "Enable ABE" box that dhouwn, I, and apparently, everyone else viewing, thought you were referring to, well, then you've made a conscious choice to forgo *all* of ABE's protections, for whatever reason, and that change should stick.

There isn't a bug, because what you wanted to do was disable individual rules, not just the whole thing. Try writing some --random nonsense -- then select them and click "Disable" below the rulebox. Then click "Enable", and see if they don't come back for you.

Please confirm that unchecking "Enable ABE" above the rule box is sticky through restarts, so that I can mark this topic as resolved -- finally.
Thank you.

[ssj100]

Yes, apologies for not posting the step by step instructions. I generally always do when it comes to stuff like this. Just got lazy I guess haha. Anyway, have a look at this and see if you still think it's not a bug (see bolded parts in particular):

1. Windows XP, SP3, 32-bit, Administrator account. No other software installed except Firefox 8.0.1.
2. Install the Firefox add-on NoScript
3. Navigate to the NoScript ABE settings
4. Click Disable (for USER)
5. Click OK
6. Close Firefox
7. Open Firefox
8. Navigate to the NoScript ABE settings again
9. Notice that the setting has become enabled (for USER)

Again, this is definitely a new thing that I noticed for versions of NoScript released from June 2011. So are you saying that the USER settings are also meant to be re-enabled after closing and re-opening Firefox? If so, what is the point of having an option to disable it?

Please confirm that unchecking "Enable ABE" above the rule box is sticky through restarts, so that I can mark this topic as resolved -- finally.
Thank you.

Yes, that's never been a problem. It's always been about specifically disabling the USER setting (not SYSTEM - I chose SYSTEM in my example above because it was just an example). The following rule has always been in the USER box for me:

Code: Select all

Site http:
Deny INC from https:

That's why I wanted to disable the USER rules, while keeping the SYSTEM rules enabled. If this is intentional behaviour, then it's obviously something that has changed and I will accept that. It just doesn't make sense that the USER rules should be automatically re-enabled after re-opening Firefox.

Many thanks for all your help and support. Can you ask Giorgio if it's possible to at least have an option to make the USER rules stick after closing and re-opening Firefox?

[Giorgio Maone]

Confirmed as a bug, will try to fix it in 2.2.3 or sooner.

[Tom T.]

Are you saying that some banks try to steal your bank login details?

No, I'm saying http://noscript.net/faq#qa4_1. And don't think for a minute that banks haven't been vulnerable to this. They have.

As for my firewall configuration, I have an IPSec rule which when enabled, only allows communication from my IP address to my bank's sole IP address (and vice versa) via Port 443, TCP protocol. Any other communication that doesn't fall under those specifications is blocked by default. Therefore, only my bank can steal my information, which they effectively have anyway!

Not if the bank is vulnerable to the injection attack described in the FAQ above, which NoScript prevents.

Having spent this many hours in assisting you, are you sure you don't care to return the favor by bringing the facts about ABE, and about NoScript in general, to the readers at your own forum, whose thread you linked earlier in this discussion? I'm done, and Thursday 24 Nov is a holiday (Thanksgiving Day) in the US.

Confirmed as a bug, will try to fix it in 2.2.3 or sooner.

Whew! Glad we finally got the *real* issue identified, and soon, fixed.
Thanks, Giorgio.

[ssj100]

Confirmed as a bug, will try to fix it in 2.2.3 or sooner.

Thanks!

Not if the bank is vulnerable to the injection attack described in the FAQ above, which NoScript prevents.

Not sure if I understand the exact mechanism of how information can be stolen if the only IP address that can be connected to my system is the bank's? All other connections to other IP addresses are terminated when the IPSec rule is enabled. The FAQ states:

That's why NoScript features unique and very effective Anti-XSS protection functionality, which prevents untrusted sites from injecting JavaScript code into a trusted web page via reflective XSS and makes NoScript's whitelist bullet-proof.

How does the untrusted site get loaded in the first place? Is it some sort of a Man-In-The-Middle attack? I suppose the login details go to the bank's IP address and then bounces from the bank's IP address to the attacker's IP address? Thanks for all the information.

Having spent this many hours in assisting you, are you sure you don't care to return the favor by bringing the facts about ABE, and about NoScript in general, to the readers at your own forum, whose thread you linked earlier in this discussion?

I'm pretty sure the facts about ABE and about NoScript in general are already somewhere in that forum. It's just not in that one specific thread I linked. Regardless, if it was this forum's (or NoScript's) policy to have to "return favours" after asking for help and identifying a bug, then I should not have asked in the first place. Some developers reward people for finding bugs in their software, not ask them to "return the favour".

However, I don't mean to sound ungrateful, and I thank you and Giorgio for taking the time to look into this. Thanks in advance for the bug fix.

[Giorgio Maone]

Should be fixed in latest development build 2.2.2rc3.
Please confirm, thank you.

[ssj100]

Should be fixed in latest development build 2.2.2rc3.
Please confirm, thank you.

Confirmed fixed. Thanks.

[Tom T.]

.
@ ssj100: Yes, I had a very nice holiday, thank you.

Not if the bank is vulnerable to the injection attack described in the FAQ above, which NoScript prevents.

Not sure if I understand the exact mechanism of how information can be stolen if the only IP address that can be connected to my system is the bank's? All other connections to other IP addresses are terminated when the IPSec rule is enabled. The FAQ states:

That's why NoScript features unique and very effective Anti-XSS protection functionality, which prevents untrusted sites from injecting JavaScript code into a trusted web page via reflective XSS and makes NoScript's whitelist bullet-proof.

How does the untrusted site get loaded in the first place? Is it some sort of a Man-In-The-Middle attack? I suppose the login details go to the bank's IP address and then bounces from the bank's IP address to the attacker's IP address? Thanks for all the information.

http://hackademix.net/2008/01/12/malware-20-is-now/

Real scam — The ultimate bank phishing using XSS.
The credential harvesting form has been embedded inside the real bank page, served through a “secure” HTTPS connection with a valid SSL certificate, exploiting a reflected XSS vulnerability. Absolutely nothing new, and a relatively poorly performed trick too: the attackers could have as easily choose to host the whole payload inside their XSS vector itself, making their fraud even stealthier without the remote inclusion of an external resource from a different domain. But since they didn’t, surely they estimated their way is good enough to work — and it is, much more than any other phishing attempt you’ve seen so far, because this is the real bank site!!!

For the record, I tried to click that link from 2008, but it's obsolete. It looks like HP bought the "spidynamics" company, so if you want more details than what Giorgio said, you might try to find it at hp.com (former Hewlett-Packard)

Having spent this many hours in assisting you, are you sure you don't care to return the favor by bringing the facts about ABE, and about NoScript in general, to the readers at your own forum, whose thread you linked earlier in this discussion?

I'm pretty sure the facts about ABE and about NoScript in general are already somewhere in that forum. It's just not in that one specific thread I linked. Regardless, if it was this forum's (or NoScript's) policy to have to "return favours" after asking for help and identifying a bug, then I should not have asked in the first place. Some developers reward people for finding bugs in their software, not ask them to "return the favour".

There is no cost and no obligation for support here, just as there is no obligation to donate to NoScript despite its probable retail value in the marketplace. You may use it for free forever. (Do you think that has anything to do with why Giorgio can't afford to pay people for finding minor bugs, which this was? Or even security flaws, rare as they are?) I'm sorry if you got a different impression. Perhaps I may clarify:

Your own link is at "ssj100 Security Forums", and user ssj100 is shown as Admin. Pardon me for finding it a bit disingenuous for you to say that it's not your site. Especially after you posted about your conversations here, and assured your readers that "this Giorgio Maone guy seems to know what he's talking about." (that's an understatement! ) How am I not to believe that you are the same user as that Forum Admin?

Whoever "owns" it, if I were the Admin of a Security Forum, I would want my users to have the best and most accurate security information available, as much as humanly possible. If misconceptions or errors are posted, I would correct them, just as I welcome anyone to enlarge my own knowledge base when I make an occasional brain-fade here, as we all do at times. Your mileage obviously varies.

The particular thread linked had a number of mistakes, misconceptions, very incomplete understanding of NoScript's many powerful protections, etc.
I gladly spent a great deal of time trying to alert you to these. You don't want to make a post or two to pass that on in that thread? OK. IMHO, it's a credibility hit for that site and a disservice to your less-secure-than-they-could-be users, but again, that's your call.

I'm pretty sure the facts about ABE and about NoScript in general are already somewhere in that forum. It's just not in that one specific thread I linked.

What if that's the only thread a visitor sees?

Do you think that all the posters in that thread will search the rest of that site for the correct information? Obviously they didn't, as they still seemed to have the misconceptions.

Search-engine hits on that thread?

As far as my being welcome to post there: TUVM. However, if I were to search all the security sites in the world and try to correct every misconception or mistake about NoScript, I'd have no time to do what I do here, which is to assist NoScript users who come to the NoScript Forum. Nor any time to eat, sleep, bathe...

Not that it matters, but the entire Support Team here consists of unpaid volunteers, who willingly donate whatever of their spare time they can to this very worthy cause. I know that at least one other team member has to make a living in the Real World, as I do, and with the global economy getting worse by the minute, that's a much harder task than it was five or ten years ago. (I've never asked the remaining members about whether they work, retired, trust fund, etc.)

And I will admit to a human failing: I've sometimes spent days trying to track elusive issues. One thread about a new form of malware infection went to more than 250 posts. But with the cooperation of the OP and some contributions from some of our frequent posters, we nailed it. I sent it to the Internet Security Storm Center at the SANS institute of Security Technology. They gladly posted it and exposed it for all the world to see. Presumably, AV vendors updated their databases accordingly. (and a cool plug for NoScript, eh? )

This was not for personal recognition -- there was no mention of this site, and they left off my last initial, which was fine by me. There was the satisfaction of having made the Net a tiny bit safer, which is more than enough reward.

Back to human failing: The issue here was misdescribed repeatedly, as "disabling/re-enabling ABE" (look at the title of the thread, which was your choice), rather than the actual issue: Disabling/re-enabling *individual ABE rules" -- a very different issue, since, as you confirmed, disabling ABE was sticky through restarts, as it should be. Only after the correct steps to reproduce were posted did anyone realize this. Note that long-time user and Forum contributor dhouwn interpreted it the same way, agreeing it made no sense. So it wasn't just I.

I'll help anyone who helps me help them. You made a human error. We all do. No big deal, and no hard feelings. But other users waited longer due to the extra (unnecessary) time spent on this issue, not to mention that I try to have a life sometimes, too.

I just thought that since the mistake cost several extra hours of my support time (and my life), that asking you to educate your users wasn't an unreasonable request. Obviously, it was. No problem. Moving on. You're still welcome here, and I'll still help you if I can -- especially now that you know to put the exact steps to reproduce into your first post.

However, I don't mean to sound ungrateful, and I thank you and Giorgio for taking the time to look into this. Thanks in advance for the bug fix.

I admit it sounded a bit ungrateful, but as they always say, if you want gratitude for your work, be a firefighter.
Cheers.