Chromium Browser for Kicksecure Discussions (not Whonix)

Viewing the situation as of 14 March 2021:

More details in wiki:
Remotely Exploitable Chromium Security Vulnerability CVE-2021-21193 exploited in the wild

Chromium is basically all independent upstream. The relevant ones available for Kicksecure all lag behind with security critical updates.

2 Likes

Viewing the situation as of 03 April 2021:

1 Like
  • Both, FlatHub and Snap Store had a more than 2 weeks gap between Google reporting a security vulnerability being exploited in the wild and these software stores pushing an upgrade.
  • Debian chromium package is still vulnerable.

Exploited in the wild is a crucial difference here. That’s the line between theoretic considerations and security in the real world.


03 April 2021


Due to my above two posts and this post…

Firefox and Chromium | Madaidan's Insecurities may I suggest to replace Chromium with Chrome? @madaidan

It sounds right in theory but all the security mitigation in Chromium didn’t help to avoid this vulnerability being exploited in the wild. We should prioritize security in the real world over theoretic considerations. Despite all security innovations in Chrome / Chromium, that didn’t actually help users in the real world if Chromium maintenance (new releases with security fixes) lags behind Chrome. Maintenance is unfortunately something that cannot be excluded from the security comparison.

Now for more than 2 weeks Kicksecure would have had the choice to either install by default:

  • Firefox: No security vulnerabilities reported being exploited in the wild.
  • Chromium: At least 1 vulnerability reported being exploited in the wild.

More theoretic considerations…

Additionally, users on the Linux platform [1] had to choice:

Kicksecure Freedom Software doesn’t have the chance to install Chrome by default because it would then become non-freedom software. Even when mixing Freedom Software with non-freedom software, I wouldn’t know if Chrome could be legally re-distributed. I haven’t found license agreement for Chrome yet.


The question of the Kicksecure default browser, Debian’s Firefox ESR (or from any other Firefox from alternative sources) versus any Chromium unfortunately now got less clear to me.


[1] Leaving out Windows from considerations since this is about what to do in Kicksecure, Freedom Software, Linux based.

Everything in the article still applies to Chromium. Independent parties packaging it insecurely doesn’t affect the security of it upstream.

Looking into Flatpak more, it appears they disable Chromium’s Layer-1 sandbox and replace it with the much weaker Flatpak sandbox for seemingly no reason: https://github.com/flathub/org.chromium.Chromium/blob/master/patches/0005-flatpak-Add-initial-sandbox-support.patch

I’ve also heavily updated my Firefox article recently and I’m going to push another update soon.

1 Like

madaidan via Whonix Forum:

Everything in the article still applies to Chromium. Independent parties packaging it insecurely doesn’t affect the security of it upstream.

Worth mentioning distribution issues, though. Since it makes a big
difference for theory/practice.

Then Chromium upstream doesn’t really act like a usual upstream. No
stable releases. That link goes to Chrome instead. As mentioned earlier.
No (gpg) signed releases.

Since Chromium doesn’t really maintain a stable release upstream, that
results in this insecure situation in downstream Debian.

1 Like

I find too many unresolved vulnerabilities in Debian’s Chromium security tracker. For now, is it better to use Firefox instead?
I don’t think Chromium from Debian will get any better soon, is it better to switch to a decent Chromium stable upstream? (I’m not aware of any stable upstream though) Maybe use Brave?

Firefox isn’t much better. Even assuming that Debian’s packaging of Firefox is flawless (it almost certainly is not), it’s still using an ESR build which inherently has many public, unfixed vulnerabilities upstream that can’t be patched even if Debian were to keep the package updated.

We might have to use another upstream, Chromium from Debian is even worse than Firefox (and Firefox-ESR) from Debian.

Discussed earlier. Doesn’t exist.
Chromium Browser for Kicksecure Discussions (not Whonix) - #27 by Patrick

Switched out chromium for firefox-esr because as things stand, chromium on Linux has very big problems with stale bug fixes compared to Mozilla.

https://gitlab.com/whonix/kicksecure-meta-packages/-/merge_requests/1/diffs?commit_id=7ba985581cfd02092186bc8cbe584ac4c0f086f9

1 Like

Not reverted.
You only added to dummy-dependency.
For such changes, you need to search the whole file for chromium, better the whole source code, best all source code. In this case, whole file would have been enough.
Meta package kicksecure-desktop-applications-recommended wasn’t changed.

That should do it for chromium, but it doesn’t add firefox. Should firefox-esr be added everywhere chromium was mentioned?

1 Like

When appropriate. It can be seen from the context. From the package name as well as the description and the other fields.

There is:

  • Package: kicksecure-desktop-applications-recommended
  • Package: dummy-dependency

Still missing firefox-esr under Package: kicksecure-desktop-applications-recommended in the Depends: list.

Done

1 Like

I don’t know if the situation has improved or not since 2021, but alternative packaging systems that have fresh versions of FF and even thunderbird are perhaps the best option. I don’t know if this gets around opengl dependency woes though (which is the main reason holding newer releases from being published in deb repos).

1 Like

This is factually incorrect now that the declarativeNetRequest API is out and ad/tracking blocking extension developers got their hands dirty with it.

Let’s also add the very important “DRM for the Web” proposal by Google which was already committed (disabled by default, behind a flag) into Chromium:

I don’t see how anyone could advocate for the inclusion of a browser (Chrome / Chromium) made by and for an advertising and spyware company even if it has bullet proof vulnerability defense.

1 Like

Long discussion on Kicksecure default browser happening here:


Added to default browser developers wiki page:
Comparison of Browsers

1 Like

Just read through the above discussion and did some documentation updates earlier today. This is me trying to distill down my thoughts on the issue so far.

IMO, we absolutely must use a browser that has some dedicated, skilled, preferably paid development team behind it, that can reliably push out updates when necessary and deal with security issues in a timely fashion. While all of these other projects that make their own variants of Firefox or Chromium are neat, there are two potential severe issues that can result if we use one of them:

  • Update lag. An update just not getting pushed out to users for a week could (in severe situations) be fatal to the user’s security. Browsers are the perfect storm of problems that make them attractive to an attacker - they’re absolutely massive applications built in unsafe programming languages, they’re very performance-sensitive (thus vulns can sneak in during optimization) they deal with unimaginable quantities of very complicated untrusted data all day every day, much of which is executable code, they’re probably the most often-used application on a user’s computer, and they have access to an extremely large amount of sensitive personal and financial information for most users. Thus the browser is one of an attacker’s most lucrative targets. No matter how secure (or not secure) a browser may be, attackers are going to be throwing their resources into finding security bugs that they can exploit. They succeed in finding issues often (Escaping the Chrome Sandbox Through DevTools is a particularly good article documenting how someone found one such issue). Thus we should assume if a browser is out of date, it’s already being actively compromised in the wild. Updates have to be very timely.
  • Projects going unmaintained. This is an even worse issue than update lag, because if someone just stops maintaining their project, now we have an entire userbase using an eternally insecure browser, that we can assume is being actively exploited in the wild. Not good. There are lots of browser forks that have died - Bold Browser (previously a Brave fork, then an ungoogled-chromium fork) is one, Light (a Firefox fork I used on Puppy Linux some time back) is another. Migrating users off of an abandoned browser would be a nightmare from a technical perspective, and it would be something that would have to be done very very fast for user security. We’d also have to actually know the project was abandoned, and if the project gets silently abandoned, it might not be possible to tell a truly unmaintained project from a project with a bad case of update lag. We would probably not be able to start migrating users to a different browser until they had been left vulnerable for a very significant period of time.

This basically narrows us down to the two big players in the browser world, and some of the better-known and better-maintained forks. I would consider Firefox (ESR), Chromium, Brave, IceCat, Base Browser, and maybe Trivalent (though secureblue is a somewhat new project and seems to be mostly run by one guy, so Trivalent could be dangerous even if it is amazing from a security hardening standpoint). Pretty much all of the others (Waterfox, Pale Moon, Floorp, Zen, potentially even Librewolf) are too scary for me. I’m reticent to list even IceCat because last I checked (which was earlier today) there were only three people maintaining it. But there is the fact that GNU has some serious issues with non-free JS, so if all three maintainers were to vanish into thin air, I find it likely that GNU would find people to pick up where they left off pretty quickly.

All of the above browsers either definitely support both x86_64 and arm64 (Firefox (ESR), Chromium, Brave) or probably support x86_64 and arm64 (IceCat, Base Browser, maybe Trivalent though it has things with hardened_malloc involved so there might be some fun problems there). So architecture considerations aren’t likely to be a problem here.

Getting the latest supported version of one of the above browsers may or may not be tricky:

  • Firefox ESR - In Debian’s repos, good, we already use this. Has security concerns.
  • Firefox - Mozilla offers an official repo for Debian Stable that provides the latest versions of Firefox (not ESR). However, I believe this only provides x86_64 builds, not arm64.
  • Chromium - As covered above, there isn’t any trustworthy, universal source for a pre-built Chromium deb package. Even if there was, it might suffer from update lag and maintenance issues very similar to a Chromium fork. Debian’s repos suffer with very bad maintenance problems with Chromium every so often.
  • Brave - Offers an official repo for Debian Stable that supports both x86_64 and arm64.
  • Base Browser - Not distributed in binary form at all, we’d have to extract it and build it ourselves.
  • IceCat - Only distributed in source-code format and as a Guix package. I tried installing the Guix package earlier today, it was an absolutely horrible experience for a new user, plus that would require introducing a whole new package manager into Kicksecure. So effectively we’d have to build it from source.
  • Trivalent - Binaries are only available for secureblue, the source is available and the build instructions are very Fedora-centric. Unsure how hard this would be to make work. It’s also intended to work with hardened-malloc (which secureblue has enabled system-wide), if we wanted to get the full security advantages we’d probably have to ship hardened-malloc alongside Trivalent somehow which could be hard. We can’t enable it system-wide because that caused serious problems in the past.

Of the above browsers, we probably want to avoid the Firefox ESR derivatives, since we’re already using Firefox ESR and are dissatisfied with it. That means Base Browser and IceCat are no good. Of the remaining options, I would omit Brave, because Brave has been caught doing worrisome things over and over again, injecting affiliate links into the address bar, hijacking ads, installing a VPN service without permission on Windows, and some other things. They may not be leaking data during normal use, but to me this seems kind of like installing bulletproof windows only to leave the front door unlocked and wide open. A service or app is of no use from a security or privacy standpoint if the creator can’t protect their users from themselves. This is a shame because this is like the only well-maintained browser for Linux that supports arm64 and provides an official repo.

That means that if wwe’re really going to try to avoid building anything from source, and we want to avoid Firefox ESR, we have one choice, which is to provide the official FIrefox binary on x86_64 and continue to use Firefox ESR on arm64. If we want to do anything beyond that (that’s noticeably better than just using Firefox ESR anyway), we get to set up some build infrastructure of our own.

If we did go with the option of setting up our own build infrastructure (which I know is something we’ve tried to avoid), probably a good starting point would be:

  • Pick a browser. If we think secureblue is going to stick around into the future, I’d pick Trivalent, otherwise vanilla Chromium is probably the best option.
  • Try to build it locally. Chromium isn’t easy to build locally, but it can be done, and Trivalent seems to go out of its way to make it fairly easy.
  • Figure out how to automatically detect and attempt building it every time a new browser version is out. The Linux Mint people are probably the ones to talk to about this since they’ve been down this road and acheived success.
  • Set up x86_64 and arm64 build infra for this. Realistically we’d probably have to use cloud services for this, which would incur some amount of cost.
  • Ideally, we should not make this just part of the Kicksecure repos, but should maintain it in a separate repo that anyone can then use without making a FrankenDebian. Then whoever ends up down this road next can use what we provide for their project and this problem of “how do I build Chromium” will finally be solved.

Last idea to discuss, I was working on updating the Wiki with more default browser info, and ran into an interesting project listed there called ffprofile (Kicksecure Default Browser - Development Considerations). I looked into this tool a bit, and it looks like the basic idea it implements is a really good alternative to the plethora of Firefox customization projects that are out there (which may be opinionated in ways we don’t like and neither do our users). However, it has some serious problems with the way it’s implemented as a server-side app that that you download your chosen configuration from. It’s also a pain to use locally. It might be worth taking that project and re-implementing it as a desktop app that users can use to quickly reconfigure Firefox to be more secure, with sensible defaults applied that would provide the configuration we think is recommended. Then the user would be applying the config themselves, which dodges the legal issues with customizing Firefox’s configuration that have been discussed elsewhere.

1 Like