Encryption Passphrase Stored Unprotected in Memory

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Open Vim Encrypted File
2.Enter Passphrase
3.Dump heap memory for VIM process
4.Extract strings from memory dump
5.Find the encryption passphrase in plain text.

What is the expected output? What do you see instead?
I would assume I wouldn't be able to see my passphrase saved in history in 
plain text.

What version of the product are you using? On what operating system?

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 12 2013 00:23:19)
Modified by pkg-vim-maintainers@lists.alioth.debian.org
Compiled by buildd@
Huge version without GUI.

Linux Mint - Trusty

Please provide any additional information below.
Demonstration:
http://blog.troseph.com/page.php?id=20150115162624

Original issue reported on code.google.com by troseph on 16 Jan 2015 at 4:14

[GoogleCodeExporter]

How exactly should Vim use a password, if it cannot keep it in memory?

I'd really love to know it if there is a concept of "protected" memory that 
could be used. Right now I've never heard of such a thing. With my current 
knowledge, I'm pretty sure you'd be able to do the same exact thing to any 
software running on your machine and using passwords.

If an attacker has the ability to inspect RAM dumps of arbitrary processes on 
your machine, then you've already lost.

Original comment by fritzoph...@gmail.com on 16 Jan 2015 at 9:37

[GoogleCodeExporter]

Is this really a problem? Usually any normal user won't be able to trace and 
dump the memory of even a process of the same user 
(https://wiki.ubuntu.com/Security/Features#ptrace and also 
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection).
 So that sounds more like a theoretical problem to me. 

Original comment by chrisbr...@googlemail.com on 16 Jan 2015 at 9:47

[GoogleCodeExporter]

There's a function, mlock(), which does exactly this.  This will prevent that 
section of memory from getting written to a core file, or from being written to 
swap.  Of course you can look at it if you have access to RAM (if you're the 
same user, or otherwise have sufficient privileges), but the point is to not 
have your sensitive data sitting around on disk.

GnuPG uses this (through pinentry).

One note is that some operating systems prevent you from calling mlock() 
without extra privileges, because otherwise you can run a DoS attack on the 
machine by locking loads of memory.  Others either just allow it, or allow up 
to a small amount, enough to keep a bunch of passwords stored.  So you'd need 
to make sure that you reverted to the unsafe behavior if mlock() failed (or 
have configuration that prevented the fallback, for the paranoid).

Original comment by danek.du...@gmail.com on 16 Jan 2015 at 11:33