This is far from being a simple task thanks to memory protection techniques.
In the old times of MS-DOS, Windows 9x and equivalent home computing systems, the memory was indeed equally shared amongst all the running process. In such conditions your feeling is right: any user process can access and modify memory from other processes, even the operating system kernel has no mean to fully shield itself.
But this is old story now. As an inheritance from mainframe computers (big bulky fridge-looking units used for highly sensitive and parallel tasks), home computers OS and processor architectures received real memory protection techniques.
At the basis of this technique there is a map allowing to match a memory segment with its owning process. Thanks to this, a process is not allowed anymore to access anything outside of its own memory. If a process attempts to break this rule (most often as the result of a bug) the operating system mercilessly kills it (this is dreaded segmentation fault, or "segfault" for the intimates).
Does this means that the threat you are describing can never happen anymore? In security, never say "never": every system as secure as it may seem has its flaw:
- The whole thing is controlled by the operating system kernel, so a flaw in the kernel may lead to bypass this security and obtain access to whole memory like in the good old days. An example on Linux could be the ptrace system call, designed to allow to trace (debug) a process. Vulnerabilities are found from time to time allowing an unprivileged process to abuse this function into getting such ability.
- On the other side of the chain, you may also want to bypass the operating system completely and directly attack the physical RAM storage. The most well known attack in this category is the Row Hammer: it has been found that on a lot of RAM modules the fact of quickly and repeatedly changing the value stored at a location may, due to some electronic weakness, affect and possibly change a value stored at a nearby location.