<br><br><div class="gmail_quote">On Mon, Jan 16, 2012 at 13:45, Greg Freemyer <span dir="ltr"><<a href="mailto:greg.freemyer@gmail.com">greg.freemyer@gmail.com</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 Thu, Jan 12, 2012 at 12:00 PM, Jonathan Neuschäfer<br>
<<a href="mailto:j.neuschaefer@gmx.net">j.neuschaefer@gmx.net</a>> wrote:<br>
> 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>
> 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>
<br>
</div>Boot CDs mean physical access. If the bad guy has physical access, all is lost.<br>
<br>
=== specifically<br>
If you want to defend against reboots to a boot CD, then all of memory<br>
is potential leak.<br>
<br>
<a href="http://citp.princeton.edu/research/memory/" target="_blank">http://citp.princeton.edu/research/memory/</a><br>
<br>
My personal favorite is when they actually move the RAM chips from one<br>
PC to another to get the data out of it.<br>
<br>
After removing power, they immediately spray freon (or something<br>
similarly cold) on the RAM chips to stabilize them, then move them to<br>
another PC and recover the content.<br>
<br>
I can't get the video to work right now, but here's a walk-thru with photos.<br>
<br>
I quote:<br>
===<br>
We stored data in these memory modules, then cooled them, removed them<br>
from the computer, and placed them in a container of liquid nitrogen<br>
for an hour. After returning them to the computer, we found<br>
practically no information had been lost. (Using liquid nitrogen would<br>
be overkill for most attacks, since cheap, widely-available duster<br>
spray would adequately cool the chips.)<br>
===<br>
<span class="HOEnZb"><font color="#888888"><br>
Greg<br>
</font></span></blockquote></div><div><br></div>I should clarify (because someone asked), the memory that I was talking about wouldn't be allocatable until after the process that read it and freed it exited.<br><br clear="all">
<div><br></div>-- <br>Peace and Blessings,<br>-Scott.<br><br>