qfile-unpacker permission-hardener whitelist security issue

[adrelanos]

Originally posted here: https://github.com/Kicksecure/security-misc/issues/162

@monsieuremre

The Qubes vulnurability ticket. The package that causes the vulnurability to escelate privileges to root,

reference:

• https://github.com/QubesOS/qubes-issues/issues/8633

Important to point out it the impact:

• Only applies to Qubes because binary qfile-unpacker is only a thing in Qubes. It's part of qubes-core-agent Debian package. Nobody installs this on plain Debian or Kicksecure ("non-Qubes Kicksecure"). It's unavailable from packages.debian.org. Only Qubes Templates have qfile-unpacker installed by default.

This issue would not be resolved by porting to another base distribution - if this is also to be made available as a Template for Qubes. The only options are to not whitelist qfile-unpacker or to fix the issue at the root by patching Qubes.

At time of writing by Qubes default (what presumably most usess use), this does not matter much because Qubes enabled passwordless sudo by default. So this only applies to users having at least "basic" sudo hardening or maybe systemd units under different user accounts (without access to passwordless sudo). References:

• https://www.qubes-os.org/doc/vm-sudo/
• https://github.com/QubesOS/qubes-issues/issues/2695

is whitelisted in our hand written service.

https://github.com/Kicksecure/security-misc/blob/master/etc/permission-hardening.d/25_default_whitelist_qubes.conf

[monsieuremre]

Anything that we whitelist in as a suid binary, we should make sure is covered by a profiles in apparmor.d, and we should depend on apparmor.d. This way, any suid/sgid binaries on the system, that we allow, are guaranteed to be protected by an enforcing mac policy. I will go ahead and also propose that we enable hardened malloc for suid/sgid binaries. This can be done with aliases or custom desktop files.

This is the very same suggestion I made for network facing daemons in #186.

Yes suid and sgid can open possibilities for privilege escalation and exploits. But I think an enforcing mac policy + hardened malloc on these binaries would really minimize the attack surface opened by suid bits. This, is the least we can do, which is actually not that little and can be very effective.

[adrelanos]

Seems off-topic.

For this issue, really the only solution is for Qubes to fix this at the code level -> https://github.com/QubesOS/qubes-issues/issues/8633

However as said above, this issue isn't introduced by security-misc and doesn't affect non-Qubes. Only a Qubes issue.

Btw that issue does not sound like hardened malloc could help. It does not sound like a memory corruption issue. Sounds like an architectural issue.

apparmor.d however might be able to mitigate (but not fix) this issue if specifically a great profile was written for qfile-unpacker (which only exists in Qubes). But that program really needs to be fixed at the root and not with a bandaid.

---

apparmor profiles for suid's sounds also nice but that seems like a feature for apparmor.d I didn't check it has this feature or not.

---

• Packaging apparmor.d for Kicksecure, uploading to Kicksecure repository: yes (once I get to that)
• Install apparmor.d in Kicksecure by default as project goal: Yes. That would be great.

Implementation detail:

• Depends: on apparmor.d in security-misc: no (reasoning in https://github.com/Kicksecure/security-misc/issues/169)
• Depends: on apparmor.d in kicksecure-meta-packages: Potentially, yes.

This can be done with aliases or custom desktop files.

Aliases?

Reliably prepending - forcing (!) - hardened malloc, any environment variable or wrapper is a hard problem on Linux. Also a hard packaging issue.

There's really no good way to prepend any wrappers for a Linux distribution. Desktop files among the bad solutions. This needs to be re-animated:

• https://phabricator.whonix.org/T634
• https://github.com/Kicksecure/proposals/blob/master/634-stackable-wrappers.txt

Above is more about "useful" wrappers being prepended, the packaging issue.

But in context of what you're suggesting... Consider malware running on the system. Let's pick some SUID as example. Chromium... If the desktop file of chromium was modified to prepend hardened malloc, that might help. Except, well... [1] But hardened malloc might improve the security of the SUID.

But when malware is running on the system, we need to look at this from an adversarial viewpoint and not a useful viewpoint. Malware wouldn't make use of the chromium SUID through its desktop file. It would just start that binary directly.

And if we move chromium to chromium.orig which chromium is the wrapper that prepends hardened malloc and chromium.orig is the real binary (by using config-package-dev which uses dpkg-divert) (similar to how Whonix package uwt is doing this), then it is easy for malware to circumvent this mechanism. Because then malware can just run chromium.orig.

For full protection, apparmor.d would need to allow the user only to execute chromium (or chromium.wrapper) and only chromium.wrapper being allowed to run chromium.

So this is getting really complex and hard to implement.

Qubes has a "far in the future" tag for this kind of feature requests.

---

[1] Browsers don't work well with Hardened Malloc because these use their own memory allocators and ignore hardened malloc. References here: https://www.kicksecure.com/wiki/Hardened_Malloc#Browsers

[monsieuremre]

Seems off-topic.

Yes it is.

I think I made the wrong impression. I know this vulnurability won't be fixed with hardened malloc. This suggestion is not for this specific exploit. I am suggesting that we set apparmor profiles and hardened malloc for all suid/sgid binaries to protect them from exploits as much as possible.

apparmor profiles for suid's sounds also nice but that seems like a feature for apparmor.d I didn't check it has this feature or not.

This is not a feature. There are no suid binaries besides what we manually allow. And we can make sure the paths that we manually allow are protected with dedicated profiles, which they are with apparmor.d. We will just make sure these are enforced.

And if we move chromium to chromium

Unrelated, but as I said, I do not suggest this motion. Anything chromium or electron should be avoided as much as possible. It is the least one can do to not give in to the monopoly. Yes some sandboxing features are missing on firefox, expecially gpu related ones. But they are on the way. They exist already in firefox, being tested and integrated slowly. In terms of security, gecko has made some big leaps and is closing the gap. With the dedicated options we can enable these early features already, as I already suggested in the other pull request.

Also I have to mention, no chromium based browser comes not even remotely close to achieving the fingerprinting protections a hardened firefox can offer, not even close. Brave and others only trick naive scripts.

But yes, coming back to the topic, I think we can enable hardened malloc on select vulnurable binaries and services manually. This is better than not doing anything at all. And also, IMO apparmor.d should be in kicksecure's priority list, in the first place probably, right next to wayland.

[adrelanos]

I think we can enable hardened malloc on select vulnerable binaries and services manually.

As said in my previous post, selective enabling of hardened malloc (not really a HM issue, same for wrappers, environment variables) is difficult.

If selective enabling for some things (SUID) then why not many more things (which which feature requests I guess are almost guaranteed to come). Therefore this mechanism to opt-in would need to be very solid with an easily extensible configuration.

To avoid a complex, much used opt-in mechanism, it might be easier to enable hardened malloc by default. However, there are some issues. Most unknown to fix one are those preventing browsers to start. Reference: https://www.kicksecure.com/wiki/Hardened_Malloc#Issues

---

related to browsers:

• https://www.kicksecure.com/wiki/Dev/Chromium
• https://www.kicksecure.com/wiki/Dev/Default_Browser

---

Unrelated, but as I said, I do not suggest this motion. Anything chromium or electron should be avoided as much as possible. It is the least one can do to not give in to the monopoly.

Let me guess, you don't like chromium due to Web Environment Integrity (WEI) (and similar worse old, new and upcoming stuff) and by extension also not electron because that's basically a desktop GUI wrapper depending on chromium? Well, I would probably agree with this.

related criticism of Chromium: https://www.kicksecure.com/wiki/Miscellaneous_Threats_to_User_Freedom#Chromium

[monsieuremre]

It might be easier to enable hardened malloc by default. This is obviously the more preferable and the more robust way of doing things. I would support this motion. But I am not a fan of your way of exempting applications from hardened malloc. You are using bubble wrap. This is just very wrong, because what if I want to use bubblewrap to sandbox stuff, wouldn't this be a problem?

Anyway, but there is probably no need to exempt stuff, except one thing. The only non-user application that seems to have problems is cryptsetup. We can just exempt that with systemd environment variables in its unit config.

For user applications, like browsers etc, flatpaks are uneffected as you point out. Let's just promote flatpaks then. On a system like debian, it is the superior option anyway. The applications are often from their official developers, and always up to date. Having Firefox and Thunderbird packaged by Mozilla with the latest version is a better option than depending on the debian team. This would not be something ground breaking. A lot of distros are doing this already. Immutable distributions do this too. I feel like this would be a solid option.

[adrelanos]

For user applications, like browsers etc, flatpaks are uneffected as you point out.

uneffected is an understatement. Browsers crash, fail to start, completely unusable using the wrapper to disable hardened malloc as documented.

But I am not a fan of your way of exempting applications from hardened malloc.

Me neither. But no better solution has been found, suggested yet.

You are using bubble wrap. This is just very wrong, because what if I want to use bubblewrap to sandbox stuff, wouldn't this be a problem?

Yes. Same issue as with Flatpak, I guess. Once bubblewrap is used (Flatpak uses bubblewrap), hardend malloc is ignored inside the sandbox anyhow.

(There might be a solution for this issue. A different project recently implemented it. But we don't have it at time of writing. References here: https://forums.whonix.org/t/bug-hardened-malloc-ignored-by-flatpaks/18199)

Anyway, but there is probably no need to exempt stuff, except one thing.

How about browsers?

For user applications, like browsers etc, flatpaks are uneffected as you point out.

Making them use hardend malloc is non-trivial.

Let's just promote flatpaks then. On a system like debian, it is the superior option anyway. The applications are often from their official developers, and always up to date. Having Firefox and Thunderbird packaged by Mozilla with the latest version is a better option than depending on the debian team. This would not be something ground breaking. A lot of distros are doing this already. Immutable distributions do this too. I feel like this would be a solid option.

I am not sure going all-in on Flathub being great idea, very off-topic. But it certainly motivated me to look into this more. New wiki chapters here, just now written:

• https://www.kicksecure.com/wiki/Install_Software#Flathub_Package_Sources_Security
• https://www.kicksecure.com/wiki/Install_Software#Flatpak_Criticism
• https://blog.frehi.be/2023/04/23/the-security-risks-of-flathub/

[monsieuremre]

uneffected is an understatement. Browsers crash, fail to start, completely unusable using the wrapper to disable hardened malloc as documented. Making them use hardend malloc is non-trivial.

I meant unaffected because they don't use hardened malloc by default. I was suggesting that we let them stay that way. Root processes, daemons and everything with privileges will be using hardened malloc. I think flatpaks not using hardened malloc is definetely passable considering all the security benefits we would get despite of it.

I am not sure going all-in on Flathub being great idea, very off-topic. But it certainly motivated me to look into this more. New wiki chapters here, just now written:

I want to make stance clear. When it comes to flatpaks, I am not a big fan of all flatpaks. I use and support only verified flatpaks. Because in essence, a non-verified flatpak is just like the AUR, which I also do not like, because purely theoretically speaking, any random schmo can package stuff there, and there is no holding anyone liable. So no, I am not in support of installing "chromium" or anything that is unverified from flathub.

Verified flatpaks, on the other hand, are far more superior to any packaging option out there. Debian team packaging firefox, will not, and can not be as reliable, as secure or as fast in providing updates than mozilla the actual people behind firefox themselves.

Flatpaks sandboxing is just a perk, that is imperfect for most applications by default. We can easily set our own bubblewrap overrides for flatpaks tho, and set strong sandboxing options.

Anyway, I think you can close this issue because it seems to get really off topic and the issue itself does not need a ticket here.

[adrelanos]

I want to make stance clear. When it comes to flatpaks, I am not a big fan of all flatpaks. I use and support only verified flatpaks.

Because in essence, a non-verified flatpak is just like the AUR, which I also do not like, because purely theoretically speaking, any random schmo can package stuff there, and there is no holding anyone liable. So no, I am not in support of installing "chromium" or anything that is unverified from flathub.

Glad we agree here.

Verified Flatpaks don't have this issue but the way Flathub is setting up Flathub it's easy for users to confuse what is verified and what is not. Also it's promoting proprietary and vulnerable software. When searching for pdf reader to shows the proprietary, abandoned, probably vulnerable Adobe Reader..

NOTE: This software is unmaintained by the vendor and may contain security vulnerabilities.

NOTE: This wrapper is not verified by, affiliated with, or supported by Adobe.

This is setting up users for failure.

If an advanced user knows to use only verified Flatpak that is probably okay but if Flatpaks are installed by default that might be construed as endorsement and promotes its use.

Flatpaks sandboxing is just a perk, that is imperfect for most applications by default. We can easily set our own bubblewrap overrides for flatpaks tho, and set strong sandboxing options.

Sandboxing should be attempted to push upstream first in the Flatpak. Only if that fails should be considered downstream in Kicksecure.

Probably should go into a dedicated package. kicksecure-flatpak-integration or however that could be named to have a more generic package name so it could also cover alternatives to flatpak, flathub (snap but not really just in theory).

One strong reason reason for a dedicated package is that kicksecure-flatpak-integration needs to run command flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo or better ship an equivalent config file to enable the flathub repository by default. It's not the job of security-misc to enable the flathub repository by default.

Anyway, I think you can close this issue because it seems to get really off topic and the issue itself does not need a ticket here.

Right. This issue isn't caused by security-misc. It's a Qubes issue and has a ticket there.

[adrelanos]

• https://github.com/flatpak/flatpak/issues/5654
• https://forums.whonix.org/t/flatpak-as-a-software-source-flathub-as-a-source-of-software/8500/57

[adrelanos]

qfile-unpacker was fixed upstream in Qubes.