After a certain time frame of inactivity on lock screen, we reload the application processes to make sure that any leftover managed memory addresses are also purged.
The documentation talks about purging the memory at:
Bitwarden Security Whitepaper | Bitwarden Help Center
and says also something about the garbage collector…
I am not very practical with how memory is managed by the linux kernel, but I understood that every user space process can access only his portion of memory, and only kernel space driver and processes can read all the memory. If it is the case, why Bitwarden take the effort of purging his memory so frequently? And if the untrusted reader of the memory is the kernel itself, how can Bitwarden protect itself?
Bitwarden clients are platform-independent, and written in large part in JavaScript. When they run in a Windows environment, any process running in the User context has access to all process memory. Some operating systems (ChromeOS perhaps?) do a better job of protecting process memory from other processes, but there is basically a single code base that runs on all operating systems (Linux, macOS, Windows, etc.).
2 Likes
On linux, and Windows (and probably mac?) process can read other processes running under the same user, f.e by reading /proc/$pid/mem on linux. No root required. Especially in a typescript/electron app this requires significant engineering to prevent (a native rust module that stores keys using the kernels keyctl f.e would work, but then the typescript UI bits might keep the strings around until garbage collected…). I.e any other unsandboxed process could dump your Bitwarden vault’s credentials while it is running and unlocked.
Btw, since you mention Linux, on Linux, the “reload application processes to make sure that any leftover managed memory addresses are also purged” behaviour is currently disabled: clients/apps/desktop/src/main/window.main.ts at 6355a1964b52d55ef36071810138f5d28877b14f · bitwarden/clients · GitHub
And if the untrusted reader of the memory is the kernel itself, how can Bitwarden protect itself?
This would not be possible to protect against for any app, but is also not the threat model.
2 Likes
Flatpaks/Snaps on linux, Windows Store apps, and mac store apps all have sandboxing that prevents this. As long as you exclusively use these, that should be the same as chromeos/android/ios.
1 Like
Does this apply to browser extensions? And weren’t we saying the same thing? (You: “process can read other processes running under the same user”; Me: “process running in the User context has access to all process memory”)
Yes, I wasn’t disagreeing with you, I posted just seconds after you so I hadn’t seen the post yet.
The later flatpak/snap/windows store comment is referring to your comment on chromeos. You can have the same protection if you use sandboxed apps on other desktop operating systems. It’s just not the default distribution method on most systems.
About browser extensions: Sure, this applies. I’m not aware whether the process is crashed / can be crashed though in the extension context, so the same “vulnerability” (I’m not sure whether I would classify it as one) of dumping credentials after locking might apply.
The real vulnerability would be a memory dump while the vault was unlocked. I’m not familiar with the sandboxing technology you describe, but shouldn’t this block memory access both for the locked and unlocked state of the vault? And if so, how would one go about getting a sandboxed version of say, the Chrome extension for Windows?
Dumping is (Linux)/was(mac/windows) possible whether the vault is unlocked or locked. The memory-dumping when “locked” was the whole reason to introduce the forced crashing of the desktop process in the first place. It’s an ugly workaround for the fact that javascript’s engines (v8 in electron) keep memory around until garbage collected. I.e even after you lock, there are several copies of your master password (from the UI) and encryption key, and decrypted ciphers still in memory.
I’m not familiar with the sandboxing technology you describe, but shouldn’t this block memory access both for the locked and unlocked state of the vault?
Yes, but only from other sandboxed apps. If you install an unsandbocked program, this can dump even the sandboxed ones running on the same system.
And if so, how would one go about getting a sandboxed version of say, the Chrome extension for Windows?
You cannot just sandbox extensions. On linux, firefox and chrome are available as flatpak. But what you actually want is to sandbox all other applications so that they can’t memory-dump chrome (no matter whether chrome is in a sandbox or not).
But, ultimately, the point is mostly that these are just hardening-steps, the best approach is to do your best to never get malware on your system that dumps memory (or captures screen/keyboard inputs).
1 Like
You and @grb have been very clear and kind, thank you. I wanted to ask to you some references (mybe it is a bit off topic) on why It exists the possibility of writing and reading from /proc/$pid/mem. I mean if I want to communicate with some process I would think to implement some Named Pipe of FIFO not to write on memory of another process without his consent… I searched a bit online but I didn’t found a clear explanation. If you have some references I can try to read them
I have not worked much with it myself, but as far as I read:
With /proc/$pid/maps you can see what’s mapped where in the process, with /proc/$pid/mem you can read/write to it, but the offset in the file is the same as the memory address (that you can also get from /proc/$pid/maps, or a debugger like gdb). I.e if you know the address of some memory you want to write to, you just open the file and write at that offset.
There are tools that wrap this, f.e scanmem if you just want to dump memory.
I mean if I want to communicate with some process I would think to implement some Named Pipe of FIFO not to write on memory of another process without his consent…
Yes, this is the proper way to do it. You can also properly have shared mapped memory between processes (https://linux.die.net/man/2/shmat), but for implementing IPC you should not use /proc/pid/mem.
Hmmmm… perhaps it would be OK, if one only gets sandboxed malware? 
If you only install sandboxed apps, your malware will also just be in sandboxes. For most desktop users, this setup is perfectly viable.
That’s why iOS and Android has much less effective malware. (Ok, granted zero-days that escape the sandbox, and even get to the kernel do happen, but are much harder to pull off than getting someone accidentally downloading the wrong .exe file on Windows or using a Word-macro).
So, in my case, believe my main risk of acquiring malware is from some malicious link that is included in Google search results. Does that mean I can eliminate (or greatly reduce) this risk by getting a sandboxed browser from the Microsoft Store? Seems Chrome is not available, but Brave, Firefox, Edge, and others can be found in the MS Store.