Chromium Browser for Kicksecure Discussions (not Whonix)

Development
, ,
21

I get the exact same result on both Arch Linux and
Whonix/Kicksecure/Debian. You’re likely doing something wrong.

eeh just discovered that running chromium from terminal wouldn’t disable
that, only if running chromium from its icon. So yes it disable TLS
1.0,1.1 just not the others.(not sure where is the issue in here)

It’s not unrelated. This option does disable it.

Im lost, it disable webRTC completely or what?

Aside from that, chromium package outdated in debian mostly the
maintainer just quite or busy… do you have the capability to push the
new version in debian?

And do we have Apparmor/bubblewrap profiles for chromium?

madaidan via Whonix Forum:

22

On FF being more configurable…
Not that I think we identified any important setting the distribution or users must be able to change to make a good point for FF instead of chromium…

Ability to configure more could be possible through chrome (same for chromium?) policies?

On disabling of certain TLS versions or ciphers… If there is any security benefit if a distribution changed such default settings or if that was any useful if users did that… Please create a new forum thread for that. Since that discussion is kinda independent from this. Preferably with authoritative sources, experts explaining any threat model where this would lead to attack surface reduction, safer connections or anything else.

This is derived from the context of the discussion. Because of the title of this forum thread. Which default browser to choose.

Chromium Browser for Kicksecure Discussions (not Whonix)

Then also the link Dev/Chromium - Kicksecure is saying:

This page is a collection of notes, issues, criticism, advantages of Chromium. Development Considerations regarding default installation of Chromium in Kicksecure.

I should have added link to Dev/Default Browser - Kicksecure earlier or made that more clear.

Related, for most part unsolvable rabbit hole:
Selecting Secure Packages from packages.debian.org

With all due respect for all the work Debian people are doing, the maintenance of the Debian chromium package seems currently less than stellar.

Upstream Chrome (assuming same or similar for chromium, can’t easily find chromium stable release channel / versions) stable version is 86.0.4240. Debian Chromium version in Debian stable/testing/unstable is 83.0.4103.116 and Debian unstable has 84.0.4147. There is a good overview here:
Quote chromium - Debian Package Tracker

Not all issues in that list may be critical. Some issues could be considered minor. For example:

  • CVE-2020-15959: Insufficient policy enforcement in networking in Google Chrome prior to 85.0.4183.102 allowed an attacker who convinced the user to enable logging to obtain potentially sensitive information from process memory via social engineering.

But others sounds more severe:

  • CVE-2020-15960: Heap buffer overflow in storage in Google Chrome prior to 85.0.4183.121 allowed a remote attacker to potentially perform out of bounds memory access via a crafted HTML page.
  • CVE-2020-6537: Type confusion in V8 in Google Chrome prior to 84.0.4147.105 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page.

An even better overview of the Debian chromium package showing which CVEs are currently shown as vulnerable:
https://security-tracker.debian.org/tracker/source-package/chromium

Debian’s firefox-esr package has no such mentions:
https://tracker.debian.org/pkg/firefox-esr

But I guess @madaidan can pull out a reference showing how firefox-esr just means most security fixes are ignored and never back ported thereby relativize this?

So we have multiple different contests.

  • A) upstream Firefox vs upstream Chromium
  • B) Debian firefox-esr package vs Debian Chromium package
  • C) upstream Firefox vs upstream Chrome (irrelevant since Chrome isn’t fully Open Source)

Who’s the winner of each contest?

  • A) upstream Firefox vs upstream Chromium: Winner is Chromium.
  • B) Debian firefox-esr package vs Debian Chromium package?

Another option in theory for Kicksecure might be downloading packages for Debian from a another source (such as for example if Chromium provided these). But it doesn’t look as if these exist.

The chromium stable release channel links to, well, chrome. Not helpful.

There might be third parties providing alternative chromium packages. I’ve also seen download scripts before for chromium (similar to tb-updater) (non-package version). Or perhaps we would have to rely in a chromium (such as ungoogled-chromium if they did provide Debian stable (currently: buster) packages or any other chromium fork project?

Even having both apparmor and bubblewrap profiles for Firefox wouldn’t speak for Firefox in favor of Chromium since it comes with its own sandbox. It’s an important thing too but could be implemented on top as bonus at any later time.

1 Like
24

That doesn’t change anything. It’s disabled either way.

The others don’t need to be disabled.

It disables WebRTC unless it is proxied which mitigates the privacy risk.

sandbox-app-launcher works.

Policies do give fine-grained control over features in the browser but it’s not the same as about:config.

https://medium.com/@thegrugq/tor-and-its-discontents-ef5164845908

Tor Browser Bundle is based on a code base that may have publicly patched Critical or High bugs that are months old. And all the Medium and Low bugs are simply never patched (forever days, as they’re sometimes called.)

An adversary can do any number of things to attack the TBB, for example:

  1. Monitor for Critical / High patched vulnerabilities in the less stable channels (Nightly, Aurora, Beta) and then check whether the vulnerability exists and is exploitable in TBB. They have a window of exposure that might last weeks or months.
  2. Chain a series of Medium / Low vulnerabilities together until they get the level of access they require, e.g. remote code execution. They have a permanent window of exposure.

[…]

Tor Browser Bundle is at the tail end of the pipeline of patching (of which it receives only a minimal patch set)

With TBB’s base being Firefox ESR.

Maintenance of each ESR through point releases is limited to high-risk/high-impact security vulnerabilities

i.e. no Medium / Low vuln fixes

Still Chromium. The security gap between older versions of each browser is even larger than it is between recent versions. Firefox has been doing lots of catching up. E.g. Firefox’s sandbox is still quite recent when compared to Chromium.

Brave has a Debian repo: Installing Brave on Linux | Brave

Brave is a small bit behind on updates sometimes too although it’s nowhere near the lag of Debian and IME, it’s not too bad. It maybe has a few weeks lag at most.

You might not like Brave though due to its controversies in the past (BAT, auto-completing affiliate links, etc.)

https://twitter.com/BrendanEich/status/1269313200127795201

I don’t see any issues with the browser in its current state though. Any “iffy” features are opt-in and I’ve monitored the connections the browser makes myself to make sure it’s not privacy invasive.

They don’t provide packages themselves. There are only sketchy third-party ones: Downloads for ungoogled-chromium

Yes, an external sandbox like AppArmor or bubblewrap is not a replacement for a proper internal browser sandbox like in Chromium. Chromium’s sandbox is much more restrictive than anything we can add on top. It splits the browser up into multiple processes and sandboxes them individually with a really strict policy. Ideally, we would have both an internal and external sandbox.

1 Like
25

There’s no official stable chromium channel by upstream chromium.org? We couldn’t even have a script similar to tb-updater that downloads chromium stable, verifies gpg signatures (don’t exist)?

For all practical purposes, a chromium binary distribution doesn’t exist? (Major missing features such as stable release channel and gpg signatures.)

26

No. Only Chrome releases are provided.

1 Like
27

Quote Download latest stable Chromium binaries (64-bit and 32-bit)

Few free and open-source Chromium-based browsers:

Any of these forks or any others more suitable?

1 Like
28

It’s never a good idea to use forks because there will always be delays in applying patches compared to the base project - palemoon for example and other firefox forks are unsecure because of that.

2 Likes
29

No not really. The only good ones listed there are Brave (see above) and Bromite (mobile only).

Palemoon is unsecure for many more reasons than that. They use an intentionally ancient version of Firefox with all sandboxing, Rust, etc. code removed. They eliminated the little security that Firefox has.

2 Likes
30

Due to,

  • the current state of the Debian chromium package,
  • unavailability of any very up to date maintained chromium package or fork elsewhere,
  • Chrome not being Freedom Software.
  • issue with (Firefox) ESR

there is no great default browser. Unfortunately re-opens the question which default browser to use for Kicksecure default installation.

Is Flathub—An app store and build service for Linux an option?

2 Likes
31

yeah, been way too back in versions.

No it doesnt. Tested chromium running from terminal and ungoogledchromium from appimage giving the same result. (But this not big deal since almost everyone gonna run software from their icons)

Not fully:

https://wiki.archlinux.org/index.php/Chromium#WebRTC

Warning: Even though IP leak can be prevented, Chromium still sends your unique hash, and there is no way to prevent this. Read more on WebRTC Leak Test - BrowserLeaks

But since we are talking about security, no problem.

32

better to come with none, but just show a dialog popup asking the user if he would like to install firefox,chromium, skip. I think this is the best choice.

33

Bad first time user experience, even more so in ISO live mode.

1 Like
34

Despite Chromium’s issues on Debian, it’s still a less atrocious option than Firefox although still not very good.

Flatpak isn’t a good option either. It has a terrible sandbox and also takes a lot of time to patch vulnerabilities.

https://madaidans-insecurities.github.io/linux.html#flatpak

Using Flatpak and Firefox together doesn’t really help its security. You can escape both sandboxes at the same time though e.g. X11.

It is the exact same. There is no difference between executing it from a terminal and clicking the icon.

user@host:~$ cat /usr/share/applications/chromium.desktop 
[Desktop Entry]
Version=1.0
Name=Chromium Web Browser
[...]
Exec=/usr/bin/chromium %U

You’re doing something wrong.

That’s referring to a browser extension.

35

I think he mentioned Flatpak as an easy way to access more recent versions than ESR and therefore having less forever days. If there is a Chromium equivalent then it would be the sweet spot.

2 Likes
36

Indeed. Flatpak sandbox is not what I was after with that idea. It’s just a vehicle to get recent versions of a browser.

Is Chromium Debian package with…

… still more secure than the most recent stable version of Firefox (acquired through flatpak)?

2 Likes
37

It’s a tough question and I’m not sure which would be better.

The disabled Chromium mitigations don’t make much of a difference anyhow as Firefox never had many of those mitigations in the first place e.g. it never used automatic variable initialization in production (only in debug builds) or CFI.

Although, Firefox’s mozjemalloc might be better than Debian Chromium’s glibc malloc? Since the Debian package disables Chromium’s hardened malloc, it defaults to the non-hardened glibc malloc. mozjemalloc isn’t very good either but it has a few security features that it sticks on to jemalloc. It’s hard to tell whether it’s more secure than glibc.

Both have a lot of lag when it comes to security patches but I’m not sure which is worse.

1 Like
38

hmm if there is possibility to install the package while user first time boot live mode then not an issue, but if live mode without root access yes it will be a problem. On reality bases i doubt someone would just go and open outdated packages before he go and upgrade them in the normal mode (which he will for surely gonna face the question if he want to install x or y or none)

39

yes thats what it should be but not according to my experience, tbh not excited to open a ticket against that.

yes even with browser extension it doesnt fully kill it.

40

The only issue here is PEBKAC.

No, faulty browser extensions are not an issue with Chromium. Chromium has working and robust functionality to mitigate WebRTC privacy risks built in. It’s already enabled by default in many privacy-focused Chromium derivatives.

https://github.com/GrapheneOS/Vanadium/blob/11/patches/0041-most-private-WebRTC-IP-handling-policy-by-default.patch

https://github.com/bromite/bromite/blob/master/build/patches/Change-default-webRTC-policy-to-not-use-any-address.patch

I really have no idea what else you want me to show you.

41

@nurmagoz via Whonix Forum:

hmm if there is possibility to install the package while user first time boot live mode then not an issue, but if live mode without root access yes it will be a problem. On reality bases i doubt someone would just go and open outdated packages before he go and upgrade them in the normal mode (which he will for surely gonna face the question if he want to install x or y or none)

Mixing up things.

ISO live mode is not same as live mode.

ISO live mode means to boot from Live DVD (ISO) (or writing ISO to USB).