Internal network firewall
uazo opened this issue · 20 comments
continue from bromite/bromite#2525
Introduced new patch 00Internal-firewall.patch to perform filtering of http calls made by the browser based on a configurable list.
the goal is to take advantage of the internal logic of mapping each individual call via NetworkTrafficAnnotationTags so that selective blocking is possible before the actual call.
the http response in that case will be timeout and the calling code can perform the normal code related to the lack of connection.
in the log the related information is written to verify and actually study the related code to allow or eliminate it.
through this patch I discovered #146
currently under enable-firewall flag disabled by default: an analysis of the calls actually involved and a check of the blocked functions will have to be done.
patch should, along with Add browser policy, help in removing patches that hinder a fast rebase from one version to another normally caused by removal patches.
should also be considered #131
@chirayudesai I'd be happy if you could take a look at it
@PF4Public although I can't 100% guarantee that it's already okay for linux as well, but maybe we could work on it, it might be of interest to you as well
@PF4Public although I can't 100% guarantee that it's already okay for linux as well, but maybe we could work on it, it might be of interest to you as well
Do I understand this feature correct: it should be able to permanently block some requests? But what do you expect to be able to block this way? Internal requests to Google?
It would be great to either enforce or have some options to have Bromite:
- Drop all new (non-established, non-related) inbound traffic
- Drop all invalid traffic
- Drop all bad TCP packets equivalent to the following IPTables rules:
-p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP
-p tcp -m tcp --tcp-flags ACK,PSH PSH -j DROP
-p tcp -m tcp --tcp-flags ACK,URG URG -j DROP
-p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j DROP
- Drop all multicast traffic (Layer 3 and/or Layer 2 if possible)
- Isolate Bromite traffic (Layer 3 and/or Layer 2 if possible)
Modern Android app versions uses eBPF, which I do not know, but rules I describe can be converted to NFTables and/or eBPF. I am not familar with neither NFTables nor eBPF syntax. I think eBPF rules are applied or can be applied on per-app basis. If that is so, then I guess that's the kind of firewall Bromite/Chromium can utilize.
it should be able to permanently block some requests?
that is the goal, but requests made 'browser-side', not directly related to features exposed on the blink side, but rather to features necessary for blink to work or features exposed to the user via ui.
sync, safe-browsing, but also integration with ecommerce or log sending, anything else for which a connection is made via http outside the application.
in any case, these are not the only ways that chromium communicates, a future patch will deal with the exchange of intent and use of services in android, while in windows I will have to check whether there is any data exchange via COM.
I know that ungoogled chromium (but also bromite, not me) have the 'Automated-domain-substitution': my patch could just be used to test the effectiveness of that solution.
as far as I am concerned, as I gained experience, I realised that
- tracking changes to blink features is easier because the changes are detailed in https://chromestatus.com/roadmap
- the same does not apply to changes to the browser for which I have not yet found a source, and browser changes may require communication to external servers.
- my guess is that the changes that are made with patches similar to
Disable-safe-browsing.patch, work but not because the removal of the code is sufficient, but simply because the flags that deactivate the function developed by google are actually working. That patch I think is useless because that code is not being called, and we are removing dead code, unnecessarily, wasting time between rebases.
But what do you expect to be able to block this way?
each individual request is detailed with a traffic annotation (list), there are a variety of them.
Internal requests to Google?
the majority, but I don't know for sure, we can verify it.
@GY8VSdYYzvL8-K6T is not really a network firewall. I would like if you would explain in another issue why those rules should be applied to the browser
ungoogled-chromium uses "trk:" scheme for catching potentially harmfull connections: https://github.com/ungoogled-software/ungoogled-chromium/blob/master/patches/core/iridium-browser/all-add-trk-prefixes-to-possibly-evil-connections.patch. Still having two independent implementations would be a great idea to verify the effectiveness of each.
for the next step (firewall on android context), remember that there is
-
context.startActivity(intent);
example launchGmsUpdate -
context.getSystemService() -
queryIntentActivitiesinbase/android/java/src/org/chromium/base/PackageManagerUtils.java
see isGsaAvailable
in windows:
Hi @uazo , with the internal firewall enabled, 9gag.com doesn't load.. had to disable the internal firewall before the site loads..
With the 9gag tab still open, re-enabling firework and restarting chromite, the site still works.. but if u close the tab and reopen a new tab, the site stops loading..
but if u close the tab and reopen a new tab, the site stops loading..
interesting. tried with my android and windows opens and works.
give me android version and device i will try with browerstack.
and log result with chrome://crashes, can you generate one manually.
it would also be interesting to check with developer tools, are you able?
technically there is no reason, what I block are browser calls and not from blink, to understand, ancillary calls not directly related to browsing. However, if this is the case, it is tracked in the log
add rules as #34 (comment)
Another bug I found in the internal firewall.. when I visit epic games store website (to claim free games), the website refuses to log me in with the firewall enabled.. had to disable the firewall so that the captcha will work..
And, after login, if I re-enable the firewall, the website refuses to remember that I'm logged in and I am no longer able to access the login page.. disabling the firewall allows epic store to remember that I was logged in..
@eskimododo please follow istructions #147 (comment)
I would need to know which call was blocked.
thank you!
05-16 15:04:06.804 9397 17826 I chromium: [INFO:url_request_http_job.cc(554)] ---ABORTED
URLRequestHttpJob: service_worker_navigation_preload(129872904) url:
HTTP://WEBADDRESS.ELIDED path: content/browser/service_worker/service_worker_fetch_dispatcher.cc
check ResourceFetcher::DetermineRequestContext()
some destinations are grouped as SUBRESOURCE (see #104)
new call intercepted in v114 (back_navigation_cache_query)
[8944:8672:0606/155211.569:INFO:simple_url_loader.cc(1687)] ---ABORTED SimpleURLLoaderImpl:
no-name(122067755) url: https://www.google.com/search?q=bla+bla+bla&ie=UTF-8&hl=en path: no-path
check also TCPConnectedSocket::ConnectWithSocket
actually breaks component build
try with
gn gen --args="is_debug=false target_os=\"linux\"" --filters="//components/subresource_filter/tools:subresource_filter_tools" out/linux
autoninja -C out/linux subresource_filter_tools
some update.
I am testing the approach mentioned in #147 (comment), which is to intercept calls that the browser makes externally via android's api.
what i understand is that there are basically two different ways
- via intent
- via binders
intercepting calls to android services doesn't seem to useful.
the first point is basically dealt with by the code in components/external_intents/android/java/src/org/chromium/components/external_intents and I found some information (as referrals) that I can ask the user whether to delete. the idea is to leave it that way, so that it is the upstream code that checks all possible ways to exploit it as fingerprinting and change only the launching of the intents (which occur after chromium actually decides to open the application).
I have not found a way to verify the binders, I will probably have to restore the patches that removes the google libraries and try again, however I assume that it is not possible to make a list of "non-malicious" binders to allow, I don't know, I will see.
I also found some code that makes calls to the network but is not tracked by any TrafficAnnotationTag: this seems strange to me, I will probably ask the devs if there is a reason for this
wip patch in https://gist.github.com/uazo/d8208d8d6fd732cf1173459a4464f143
some update.
I am testing the approach mentioned in #147 (comment), which is to intercept calls that the browser makes externally via android's api.
what i understand is that there are basically two different ways
- via intent
- via binders
intercepting calls to android services doesn't seem to useful.
the first point is basically dealt with by the code in components/external_intents/android/java/src/org/chromium/components/external_intents and I found some information (as referrals) that I can ask the user whether to delete. the idea is to leave it that way, so that it is the upstream code that checks all possible ways to exploit it as fingerprinting and change only the launching of the intents (which occur after chromium actually decides to open the application).
I have not found a way to verify the binders, I will probably have to restore the patches that removes the google libraries and try again, however I assume that it is not possible to make a list of "non-malicious" binders to allow, I don't know, I will see.
I also found some code that makes calls to the network but is not tracked by any TrafficAnnotationTag: this seems strange to me, I will probably ask the devs if there is a reason for this
wip patch in https://gist.github.com/uazo/d8208d8d6fd732cf1173459a4464f143