retsl

A lot of phone manufacturers "save on memory" and use the same memory chips for the baseband processor and the central cpu. Which means that it's a little bit cheaper ... and the baseband has access to all the phone memory and all peripherals connected through the memory bus (which is all of them in any recent phone).

This can be mitigated e.g. via an IOMMU: https://grapheneos.org/faq#baseband-isolation

It may even be the case that these chips are integrated in the cpu (which I believe is the case for recent Apple chips).

I don't know whether it's true or not that they use the same RAM chips. But either way it doesn't change the fact that they can still be properly segregated via the IOMMU.

[...] The baseband implements other functionality such as Wi-Fi and GPS functionality [...] https://grapheneos.org/faq

It doesn't need to ask the OS, it can just get the coordinates and send them off.

This is true but there's automatic restart which will automatically restart the phone to get it back into BFU state:

Automatic Restart is a security mechanism in iOS 18.1 iPadOS 18.1 and or later that leverages the Secure Enclave to monitor device unlock events. If a device remains locked for a prolonged period, it automatically restarts, transitioning from an After First Unlock state to a Before First Unlock state. During the restart, the device purges sensitive security keys and transient data from memory.

https://help.apple.com/pdf/security/en_US/apple-platform-sec...

[...] inactivity reboot triggers exactly after 3 days (72 hours). [...]

https://naehrdine.blogspot.com/2024/11/reverse-engineering-i...

GrapheneOS also has this (https://grapheneos.org/features#auto-reboot) with a default of 18 hours.

Maybe one could try to force restart (https://support.apple.com/en-gb/guide/iphone/iph8903c3ee6/io...) to quickly get to BFU. But I could imagine that it'd be hard to remember and then execute the right steps in a stressful situation.

Yes, afaik macOS apps could theoretically be sandboxed as well (or close to) as iOS apps are. You can find the policies for many first-party apps and deamons in /System/Library/Sandbox/Profiles. But in practice most third-party apps aren't.

https://bdash.net.nz/posts/tcc-and-the-platform-sandbox-poli... and https://bdash.net.nz/posts/sandboxing-on-macos/ are good introductory articles.

Not without approval, see https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_A... or https://web.dev/articles/async-clipboard#security_and_permis.... But that is not relevant here.

Instead of the .torrent files, the compromised website served a .zip file, which contained a .exe. When opened, it shows a GUI to select a Xubuntu version and a button to generate the link. When that button was clicked, the malware showed a download link to the user and, in the background, deployed a second stage to %APPDATA%\osn10963\elzvcf.exe and executed it.

The second stage monitors the clipboard for cryptocurrency addresses which it will replace with attacker-controlled ones. The second stage is also added to HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ to ensure it is run whenever the user logs in.

Both stages have some limited anti-debugging and anti-VM functionality.

the malware's main function seems to be to check the clipboard for crypto wallet addresses and then replace them with attacker addresses:

  Bitcoin (bc1): bc1qrzh7d0yy8c3arqxc23twkjujxxaxcm08uqh60v
  Litecoin (ltc1/L/M): LQ4B4aJqUH92BgtDseWxiCRn45Q8eHzTkH
  Ethereum (0x): 0x10A8B2e2790879FFCdE514DdE615b4732312252D
  Dogecoin (D): DQzrwvUJTXBxAbYiynzACLntrY4i9mMs7D
  Tron (T): TW93HYbyptRYsXj1rkHWyVUpps2anK12hg
  Ripple (r): r9vQFVwRxSkpFavwA9HefPFkWaWBQxy4pU
  Cardano (addr1): addr1q9atfml5cew4hx0z09xu7mj7fazv445z4xyr5gtqh6c9p4r6knhlf3jatwv7y72deah9un6yettg92vg8gskp04s2r2qren6tw

the virustotal report shows the output from detectiteasy in "Details" -> "Basic properties": DetectItEasy PE64 Compiler: Microsoft Visual C/C++ (19.14.26715) [C++] Linker: Microsoft Linker (14.00.24241) Tool: Visual Studio (2015)

this is not meant to imply anything about whether the binary is malicious or not.

Containers on MacOS are ran inside a Linux VM. If you ensure that the Linux VM doesn't have access to anything besides the required files/networks, that should be pretty secure.

Best case you go through the settings of Docker, Podman or whatever you use to limit integrations. Then, from within the VM and container see what networks, files, etc. you can reach to be sure.

There's a feature request from 2018 to add a proper permission model for plugins in VSCode: https://github.com/microsoft/vscode/issues/52116

Sadly it doesn't seem to make any progress.

"For VS Code remote, the VS Code server is in the same trust boundary as the VS Code client. [...]

For Remote SSH: [...] A compromised remote could use the VS Code Remote connection to execute code on your local machine."

https://github.com/microsoft/vscode-remote-release/issues/66...

I wrote about it in a bit more detail a month ago because it seems to be a common misunderstanding: "VS Code Remote Dev and Dev Containers are not security boundaries" https://lets.re/blog/vscode-remote-dev/

I set up Qubes OS for and with technical, less-technical and non-technical people and I very much disagree. It only works well for those who are prepared and motivated to learn, and even then, it sometimes can be frustrating.

The copy-pasting between VMs, mentioned in a sibling, requires four steps: (1) copying to the source VM's clipboard, (2) copying to the global clipboard, (3) copying to the destination VM's clipboard, and (4) pasting to the destination. The shortcuts become part of your muscle memory after some use, but until they are, that is just one way in which Qubes gets in the way of productivity.

There are a bunch of minor quirks, often specific to the hardware, which the user needs to learn about and find workarounds for. But if they do, Qubes is probably the most seamless way to work with tons of (well-isolated) VMs. For example, SecureDrop [0] is based on Qubes and does seem to work well for journalists for securely receiving and working with documents from anonymous sources.

[0] https://securedrop.org/