Google reveals “high severity” flaw in MacOS kernel

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.

I don't think it's that hard: it's basically equivalent to finding the value of a variable in a coredump, which is a thing I've done a lot and which debuggers explicitly help you with, even if it's a release build without debug symbols. One way to do it is to inject a controlled password into the same build of the program on your own machine, dump its memory, search for the password, and then reverse ASLR if needed (which is easy if you have full memory read/write access; the point of ASLR is to make limited-access vulnerabilities like small stack overflows hard to exploit, but sort of by definition the information about where libraries are is located somewhere in the process so that the process itself can run). You can then script doing the same thing once per current-ish release build per current-ish OS, and get a robust automated attack.

In general I think people overestimate the difficulty of doing clever things with process memory (one of my favorites here is the "Vudo" exploit from 2001 http://phrack.org/issues/57/8.html in which sudo could be tricked into temporarily writing a 0 byte one past the end of a buffer and then restoring the original byte, and it's still exploitable to get root). If you haven't done it yourself, it sounds harder than it is, and betting that it's hard because it sounds complicated when there's no actual isolation boundary is more-or-less security by obscurity.

The same thing applies to triggering keychain prompts: use a side channel (e.g., polling the stack of a legitimate process) to figure out when the user is likely to need a keychain unlock, then trigger a keychain unlock for your app at the same time. (Note that you can either pop up a dialog on your own or actually request keychain access for your own process.) You also might not even need to time it: just rely on the fact that the vast majority of users are going to respond to security prompts in a way that appears to unblock their jobs, without evaluating whether the prompt is reasonable. See studies on click-through rates of cert warnings before they got hard to click through, the continued effectiveness of phishing / spear-phishing, etc. If you pop up a dialog saying "Java Updater needs your password," I bet you'll get a ton of people who don't even have Java installed type in their password.