On 28 September 2012 00:34, Josh More <[email protected]> wrote: > I do not disagree, but I am in a somewhat contrarian mood tonight. > > Might it be possible, in a ridiculously small number of circumstances, > to use the inode number to begin building a map of the disk and > thereby reduce the complexity of finding an encryption key after the > server has been stolen? (You know, for all those times when someone > breaks into a data center to steal a LAMP box ;)
Can you explain more? The other way out things we came up with over a beer was monitoring it to work out how often files were changing and maybe using it to work out if other files were being changed due to the inode changing as files were rearranged due to optimisation. Robin > -Josh More > > > > On Thu, Sep 27, 2012 at 5:10 PM, Robin Wood <[email protected]> wrote: >> On 20 September 2012 21:22, Robin Wood <[email protected]> wrote: >>> I've had both Nikto and Nessus recently report Apache ETags leaking >>> inode information for example in the Nikto output below: >>> >>> <description><![CDATA[Server leaks inodes via ETags, header found with >>> file /icons/README, inode: 491605, size: 4872, mtime: >>> 0xbd8ce4c0]]></description> >>> >>> I understand that knowing the size and access time is a bit of info >>> leakage but the stress is on the inode, can anyone explain why this is >>> so bad? What can an attacker how knows an inode value do with it? I'd >>> have thought if they had enough access to a machine to be accessing at >>> the inode level then they would have full file system access anyway. >>> >>> Robin >> >> Seeing as I've had no answers I'll answer myself... >> >> I asked a lot of people this question while at Brucon and no one >> managed to come up with a good reason why knowing the inode is a >> really bad thing. We all agree that we should avoid leaking >> information wherever possible but no one managed to come up with a >> good use for a leaked inode. >> >> If anyone wants to disagree please shout up. >> >> Robin >> _______________________________________________ >> Pauldotcom mailing list >> [email protected] >> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >> Main Web Site: http://pauldotcom.com > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com _______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
