From: j.neuschaefer@gmx.net (Jonathan Neuschäfer)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Does Linux process exist information leakage?
Date: Thu, 12 Jan 2012 18:00:22 +0100 [thread overview]
Message-ID: <20120112170022.GA1513@debian.debian> (raw)
In-Reply-To: <CAFB9KM0-zuer0_dbQmjjvVmaCSYcjUaxVhmQrfn3dk8qif=gsg@mail.gmail.com>
On Wed, Jan 11, 2012 at 12:52:33PM -0500, Scott Lovenberg wrote:
> Real world example in C; I fixed a security bug in Samba that dealt with
> this exact problem. Credential files were read to memory as the root user
> and then the memory was freed without being zeroed. A user could therefore
> read the contents of a file that they didn't have permission to read
> because the whole thing was put in memory by a user that had permission to
> view the file. Someone clever could churn through memory and find the
> credentials if they knew that the mount command was just run.
>
> I added a memset() to the end of the parsing function to zero out the
> memory before freeing back to the OS.
Could you please clarify how this "churning through memory" would work?
Of course someone could find another security bug and access heap space,
but that requires said other bug. Debuggers are also irrelevant to this,
because you need certain parmissions to run a program through a
debugger, and if you do that, you might also set a breakpoint in the
function and catch the credentials when it's run.
Swap disk are a real issue under some circumstances, though.
A page containing sensitive data may be swapped out and not be over-
written before an attacker can boot from an external medium (CD etc.)
and peek through the swap disk.
If you don't suspend (which means writing all pages to persistent
storage), mlock() would be the solution here (CMIIW). (Which doesn't
mean zeroing isn't also a good idea)
Of course, people should also encrypt their disks on this kind of server.
Thanks,
Jonathan Neusch?fer
next prev parent reply other threads:[~2012-01-12 17:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 12:53 Does Linux process exist information leakage? 夏业添
2012-01-11 16:23 ` Jonathan Neuschäfer
2012-01-11 16:45 ` Dave Hylands
2012-01-11 17:52 ` Scott Lovenberg
2012-01-12 2:14 ` 夏业添
2012-01-12 17:00 ` Jonathan Neuschäfer [this message]
2012-01-16 18:19 ` Scott Lovenberg
2012-01-16 23:45 ` Jonathan Neuschäfer
2012-01-19 14:47 ` Scott Lovenberg
2012-01-16 18:45 ` Greg Freemyer
2012-01-16 20:44 ` Scott Lovenberg
2012-01-12 2:05 ` 夏业添
2012-01-11 18:44 ` Greg Freemyer
2012-01-19 20:23 ` Rik van Riel
[not found] ` <CAOfVmNFuBCjWb7-5rJaU7ksgcU8LyAW15JiEwa2PigZL3zC0aw@mail.gmail.com>
2012-01-12 2:30 ` 夏业添
2012-01-18 1:53 ` Fredrick
[not found] ` <CAOfVmNFN-GLDwkfLKG11iw7-p6KerDmyoMxV1oSD5WSYJMXc0g@mail.gmail.com>
2012-01-18 11:43 ` beyond.hack
2012-01-19 1:27 ` 夏业添
2012-01-19 7:12 ` SaNtosh kuLkarni
2012-01-19 8:37 ` SaNtosh kuLkarni
2012-01-20 6:52 ` Fredrick
2012-01-19 14:48 ` Scott Lovenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120112170022.GA1513@debian.debian \
--to=j.neuschaefer@gmx.net \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).