madaidans-insecurities / madaidans-insecurities.github.io Goto Github PK

Your website provided helpful information. I want to translate your articles into Chinese. But there isn't any license on the page, so I would like to ask if translation and redistribution of your articles are allowed.

I no longer can find the page that talks about OpenBSD. Why it got removed?

from Daniel Micay:

CalyxOS has serious privacy and security issues inherited from Android that are addressed by the improvements in GrapheneOS. For example, in CalyxOS, apps can record audio and track your movement (including determining location) via sensors without having any permissions. In CalyxOS, many basic mitigations like ASLR and stack canaries do not function properly.

On CalyxOS, an app can monitor your movement and record audio without any permissions. Exploits for Android can be used against CalyxOS unchanged, since it provides no additional defenses against them.

https://www.reddit.com/r/CalyxOS/comments/jzn9ko/just_discovered_calyxos_today_which_are_the/

Hi, I really enjoyed reading this very comprehensive guide. Just wanted to inform you that the hide-hardware-info script URL 404's:

The correct one:
https://github.com/Whonix/security-misc/blob/master/usr/libexec/security-misc/hide-hardware-info

Regards

The links in the website are put in a way that makes them not so accessible. This article is an example of links that aren't accessible https://madaidans-insecurities.github.io/firefox-chromium.html#security-researcher-views
See the MDN Web Docs For link best practices

Comparison between web browsers — Spyware Watchdog

Since iOS is a recommended operating system, it might be nice to have an article describing its mitigations and security features (such as PPL and PAC), similar to the Android article.

Your analysis of Firefox vs Chromium security says RLBox is only used to sandbox three libraries, the announcement blog post claims that it is currently applied to five libraries (and the dependencies of those libraries). Please address this inaccuracy, thank you.

Interesting topic, but I have a question that I hope they can answer for me.

You wrote:

By default, Android has a strong security model and incorporates full system SELinux policies, strong app sandboxing.

Rooting your device allows an attacker to easily gain extremely high privileges. Android's architecture is built upon principle of least privilege. By default, unrestricted root is found nowhere in the system due to the full system SELinux policy. Even the init system does not have unrestricted root access. Exposing privileges far greater than any other part of the OS to the application layer is not a good idea.

That sounds very good, but why are root vulnerabilities still possible?

Apparently this was fixed in Firefox 99, however it seems the gpu process still isn't enabled by default, so I'm not sure how they did it.
https://bugzilla.mozilla.org/show_bug.cgi?id=1129492

searching for filesystem=home or host is not accurate as many packages have ro or only subdirs access to the filesystem. You can also often use portals to replace the filesystem=host/home permission.

Please consider adding one and noting it on the pages.
Thanks!

Under "Browser":
adding new (Chromium-)Edge would be good as it's more secure then Chrome/ Chromium on Windows.

Under "Email":
web apps are not less secure, they just have problems with PGP. If PGP isn't needed, web apps are reducing the attack surface by installing a external app.

Under "General":

• Beside VeraCrypt, Bitlocker should be listed too.
• NoScript isn't needed as Browser's itself provide a UI for JavasScript controlling. Installing a extension for that only increase attack surface and reduce privacy

The website is a great source of security/privacy information, but it only considers security/privacy and not other important things. That should be clarified a bit more, since for newcomers it can be confusing to see blatant stuff like "Do not use Linux". These kind of broad statements also invite more...interesting types that only consider security and nothing else. Considering how the website gets constantly hated on Reddit, clarifying the security purpose would probably reduce that too.

I realize it already has

Note that these analyses are purely objective and do not account for threat models or other user-dependent factors.

but you should still explicitly mention non-security stuff like performance.

Putting a disclaimer in the index.html, and in the security/privacy guide, like:

This website only analyzes software security and privacy. It does not account for performance, usability, convenience, or anything else.

should be enough.

The central thesis of the Firefox versus Chromium article still stands, but some details have changed to narrow the gap between the two.

The most significant one: Mozilla has been working on a "utility process overhaul". You can see it at work in about:processes. They've shipped a separate network process for a while. Recently in Firefox 102 (the next ESR), they also moved audio decoding to the utility process.

They've also enabled ACG on the utility process.

Regarding oxidation: Firefox has been parsing untrusted content with Rust for a few years now, which is probably one of the best use-cases for a memory-safe language. Their ISO Base Media Format and CSS parsers are written in Rust. Given that CSS is the least-likely resource to be stopped by a CSP and SRI (the vast majority of sites allow unsafe-inline CSS and SecurityHeaders is actually planning on relaxing that requirement), I think it's worth treating it as a bit more dangerous strictly from the perspective of a browser's parser.

On the other hand, two areas I think are worth more attention on are Firefox's lack of PID namespace isolation and eventually the lack of good JITSploitation mitigations once Chromium rolls out its virtual memory cage. Safari already has one in its JIT-specific allocator.

In your analysis of Firefox and Chromium security, it is claimed that "Firefox does not have a multi-process architecture" on Android, which I believe is no longer the case. My personal understanding is that Fenix has a parent process, two content processes, a remote data decoder process, and a GPU process as of a few days ago. Additionally I feel it is important to mention that by default, Chromium on android does not have full site isolation, forks like Vanadium do though.

https://bugzilla.mozilla.org/show_bug.cgi?id=1530770
https://bugzilla.mozilla.org/show_bug.cgi?id=1331109

Kindly add information about the sandboxing Firefox offers on macOS, on https://madaidans-insecurities.github.io/firefox-chromium.

Firewalls such as AFWall+ or Netguard are regularly used on Android to attempt to block network access from a specific app but these do not reliably work — apps can use IPC to bypass the restrictions

Is there an example for this? Unfortunately I have not found an example. It would be nice if they could give one or more CVE numbers for this. A small example in their repo would also be perfect.

As of now NoScript is recommended on the 'Security and Privacy Advice' page.
But I am not sure it is a good idea to recommend it like that without asterisks.

1. Adding extra attack-surface and another party to trust
2. You are potentially making yourself more-fingerprintable if you block some domains and not others
3. Weakening site-isolation

Almost all browsers already have a per-site JS toggle making NoScript's main functionality somewhat redundant.
I did not look into NoScript's XSS and CSRF protection. So I can't comment on that

You already mentioned how PulseAudio is insecure, and to use standard ALSA utilities instead. However, that might not be feasible for many users.

What do you think of Pipewire? It's written with security in mind, and it works well out-of-the-box. It's still early in development.

Website: https://pipewire.org/

Flatpaks can not call syscalls like unshare, mount, chroot/pivot_root which are essential to setup a namespace based sandbox. This means flatpaks can not directly sub-sandbox it self and need to use flatpak-spawn instead.

The most chrom* and electron flatpaks use zypack to redirect the chrome-sandbox to flatpak-spawn. AFAIUI this means that the "good" chrome sandbox is replaced by the "weak" flatpak sandbox.

Should there be an "If you install chromium via flatpak the sandbox ..." note or do I understand things wrong?

The current text about signature spoofing is misleading:

MicroG is a common alternative to Google Play Services. It is often used to get rid of Google's tracking, but most people do not realise that this can potentially worsen security as it requires signature spoofing support which allows apps to request to bypass signature verification. This subverts the security model and breaks the application sandbox as an app can now masquerade itself as another app to gain access to the app's files. In a system with signature spoofing, it is impossible to know anything — there is no way to trust that an application is genuinely what it claims to be and it is impossible to build a strong security model upon this.

• allows apps to request to bypass signature verification: With signature spoofing, signatures are verified by the OS as usual. If apps implement signature verification themselves (for whatever reason) those would work as usual as well. Signature spoofing pops in after the OS verified the signature as usual when third-party apps ask the OS what the signing certificate of another app is without actually verifying it.
• an app can now masquerade itself as another app to gain access to the app's files: The masquerading of signature spoofing does not extend to the package management. This means that app updates must still be signed using the same key that signed the to-be-updated app - even if that app used signature spoofing. The only situation where an app with signature spoofing might be able to gain access to files that it shouldn't be allowed to get access to, is when other apps on the same system forward private files to another app that they (based on signature) assume to be authorized to receive those files. This is against the best practices outlined in the official Android security guide (which suggests using a signature restricted permission instead, which is managed by the package manager and thus would not be affected by the signature spoofing patch)
• there is no way to trust that an application is genuinely what it claims to be and it is impossible to build a strong security model upon this: First of all, it is trivial for apps to find out if another app has the signature spoofing permission and thus could spoof signature using the widely available signature spoofing patches. It is also possible for apps to verify signatures themselves instead of just requesting them, if it must be assured that the signature is valid and done using a specific key. However, I'm also not completely certain what kind of "trust" you're envisioning here: On a device owned and controlled by the user, apps can't trust that the user did not intentionally modify the device to better fit their own needs. A device where this is possible would not be in control by the user.

I'm here because someone claimed wrong things and linked to your website as a source. While your description is mostly not wrong per se, it is misleading enough for people to read it wrong.

Page : https://madaidans-insecurities.github.io/linux.html

Broken links :

https://www.csc2.ncsu.edu/faculty/xjiang4/pubs/ASIACCS11.pdf

https://www.graplsecurity.com/post/kernel-pwning-with-ebpf-a-love-story

On the linux hardening page, section 21.3.1

https://madaidans-insecurities.github.io/guides/linux-hardening.html#grub

It says

Create /etc/grub.d/40_password and add:
[...]

If I do that I get /etc/grub.d/40_password: 2: password_pbkdf2: not found

Those files seem to be meant to be executed, hence

cat << EOF
set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.......
EOF

and update-grub seems to work:

# grep -e password -e superuser /boot/grub/grub.cfg
### BEGIN /etc/grub.d/40_password ###
set superusers="root"
password_pbkdf2 root grub.pbkdf2....
### END /etc/grub.d/40_password ###

Matrix seems to be a decentralised, federated chat server/protocol. It also seems to be picking up in adoption. If you've got the time and the willingness, it might be a good idea to have a look at it?

About userdebug builds: "adds tons of debugging tools as extra attack surface"
You need to explain how significant the extension of surface attack is. There are already dozens of Turing Complete Machines available in a user build. The extension of SELinux policy is small compared to the holes most OEMs make in their SELinux policy.

"An attacker can fake user input by for example, clickjackers or they can exploit vulnerabilities in apps you've granted root to. "
Unlike the wording says, this isn't an actual attack. An attacker would need to find a security flaw for clickjacking. If user is using a Custom ROM, this isn't an issue, because Custom ROMs are always up-to-date with framework security patch, and the vast majority of clickjacks are framework-side.

The argument against root comparison with Linux is stupid. It's st ill harder for an attacker to get root on a root-ed Android device than on Linux. Even root-ed, the security of an Android is still much higher than of GNU/Linux. So yes using a root-ed device is still pretty secure.

"exposes root access via adb" this requires both physical access, and clickjacking exploit to be usable. This is still much more secure than application-facing root, and thus still infinitely more secure than any desktop OS.

"disables verified boot" even though it's true, it's already part of "unlocked bootloader" by design of Android, so it's redundant.

"It does not implement rollback protection" again, this is exactly the same argument. Also, please list OEMs that properly implement rollback protection. I believe even Google pretty much never uses rollback protection.

"It does not include firmware updates which prevents you from getting new patches to fix vulnerabilities." That's just plain wrong? kernel-wise (which in Android is considered "firmware update", I don't know if you do), Lineage is always ahead of every single OEM, including Pixels. They often include updated blobs from OEM when OTA appear.

"requiring signature spoofing which allows apps to request" Assuming this is behind a "privileged" permission, this requires secure-boot break of chain to exploit. If you break secure-boot chain, you don't fucking care about spoofing an app's signature.

"Firewalls" That's why users are additionally work profiles, for instance with Island for Android.

"Conclusion"
GrapheneOS doesn't give any answer to the "Firewall" section. Google is notorious for using very old version of Qualcomm's BSP, so following Linus' "Every bug is a security bug", Google is missing a lot of "firmware" security fixes

IOMMUs aren't exclusive to Pixels, by a wide margin.
Hardware-backed keystore is a requirement for every single Android device running Google applications. You should rather mention Pixel >= 3 have tamper-resistant keystore.
"hardened basebands", your source doesn't say this hardening isn't for all Qualcomm devices.
kernel CFI is "STRONGLY RECOMMENDED" in CDD, so you can bet most flagships already have it as well.
So, you haven't been able to list a single positive security aspect of Pixels. There is indeed one with Pixel, but using any 10€ SIM card as keystore would achieve the exact same feat.

"Verified boot is not just for local security as many people assume. Its main purpose is protection against remote attackers and the physical security is a nice side-effect. " This is bullshit.
The only positive aspect of verified boot when it comes to remote attackers is to prevent persistence, nothing else. If you find an exploit to become root, you'll become root, no matter whether there is verified boot or not.

The name of this website is 'madaidans-insecurities', but I don't see any insecurities.

I also have root rights on a PC. What makes smartphones so dangerous that root rights are not recommended there?

Fscrypt is a transparent file encryption tool that Android uses for their encryption implementation. It's more fine-grained than full-disk encryption like dm-crypt. TPM provides a coprocessor to handle keys, like in smartphones., though it's not nearly as good.

Together they can provide a decent desktop encryption implementation. This is worth adding to the hardening guide, under physical security.

It would be useful to add an item to the Linux Hardening Guide with installing and configuring Tor (configuring bridges, configuring iptables/nftables, DNS, etc.)

The Android page conclusion (https://madaidans-insecurities.github.io/android.html#conclusion) should be updated now that Pixels have dumped Qualcomm SoC and using Tensor instead. Also TitanM2

Hello, it appears that starting with Firefox 100, they have restricted access to Win32k, according to this article: https://hacks.mozilla.org/2022/05/improved-process-isolation-in-firefox-100/

Last commit was in april 2022. There are a few pull-requests open, which I personally like to see get merged.

https://madaidans-insecurities.github.io/encrypted-dns.html

Encrypted hello (ECH) (upcoming) will improve things.

You should sign your GitHub commits to avoid unwanted manipulation:
https://help.github.com/en/github/authenticating-to-github/managing-commit-signature-verification

In e.g. my repository you can see how it looks

I can't find any details about vulnerabilities related to Magisk/AddonSU. Do you have a link with an overview?

And in addition, because it matches the topic:

It does not matter if you have to whitelist apps that have root — an attacker can fake user input by for example, clickjacking or they can exploit vulnerabilities in apps that you have granted root to.

Do you have an example for this? Unfortunately I have not found an example. It would be nice if they could give one or more CVE numbers for this, e.g. from here: https://www.cvedetails.com/product/19997/Google-Android.html?vendor_id=1224