|
|
|
|
|
by fabulist
4445 days ago
|
|
To clarify what thrownaway2424 said, in case some people really are unfamiliar; You can't take the password out of RAM. It would be pretty insane to store it in RAM once the login process is done. This exploit can't read RAM. Being able to read RAM from a program other than the one you are exploiting is pretty unusual today (early operating systems were much less scrupulous, however). There are lots of scary local exploits that can do this by abusing the high level of privileges granted to drivers for things like HDMI devices, but I've never heard of a remote exploit that could read arbitrary RAM. You can sometimes convince a program to dump core if you have a DoS and can run ulimit. We used to store passwords in /etc/passwd. The user database need to be public. So the passwords stored in it were hashed, and thus were thought to be secure. Along came the Morris worm, which used (among other things) MD4 password cracking to infect systems. I imagine there were less high-profile incidents as well, but the long and the short if it is we how use /etc/shadow for secrets, and /etc/passwd for usernames. While not secret, I'd certainly call /etc/shadow sensitive, but its a small point. |
|