full-disclosure - Re: [VulnWatch] Microsoft Windows NTFS Information Disclosure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <200506302117.j5ULH73w027962@unix6.uvic.ca>
Date: Fri Jul  1 03:03:03 2005
From: klassen at uvic.ca (Melvin Klassen)
Subject: Re: [VulnWatch] Microsoft Windows NTFS
	Information Disclosure

mattmurphy@...rr.com (Matthew Murphy) at Jun 30, 2005 12:01:59 PM wrote:

> However, an apparent error in the NTFS driver's code causes the file 
> system to incorrectly assign disk blocks to files before they have been 
> initialized.  Following a recovery from a system shutdown, uninitialized 
> data may be visible in files from previously allocated disk blocks.

As far as I know, _every_ major Operating System has the same vulnerability.

I do _NOT_ know of any Operating System that "zero's" each newly-allocated
block/sector/track/cylinder of disk-space when allocating a "new" file,
whether on disk, or on magnetic tape, or on removable media.

  IBM AIX?    No.
  IBM z/VM?   No.
  IBM z/OS?   No.
  IBM OS/2?   No.
  HP/UX?      No.
  Linux?      No.
  MS DOS?     No.
  MS Windows? No.

The "cost" (in elapsed time, due to I/O waits) 
would be an unacceptable performance-penalty.

The "benefit" would be that one would never need to 'FORMAT' a 3.5" disk;
the O.S. would do it for you, the first time that you tried to write to it.

I would hate to work with an O.S. that would automatically "write" 
on a magnetic tape to completely fill the tape, _before_ allowing 
"backup" software to rewrite useful information onto a tape.  
Backups would take _double_ the elapsed-time to complete ?!?!
Unacceptable.

P.S.

If you're looking for a "vulnerability", consider how a logical record 
is updated within a file-system.  Typically, an "update-in-place" mechanism
is not used.  Instead, when a logical record is to be updated,
the physical block containing that logical record is read from the disk,
the logical record is updated in a buffer, and the file-system finds an
"unused" physical block on the disk, and copies from the buffer to that 
new block.  If there is a "pointer-block" that points to all the "data" blocks
in the file, then that pointer-block is read from the disk, updated in the
buffer, and, like the updated "data" logical record, written to an "unused"
block on the disk.  If there is a "file-directory" structure on the disk,
an update occurs to that structure, and the updated part of that file-directory
is written to an "unused" block on disk.

So, updating just _one_ logical record can cause many I/O operations,
and the consumption of many of those "previously-unused" blocks on the disk.

However, note that the "dead" block(s) are not "zero'd" during the update.
Why? Because, if the operating-system crashes during these updates,
the original "file-system" structure is still present on the disk,
and the original "pointer-blocks" and "data-blocks" are still present,
i.e., after the crash, the "original" file has returned,
and the file-system in a "consistent" status,
and any of the "incomplete" updates have been "rolled-back".