Would Vanadium secure against phishing sites?

DynamicGlow

This is a noob question (new to grapheneOS) but I was browsing some "websites" and was carless and went to a malicious link or two. These are the virustotal links for the URL analysis

https://www.virustotal.com/gui/url/b163327621ff046384359cde3cc8eefb025cd8f10a13718a6fab392ec36a1ce2/detection

https://www.virustotal.com/gui/url/a6fedb1cb1c821a3b354d9f309b136efde3d120bd49837698f05dcaff4f536d1

I do not know under the hood what these URLs could have done when I was on them. Could anyone in the know tell me if in this particular case I am safe as far as vanadium allowing the pages to execute malicious code on my phone? Thanks!

P.S. what would be the best course of action for me to take from here?

Benjamasu

DynamicGlow I believe it is a good practice to disable JavaScript by default and only enable it for trusted sites or when necessary. It is also better to browse the Internet in incognito mode so that permissions are not saved permanently.

I am not an expert on this matter. I would assume that if you are updated to the latest version (OS and browser), the probability of a non-targeted exploit of vulnerabilities working in Vanadium is very low. But that is just my speculation.

And, as graphny recommended, it's a good idea to set up blocking for known malicious websites. This can reduce the chances of accidentally visiting such sites, but obviously, it doesn't protect against ones that are not yet known.

You can use the RethinkDNS app for this, for example. Or use (on its own or together with RethinkDNS) DNS servers (public or private) with filtering.

Watermelon

DynamicGlow (Note that “phishing” means trying to attack you as a person by tricking you to give personal info. What you're asking about is how well Vanadium protects you from exploits — when a website tries to attack your software.)

DynamicGlow as far as vanadium allowing the pages to execute malicious code on my phone?

DynamicGlow P.S. what would be the best course of action for me to take from here?

DynamicGlow what is the verified boot mechanism?

First of all, rebooting is a great advice. The other advice is always running the most up-to-date software, both the OS version and all apps in the built-in App Store.

I think you might enjoy reading these:
https://grapheneos.org/features#anti-persistence
https://vanadium.app/
The short version is that GrapheneOS has these features, partially inherited from Google's Android and Chromium:

Every time you reboot the device, the entire operating system (including all preinstalled apps like Vanadium, Auditor, etc) are either reverted to a known clean state as the GrapheneOS project created them if anything was changed on your device and it's possible to revert it, or blocked from being loaded if impossible to revert. So every time you reboot, you know all GrapheneOS software on your device doesn't have any modifications by an attacker. GrapheneOS extended this guarantee also to updates to all system apps and preinstalled apps, like Vanadium, installed outside of what's included in your current OS version (e.g. updates from the built-in App Store, although the OS doesn't care which source you get the updates from). In normal Android, the OS verifies updates to system apps only when you update them, but not at boot.
GrapheneOS extends this guarantee so it wouldn't happen just when you boot the device and when updating a system app, but all the time (on every read of the app). Every time you use Vanadium, the OS verifies that the Vanadium app wasn't tampered by an attacker, and blocks the app from running if it was tampered. Although, I still think rebooting is a great suggestion if you feel like you need to, as an extra measure — your device starts verifying all GrapheneOS software from scratch every time you reboot. Normal Android verifies all the time only the code/data loaded from the system partition, but not updated versions of system apps updated through an app store.
Every site in Vanadium is isolated into a tight sandbox, so that if it corrupts the “browser”, it actually corrupts only a dedicated browser process created just for this site, not shared with other sites. Every element embedded within a site you browse that's coming from a third-party site not the one you browse currently is also further isolated within its own isolated process, not shared with its own process when browsing it directly (so if you have two tabs open, google.com and facebook.com, and within the google.com page there's an element from facebook.com, you'd have three separate processes: one for google and two for facebook). And by “third-party”, I mean even a different site within the same top-level domain as your current site is considered by Vanadium as a “third-party” site. In normal Chrome, sites from the same top-level domain (such as www.google.com and mail.google.com both coming from google.com) share the same browser process, and Chrome can degrade isolation even further if it detects your device doesn't have enough physical memory (RAM).
Vanadium completely disables JIT compilation of JavaScript and WebAssembly code for all sites by default. This prevents sites from exploiting vulnerabilities in the JIT compiler. In normal Chrome, JIT cannot be disabled completely.
Vanadium blocks all dynamically created/injected code inside sites' processes. As for your question if a malicious site can execute malicious code, the answer is “basically no”. Only code that's part of the Vanadium code as it's stored in the app code, not created during your browsing, is allowed to run. Vanadium uses OS features to enforce this on site processes. This is only possible when JIT compilation is disabled, because the whole point of JIT compilation is to generate optimized website JavaScript code just-in-time during browsing. Normal Chrome doesn't do this, even on GrapheneOS.

And if all of this isn't enough, all apps, including Vanadium, are contained within their own sandboxes. If a website somehow manages to completely compromise the Vanadium app, it can't spread to other apps, and can't abuse any OS permissions you revoked from the Vanadium app. GrapheneOS tightens the sandboxes of apps, and tightens the kernel against attacks from rogue apps, and more. (The kernel is the highly privileged core of the operating system, and it also plays a part in enforcing/providing some of the security features. So obviously it's very important to secure it.)

graphny

From Wikipedia

Phishing is a form of social engineering and a scam where attackers deceive people into revealing sensitive information[1] or installing malware such as viruses, worms, adware, or ransomware[....]Attackers use spoofed login pages and real-time relay tools to capture both credentials and one-time passcodes

So, did you enter anything there? If not, maybe you are good(?)
I can't visit those sites, because both are blocked by Hagezi's and 1hosts's blocklists. It's why you should used these DNS blocklists.

DynamicGlow

graphny It said phishing, and while I do know what phishing is, I didn't know if they had anything else in them that had some js exploit

DynamicGlow

graphny I forgot to mention block redirects and popups was on, and the pages were blank when I went to them

DynamicGlow

Benjamasu just disabled js and added exceptions. Thanks for the tip!

Benjamasu

@DynamicGlow In such cases, you can also reboot the device to utilize the Verified Boot mechanism. Perhaps that will give you some peace of mind.

DynamicGlow

Benjamasu what is the verified boot mechanism? Thanks for the help!

DynamicGlow

Watermelon OMG thanks for the detailed answer! But does the rebooting process verify the integrity of the whole OS and all apps or just vanadium?

CGG

Watermelon Absolutely perfect. Great response.

Watermelon

DynamicGlow But does the rebooting process verify the integrity of the whole OS and all apps

It verifies all of the Pixel firmware from Google, all of the OS, and all of the preinstalled apps. GrapheneOS also publishes some of their apps on Google Play Store — they install as a separate variant like a new app, side-by-side with the preinstalled variants, and these aren't verified.

DynamicGlow

Watermelon thanks for the help! Your great!

DynamicGlow

Watermelon sorry ONE more question. If AOSP has a lot of these security features, how come malware is so prevalent on android? Just curious because if all androids have verified boot and chromium security features, how does malware have such a prevalent presence and even an attack vector?

Watermelon

DynamicGlow These security features are meant to let you enforce permissions on apps, isolate them from each other, etc. They're not meant to prevent you from running certain software, or stop you from granting a permission to a bad app that doesn't really need it. Malware probably works just as well on GrapheneOS if you install it and grant it all the permissions it wants. But it'd be very difficult to inject malware into your device or affect your other apps/data without your permission. Actually, GrapheneOS doesn't even have Google Play Protect preinstalled, so even if you try to install known malware and grant it permissions, there would be nothing to stop you. (Although, GrapheneOS adds more granular permissions, such as Storage Scopes, so ransomware for example can be much more limited on GrapheneOS if you choose. And it also adds a safety measure to permission prompts: you must see the permission request on your screen for at least one full second before you're able to accept the permission request, so an app tricking you into tapping the place where the allow button would show up just a moment before it does won't be able to do this on GrapheneOS.)

de0u

DynamicGlow If AOSP has a lot of these security features, how come malware is so prevalent on android?

One reason is that lots of devices are not up to date with security fixes. In some cases that is because device vendors are slow to release system updates, but it is also the case that users don't always update when an update is available. Some users continue using devices after vendors have stopped issuing updates.

DynamicGlow

Watermelon thanks for the explanation!