Maybe I missed something, but why is this a vulnerability? This behavior is directly caused by NTFS. The way information is stored in the MFT and in a INDEX_ALLOCATION (for large directories) will cause this problem to any secure delete program. IIRC, if your file is located in a large directory, the records (mainly the FILENAME attribute) for this directory are not hold in a resident attribute (INDEX_ROOT - 0x90) in the MFT, they are hold in a non-resident attribute (INDEX_ALLOCATION - 0xA0) somewhere on some cluster(s) on the disk. Those records are organized into B-trees. Meaning that any modification to a filename will result in a rebalancing of the B-Tree. This can leave the original filename (complete or partial) in between records in the index on the disk because INDEX can have free spaces in them. Even SDelete from System Internal can't handle this (taken from Microsoft[1]) : *The reason that SDelete does not securely delete file names when cleaning disk free space is that deleting them would require direct manipulation of directory structures. Directory structures can have free space containing deleted file names, but the free directory space is not available for allocation to other files. Hence, SDelete has no way of allocating this free space so that it can securely overwrite it.* Am I wrong? [1] http://ift.tt/1aacCO0 On Mon, May 18, 2015 at 3:35 PM, KoreLogic Disclosures <
disclosures@korelogic.com> wrote: >
Source: Gmail -> IFTTT-> Blogger
No comments:
Post a Comment