<br><br><div class="gmail_quote">On Thu, Jan 12, 2012 at 12:00, Jonathan Neuschäfer <span dir="ltr"><<a href="mailto:j.neuschaefer@gmx.net">j.neuschaefer@gmx.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Jan 11, 2012 at 12:52:33PM -0500, Scott Lovenberg wrote:<br>
> Real world example in C; I fixed a security bug in Samba that dealt with<br>
> this exact problem. Credential files were read to memory as the root user<br>
> and then the memory was freed without being zeroed. A user could therefore<br>
> read the contents of a file that they didn't have permission to read<br>
> because the whole thing was put in memory by a user that had permission to<br>
> view the file. Someone clever could churn through memory and find the<br>
> credentials if they knew that the mount command was just run.<br>
><br>
> I added a memset() to the end of the parsing function to zero out the<br>
> memory before freeing back to the OS.<br>
<br>
</div>Could you please clarify how this "churning through memory" would work?<br>
<br>
Of course someone could find another security bug and access heap space,<br>
but that requires said other bug. Debuggers are also irrelevant to this,<br>
because you need certain parmissions to run a program through a<br>
debugger, and if you do that, you might also set a breakpoint in the<br>
function and catch the credentials when it's run.<br>
<br>
Swap disk are a real issue under some circumstances, though.<br>
A page containing sensitive data may be swapped out and not be over-<br>
written before an attacker can boot from an external medium (CD etc.)<br>
and peek through the swap disk.<br>
If you don't suspend (which means writing all pages to persistent<br>
storage), mlock() would be the solution here (CMIIW). (Which doesn't<br>
mean zeroing isn't also a good idea)<br>
<br>
Of course, people should also encrypt their disks on this kind of server.<br>
<br>
Thanks,<br>
<span class="HOEnZb"><font color="#888888"> Jonathan Neuschäfer<br>
</font></span></blockquote></div><div><br></div>Sorry for taking so long to reply. <div><br></div><div>Let me walk you guys through how this bug could be exploited.<div>The file that you want to access is blocked from you by file system permissions. The root user (uid==0) can access this file (that contains credentials) and read it into memory that it has malloc()'ed. After the process running as root is done, it free()'s the memory without zeroing it out. Now you (you clever hacker) spawn a process that requests memory in large hunks. It then searches for the string "password=" in that memory. Since the memory was free()'ed back to the pool without being changed, it still contains the original information that was in the file that you cannot read. Does this make sense, or should I go into t a bit more detail?<br>
<br clear="all"><div><br></div>-- <br>Peace and Blessings,<br>-Scott.<br><br>
</div></div>