4 ms·
Maybe I'm missing something, but reading something from another process' memory isn't a thing you can do, is it?
by foota 8y ago
Maybe I'm missing something, but reading something from another process' memory isn't a thing you can do, is it?
- geofft 8y agoIn general, for processes running as the same user on traditional desktop / server OSes (Windows, Mac, UNIX), it is. On mobile it's not because they had no backwards compatibility to care about (specifically, iOS applies heavy sandboxing to apps and Android runs them as different Linux user IDs). And desktop app stores are moving towards the same model. On Linux, SELinux/AppArmor/etc. might also prevent this depending on config. More fundamentally, an unsandboxed process can do things like set environment variables, update config files, modify applications installed into the user's home directory, read your browser cookies, etc. as a consequence of traditional desktop apps having unrestricted access to the user's home directory, so preventing reading memory doesn't really prevent one app from attacking another.
- foota 8y agoHuh. Thanks, I'm surprised I didn't know that.
- JoeSmithson 8y agoI don't think that's true at all, not since like Win95 days at least... Perhaps I'm also completely misinformed or misunderstanding what GP is saying but each process is meant to get it's own virtual address space
- telotortium 8y agoYes, they do get their own virtual address space, but any process running as your user can manipulate any file that user has access to (by default, without any sandboxing, which some recent apps on macOS/Linux do use, but which is not the default). Often any process running as a user can attach a debugger to any other process running as that user, which is tantamount to having complete control of that process (because a debugger can read and write memory).
- abeyer 8y agoSeparate address spaces mean that one process won't accidentally stomp on or read from other processes' memory, not that they can't if they choose to. A debugger is the canonical example of something that's sole purpose is to inspect and modify the state of another process. There are some permissions and restrictions around the ability to do this, but most desktop OS's won't stop a user from doing so to processes they own.
- geofft 8y agoYes, processes get their own address space, but there are APIs to read/write the address space of other processes, and on traditional desktop OSes, those APIs are accessible to other processes running as the same user. Virtual address spaces are for a) protection between processes running as different users and b) stability when other processes are incompetent but not malicious. Windows: https://docs.microsoft.com/en-us/windows/desktop/api/memoryapi/nf-memoryapi-readprocessmemory https://docs.microsoft.com/en-us/windows/desktop/api/memorya... macOS (Mach): https://developer.apple.com/documentation/kernel/1402405-mach_vm_read?language=objc https://developer.apple.com/documentation/kernel/1402405-mac... Linux: /proc/*/mem or http://man7.org/linux/man-pages/man2/process_vm_readv.2.html http://man7.org/linux/man-pages/man2/process_vm_readv.2.html and so forth.
- eridius 8y agoI was under the impression that on macOS you ultimately needed to get the task_t to do stuff with a target task, and that getting this for a target task was a privileged operation (unless the target task sent it to you).
- geofft 8y agoTrue - it has been getting increasingly hard on macOS (I just tried lldb on the command line and it's complaining about System Integrity Protection). It might actually be at the point where malicious software can't get access even with some cleverness?