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 ;)
-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
