[Bug report] ABE blocking non-local website

[ralf]

Hi,

using NoScript 2.4.1 and Firefox 12.0, the following website is mostly blocked by the ABE, to the extend that no CSS or JS is loaded, nor can I make any comment on the blog: http://wm161.net/
The ABE rulesets are at default, I have "WAN IP in LOCAL" enabled. Disabling the ABE makes the website look and behave as expected.

The hostname resolves to 173.255.226.43, and I can't see why NoScript would consider this a local IP.

Kind regards,
Ralf

[Thrawn]

I can't seem to reproduce this; site looks the same (and normal) with or without ABE.

Can you look for ABE messages in the Error Console (Tools - Error Console) and paste them here?

[ralf]

Sure. This is the error when I click above link:

Code: Select all

[ABE] <LOCAL> Deny on {GET http://wm161.net/ <<< http://forums.informaction.com/viewtopic.php?f=23&t=8729 - 6}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny

Some of the messages when opening http://wm161.net/2012/05/16/musings-on- ... dio-stack/

Code: Select all

[ABE] <LOCAL> Deny on {GET http://wm161.net/blog/wp-content/themes/twentyten/style.css <<< http://wm161.net/2012/05/16/musings-on-the-linux-audio-stack/ - 4}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
[ABE] <LOCAL> Deny on {GET http://wm161.net/blog/wp-content/plugins/openid/f/openid.css?ver=519 <<< http://wm161.net/2012/05/16/musings-on-the-linux-audio-stack/ - 4}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
[ABE] <LOCAL> Deny on {GET http://wm161.net/blog/wp-includes/js/l10n.js?ver=20101110 <<< http://wm161.net/2012/05/16/musings-on-the-linux-audio-stack/ - 2}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
[ABE] <LOCAL> Deny on {GET http://wm161.net/blog/wp-includes/js/jquery/jquery.js?ver=1.4.4 <<< http://wm161.net/2012/05/16/musings-on-the-linux-audio-stack/ - 2}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
[ABE] <LOCAL> Deny on {GET http://wm161.net/blog/wp-content/plugins/openid/f/openid.js?ver=519 <<< http://wm161.net/2012/05/16/musings-on-the-linux-audio-stack/ - 2}
SYSTEM rule:
Site LOCAL
Accept from LOCAL
Deny
...

In case that's of any interest, the output of "ip addr":

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether d8:d3:85:1c:55:54 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.100/24 brd 192.168.1.255 scope global eth0
inet6 fe80::dad3:85ff:fe1c:5554/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether c4:17:fe:c0:33:de brd ff:ff:ff:ff:ff:ff

I disabled "WAN IP in LOCAL" to see if that helps - it does not, the issue persists.


(btw, there's a bug somewhere in your board setup: If I paste the URL http://wm161.net/2012/05/16/musings-on-the-linux-audio-stack/ and hit "preview", then it changes to http://wm161.net/2012/05/16/musings-on- ... dio-stack/ in the source code unless I hit "Do not parse URLs".)

[therube]

(

there's a bug somewhere in your board setup...

Known. (And yet it persists!?)
)

[Giorgio Maone]

Just after this happens, please run the following in your Error Console (Ctrl+Shift+J):

Code: Select all

top.opener.noscriptOverlay.ns.__global__.DNS.resolve("wm161.net", 0, function(r) alert(r.entries.toSource()))

[Ralf]

The result is

["173.255.226.43", "fe80::adff:e22b"]

[Giorgio Maone]

fe80::adff:e22b is a link local IPv6 address.
No idea of why it's listed in the DNS together with public IPv4 address, IMHO shouldn't be there.
asking an expert, maybe there's actually a legitimate reason and I need to work-around some way.

[siu]

Hi, I can reproduce this error too, I think this is the same issue I reported in: http://forums.informaction.com/viewtopi ... =23&t=8691

[Giorgio Maone]

Hi, I can reproduce this error too, I think this is the same issue I reported in: http://forums.informaction.com/viewtopi ... =23&t=8691

Yes it is. Unfortunately, not even Dan Kaminsky (see Twitter conversation linked above) could provide any plausible rationale other than a dhcp misconfiguration (when? where?).

[ralf]

If Dan Kaminsky can't find one, then probably there is none
I mean, putting "192.168.0.1" doesn't make sense either... these addresses are not even routed.
If nobody did this already, I'll try to email the admin of the blog, and ask him to change/fix/explain the DNS setup.

[GµårÐïåñ]

Just after this happens, please run the following in your Error Console (Ctrl+Shift+J):

Code: Select all

top.opener.noscriptOverlay.ns.__global__.DNS.resolve("wm161.net", 0, function(r) alert(r.entries.toSource()))

You got mine through the email but I never heard back on it, so it seems others are facing this too. Ideas?

[Giorgio Maone]

Just after this happens, please run the following in your Error Console (Ctrl+Shift+J):

Code: Select all

top.opener.noscriptOverlay.ns.__global__.DNS.resolve("wm161.net", 0, function(r) alert(r.entries.toSource()))

You got mine through the email but I never heard back on it, so it seems others are facing this too. Ideas?

Your case is different and I've got no clue, since your DNS resolution seems OK.

[GµårÐïåñ]

Your case is different and I've got no clue, since your DNS resolution seems OK.

Hmm, ok, so does this other case yield anything on that front?

[Giorgio Maone]

Your case is different and I've got no clue, since your DNS resolution seems OK.

Hmm, ok, so does this other case yield anything on that front?

This one (wm161.net) and that one (bootlepy.org) share the very same problem (spurious DNS entry due to a change in ISP's architecture). I had an email exchange with Trever Fischer, the owner of wm161.net, and he confirmed the issue (due to Linode switching to IPv6) and told me he was going to fix it immediately.

However, since it seems this is gonna be quite common at least during the switch to IPv6 of hosting providers, and since web servers are very unlikely to be legitimately hosted on link-local IPs inside LANs, I'm gonna work-around for good by considering IPv6 link-local addresses (fe80:/10) as external for the purpose of cross-zone checks.

@GµårÐïåñ: as I said, your issue seems completely different and more difficult to investigate. Please open another thread, and start with confirming that it happens also on a clean profile with just NoScript in its default configuration.

[Ralf]

However, since it seems this is gonna be quite common at least during the switch to IPv6 of hosting providers, and since web servers are very unlikely to be legitimately hosted on link-local IPs inside LANs, I'm gonna work-around for good by considering IPv6 link-local addresses (fe80:/10) as external for the purpose of cross-zone checks.

Doesn't this circumvent parts of the protection? I don't know which IPs, for example, (home) routers use for their LAN configuration interface. Sites with such a DNS entry will be in trouble anyway as soon as more people have dual-stack at home - their site will be unavailable then (or at least much slower... I'm not sure if the browser are clever enough to notice that the IPv6 IP is dead, and fall back to the IPv4 one).