Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ BUG? ] Links Launching Browser Are NOT Filtered Consistently #2067

Closed
GuardianMajor opened this issue Oct 13, 2016 · 11 comments
Closed

[ BUG? ] Links Launching Browser Are NOT Filtered Consistently #2067

GuardianMajor opened this issue Oct 13, 2016 · 11 comments

Comments

@GuardianMajor
Copy link

Issues

> Scenario # 1

When a program launches a URL, say trying to go to adf.ly or whatnot, and the browser is NOT already running, it will bypass uBlock completely on start up and loads the blocked page anyway nearly 100% of the time. In very limited instances, it will block it but instead it comes accompanied with a bizarre, this block was done by the browser and it will interfere with proper operation, bluh bluh (not from uBlock, this is clearly something built-in).

> Scenario # 2

When the browser is running already, then nearly 100% of the time it blocks it just fine; but there are occasional times it will still let it through.

> Scenario # 3

Now if the browser was NOT running, and the link launched it (the first case I stated) and then a second link launches while it is open now, it will still not block it. SO if the item manages to bypass uBlock on startup, then it will continue to do so until you close the browser, open it back up and THEN wait for the links to hit. At this point it seems to work "ok".

URLs

Any link shortening service, although I have experienced it with these:

bc.vc
cld.pt
adf.ly
dx.am

Screenshots

Really not a visual issue that a screenshot would add any value and plus I didn't grab any of the times it happened, so since this is understandable without it, shouldn't be an issue.

Reproduce

First put the filters above in. Then you can have a program trigger them for you or create a desktop shortcut to some shortened URL, preferably one of the above, close your browser completely and make sure its not in memory anymore, then double click the link and have it open up, watch and see what I mean.

Settings

Not entirely important here but here you go:

ublock_settings

  • Browser/version : Chrome (Stable) Version 53.0.2785.143 m (64-bit) until today's update to Version 54.0.2840.59 m (64-bit) and nothing else has changed.
  • uBlock Origin version : v1.9.10

Lists

As already state in issue #2066 , not applicable here, so I won't clutter here with it but except for a couple extras that I clicked, the rest is pretty default, minus ONE outside list that is actually meant to prevent blocking of the blocking and it is combined with a TM script to ensure that they can't invalidate my blocks.

Filters

N/A beyond what is already listed above.

@gorhill
Copy link
Owner

gorhill commented Oct 13, 2016

When a program launches a URL, say trying to go to adf.ly or whatnot, and the browser is NOT already running, it will bypass uBlock completely on start up and loads the blocked page anyway nearly 100% of the time.

The browser does not wait for extensions to be fully loaded and ready before opening tabs, it's a by-design browser issue. Reported before.

@Atavic
Copy link

Atavic commented Oct 13, 2016

This is a system-wide issue.

You can block the default browser in the OS settings with a firewall, or even prevent default browser execution with an Intrusion Prevention System. While the user actively launches a non-default OS browser, any automated/drive-by browser connection is blocked by the firewall,
as they activate the default OS browser.

@GuardianMajor
Copy link
Author

@gorhill yes my friend, I know as much but sometimes it will bypass it even when it is running. You put your focus entirely on Scenario 1 and completely glossed over the second one where the browser is now up and running - so by your statement - the extension is active, so what's the reason then it will continue to allow them to open after the extension is loaded? Because right now, the allowance at initial startup can be triggered willfully by simply the malicious program initiating a new instance of the browser too with a different "command line" parameters. Since that instance has to "load" the extensions again as well, it is effectively nullifying the blocks.

What I am mostly asking is, why after the initial bypass it keeps letting it through? And as a resolution to this, or to at least try and mitigate (which looking through the source of Chromium there are ways to hook in earlier, much like NoScript does with Mozilla by for lack of a better word "hooking the kernel" so it runs at system level which means that the browser WILL honor any security restrictions BEFORE launching, no matter the extension recognition time) to try and provide a slightly earlier execution time?

Alternatively, can we just introduce a render block which effectively acts like say JQuery's document.ready mechanism, to prevent any links from ACTUALLY making the socket connection, until the browser has fully loaded and the system is in place, so voila once the render block is done because the system is ready, it will let the socket go through at which time if it matches a rule, bam, killed.

Now, I know these might not be solutions readily available, but what if we at least lobby for them, or look into using existing framework's that Google uses to secure the browser itself, to leverage to what we need. Sort of like off label use of a medication.

@Atavic what you are saying makes little sense, because the firewall would block the BROWSER itself, not a link within it, unless you mean web filtering like Malwarebytes or Avast which cause more problems than they resolve and not interested in hacking all over the place, we are testing for a reliable single existing solution, because asking the end user to protect so many end points is a near impossibility as not everyone is technically inclined. So your system of blocking the default browser results in poor usability and we don't need the "cure" to be worst than the disease.

@Atavic
Copy link

Atavic commented Oct 14, 2016

Maybe wasn't my previous post clear enough?

I have my default browser blocked by my IDS. It can't even launch. Any link launched by applications in my OS call this blocked browser.

I use another browser and I have a taylored Open with... on my system. This solves all your problems that are security issues on a system level, not the browser or the addons.

@gorhill
Copy link
Owner

gorhill commented Oct 14, 2016

I did not address issue 2 because there is no reproducible case, no URL. What I need is all the steps for me to reproduce without having to guess anything.

@Atavic
Copy link

Atavic commented Oct 14, 2016

BTW the answer was given: Browser Issue. Addons work inside the browser, so the issue should be filed to: Bugzilla@Mozilla or you can block the default browser at the system level.

@0xBRM
Copy link

0xBRM commented Oct 14, 2016

Second scenario is probably caused by cached items, remnants of scenario 1.

Scenario 3 is the only one that seems plausible and worth a try.

@GuardianMajor
Copy link
Author

@anewuser I can't believe someone agreed with your statement given it means nothing here. You say be concise, what about the way I presented the details of the problem organized answering everything the developer specifically puts to be answered no concise? This is technology and discussing ways to do something can't be done in a single line, if that's how you consider development, you are in the wrong field. I was concise without sacrificing detail or explanation.

@Atavic I understand your system, it was clear and I find it very clever and something I would do for myself but not something that is scalable, deployable (easily) or stable long-term, too many things can break the hackiness of it. I am on Chrome with this right now, not Mozilla, so keep referring to that is just ignorant. The part that is the fault of the browser has been starred and not much else can be done.

@CrisBRM Yes that one is included for completeness because it DOES happen even when the browser was manually and fully loaded. While cache is a possible problem, it shouldn't actually matter. The blocking is done at the socket level, so cache request or not, shouldn't matter. Especially that the links in question don't really cache since they are "hoppers". It was mostly the scenario 1 & 3 that are issues, but I don't believe in being half assed even when accused of not being concise; whatever the hell that is supposed to mean from a random hit and run comment.

@gorhill We go way back, and I was there when you started uMatrix (when it was still called HTTP Switchboard), so at least have the civility to be respectful and don't be condescending when you know you are being glib and dismissive. I don't know the motivation and I personally don't care, but what I am bringing up is valid and pretending like it is not, is not the right way to go.

I included all the links above (in the filter section) and the reason I didn't give out full links is because it would be putting malicious links in the wild and I have more consideration than that. Since you can easily test what I am saying with ANY short link that you can generate yourself, hanging up on no links to test is disingenuous as is saying it's not reproducible simply because you didn't even try.

I provided you EVERYTHING you asked in your template and was even insulted and accused of not being concise because of all the things you asked for and I provided and yet you are still claiming you don't have what you need? There is no guessing and seriously you should just say I don't care about it working right, don't want to fix it or look into it despite putting my name and reputation on it, and I don't care that you took time to come to me and try to help me and it would been far more genuine and appreciated than trying this act. There are things you don't know that would make this even more wrong and shameful but ignorance is not an excuse and I have no interest in telling the world what you should already know.

Fix it, don't fix it, care, don't care, I am done. Good luck with that but the day you realize I was right and you could have done something about it, remember this.

@gorhill
Copy link
Owner

gorhill commented Oct 15, 2016

the civility to be respectful and don't be condescending when you know you are being glib and dismissive

I don't know why you say that -- nowhere in here did I write something condescending. I just try to keep my answers short and to the point. If it's about my "no URL" answer, then again that is me pointing out that fact: I currently would have to go on a hunt to find somewhere on the web URLs which involve at least one of your listed wildcarded hostnames to use as test case for this issue -- and such time-consuming URL-hunt is not something that should be expected from me; it is the responsibility of the person opening an issue, hence why I emphasize this in CONTRIBUTING.

There might be something to do for point 1, there is an idea I have been juggling with since a while -- but I am really not sure about the result, I will have to experiment when I get the time.

@Atavic
Copy link

Atavic commented Oct 21, 2016

What can you do about it? Forcing Offline Mode until the addon is loaded and working?

@gorhill gorhill closed this as completed in 8c3da95 Nov 3, 2016
@gorhill gorhill reopened this Nov 3, 2016
gorhill added a commit that referenced this issue Nov 4, 2016
@gorhill
Copy link
Owner

gorhill commented Nov 4, 2016

Actually duplicate of #1327 -- I had forgotten there was an issue already opened about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants