Everhart,Glenn From: Bill Potvin, II [bpotvin@merxsoft.com] Sent: Saturday, March 21, 1998 12:57 AM To: 'Kevin Houston' Cc: ntsecurity@iss.net Subject: RE: [NTSEC] NTFS alternate data streams [LONG] TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net Contact ntsecurity-owner@iss.net for help with any problems! --------------------------------------------------------------------------- Ntfs "Multiple Data Streams" On the Nt File System, a file is represented by a fixed-length record in the Master File Table, or Mft. Each record in the Mft contains a number of sections that describe "attributes" associated with the record. There are different attributes including "Standard Information", "File Name", "Symbolic Link", "Volume Name", and "Data" attributes. (This is clearly not an exhaustive list; there are at least 14 different attributes that I'm aware of). Attributes can be either "Resident" or "Nonresident", which describes the location of the attribute in relation to the Mft record itself. As one might assume, Resident attributes are those which live directly within the given Mft record, while Nonresident attributes live elsewhere on the physical volume. When an attribute is Nonresident, the Mft record contains information pointing to the location of the attribute. The attribute relevant to this discussion is the "Data" attribute. The Data attribute typically contains information pointing to the actual data comprising the file. As with the other attributes, the Data attribute can be either Resident or Nonresident. The term "Alternate Data Stream", or more appropriately, "Multiple Data Stream", refers to the fact that a given Mft record can have more than one Data attribute. In order to more clearly illustrate the concept, I've included both a raw dump of an Mft record containing two Data attributes, as well as a selective format of that record. ["selective" means that I'm only showing those values I'm reasonably sure of...:-}] The Data attributes were created using Notepad and are both very small in order to keep the attributes Resident in the record. You can see the data clearly in the dump: [Of course, this dump section should be viewed with a monospaced font] FILE RECORD [15635] RAW DUMP [464] BYTES: 0012eef4 (00000000) 454c4946 0003002a c6c134a5 00000000 | FILE*....4...... | 0012ef04 (00000010) 00010025 00010030 000001d0 00000400 | %...0........... | 0012ef14 (00000020) 00000000 00000000 00870005 00000000 | ................ | 0012ef24 (00000030) 00000010 00000048 00000000 00000000 | ....H........... | 0012ef34 (00000040) 00000030 00000018 6a13ac80 01bd51b9 | 0..........j.Q.. | 0012ef44 (00000050) 41076750 01bd5478 41076750 01bd5478 | Pg.AxT..Pg.AxT.. | 0012ef54 (00000060) 41076750 01bd5478 00000020 00000000 | Pg.AxT.. ....... | 0012ef64 (00000070) 00000000 00000000 00000030 00000070 | ........0...p... | 0012ef74 (00000080) 00000000 00030000 00000058 00010018 | ........X....... | 0012ef84 (00000090) 00000005 00050000 6a13ac80 01bd51b9 | ...........j.Q.. | 0012ef94 (000000a0) 6a13ac80 01bd51b9 6a13ac80 01bd51b9 | ...j.Q.....j.Q.. | 0012efa4 (000000b0) 6a13ac80 01bd51b9 00000000 00000000 | ...j.Q.......... | 0012efb4 (000000c0) 00000000 00000000 00000020 00000000 | ........ ....... | 0012efc4 (000000d0) 0076030b 00730069 00620069 0065006c | ..v.i.s.i.b.l.e. | 0012efd4 (000000e0) 0074002e 00740078 00000050 00000078 | ..t.x.t.P...x... | 0012efe4 (000000f0) 00000000 00040000 0000005c 00000018 | ........\....... | 0012eff4 (00000100) 80040001 00000030 00000040 00000000 | ....0...@....... | 0012f004 (00000110) 00000014 001c0002 00000001 00140000 | ................ | 0012f014 (00000120) 001f01ff 00000101 01000000 00000000 | ................ | 0012f024 (00000130) 00000201 05000000 00000020 00000220 | ........ ... ... | 0012f034 (00000140) 00000501 05000000 00000015 79184de3 | .............M.y | 0012f044 (00000150) 51206016 156a5a7f 00000201 00000000 | .` Q.Zj......... | 0012f054 (00000160) 00000080 00000028 00000000 00010000 | ....(........... | 0012f064 (00000170) 00000010 00000018 2c7a6142 72614220 | ........Baz, Bar | 0012f074 (00000180) 6f46202c 0a0d2e6f 00000080 00000040 | , Foo.......@... | 0012f084 (00000190) 00180a00 00020000 00000010 00000030 | ............0... | 0012f094 (000001a0) 00690068 00640064 006e0065 0074002e | h.i.d.d.e.n...t. | 0012f0a4 (000001b0) 00740078 00000000 2c6f6f46 72614220 | x.t.....Foo, Bar | 0012f0b4 (000001c0) 6142202c 0a0d2e7a ffffffff 00000000 | , Baz........... | FILE RECORD [15635] SELECTIVE FORMAT: FileRecordSize 464 AllocatedSize 1024 FileAttribute[0]: Type 10 ($STANDARD_INFORMATION) Length 48 NonResident 0 ValueLength 0 ValueOffset 0 Compressed 0 Id 0 RESIDENT: Length 30 Offset 18 Indexed 0 STANDARD INFORMATION PROPERTY: CreateTime 1998-03-17 10:29 LastWriteTime 1998-03-20 22:20 LastAccessTime 1998-03-20 22:20 RecordLastWrite 1998-03-20 22:20 Attributes 20 (.....a.....) FileAttribute[1]: Type 30 ($FILE_NAME) Length 70 NonResident 0 ValueLength 0 ValueOffset 0 Compressed 0 Id 3 RESIDENT: Length 58 Offset 18 Indexed 1 FILE NAME PROPERTY: ContainerRecord 5 SequenceNumber 5 CreateTime 1998-03-17 10:29 LastWriteTime 1998-03-17 10:29 LastAccessTime 1998-03-17 10:29 RecordLastWrite 1998-03-17 10:29 AllocSize 0 RealSize 0 Flags 20 (.....a.....) NameLength 11 NameType 3 (Unicode/Dos) Name visible.txt FileAttribute[2]: Type 50 ($SECURITY_DESCRIPTOR) Length 78 NonResident 0 ValueLength 0 ValueOffset 0 Compressed 0 Id 4 RESIDENT: Length 5c Offset 18 Indexed 0 SECURITY DESCRIPTOR PROPERTY DUMP: 0012eff4 (00000000) 80040001 00000030 00000040 00000000 | ....0...@....... | 0012f004 (00000010) 00000014 001c0002 00000001 00140000 | ................ | 0012f014 (00000020) 001f01ff 00000101 01000000 00000000 | ............ .... | 0012f024 (00000030) 00000201 05000000 00000020 00000220 | ........ ... ... | 0012f034 (00000040) 00000501 05000000 00000015 79184de3 | .............M.y | 0012f044 (00000050) 51206016 156a5a7f 00000201 3f3f3f3f | .` Q.Zj.....???? | FileAttribute[3]: Type 80 ($DATA) Length 28 NonResident 0 ValueLength 0 ValueOffset 0 Compressed 0 Id 1 RESIDENT: Length 10 Offset 18 Indexed 0 PROPERTY DUMP: 0012f06c (00000000) 2c7a6142 72614220 6f46202c 0a0d2e6f | Baz, Bar, Foo... | FileAttribute[4]: Type 80 ($DATA) Length 40 NonResident 0 ValueLength a ValueOffset 18 Compressed 0 Id 2 ValueName hidden.txt:$DATA [Resident] RESIDENT: Length 10 Offset 30 Indexed 0 PROPERTY DUMP: 0012f0ac (00000000) 2c6f6f46 72614220 6142202c 0a0d2e7a | Foo, Bar, Baz... | 4406 milliseconds elapsed time. The most obvious difference between the "primary" data attribute and the second is the presence of additional, prepended information in the form of a "name" in the second Data attribute. Looking at attribute number 3, you can see that the ValueLength and ValueOffset values are both Zero. However, these same values for attribute number 4 are x'A' and x'18', respectively. In addition, you'll note that the Resident Offset value is bumped to x'30' as opposed to x'18', as is the case for all of the other records, which clearly accomodates the name value. You may note that in the formatted display, I'm displaying the second Data stream name as "hidden.txt:$DATA". This appears to be an Ntfs convention as this is the name returned by other native Apis. This is interesting because it implies that there can exist multiple streams relative to attributes other than the Data attribute. Also, Multiple Data Streams are mentioned in the Windows NT Version 3.5 Resource Guide, Volume 1, Page 169. As has been previously noted, the documentation is nothing more than a brief description. However, the notion that there has never been any way to view these multiple streams is not exactly correct: the "dir" command that is included in my "rxsh" command interpreter for NT has had a "-m" switch, which causes the multiple streams to be displayed in a dir listing, since 1995. [Please excuse the "plug"]: rxsh ++D:\>dir Volume in drive D is MERU-971029 (NTFS) Volume Serial number is dc7f-91db Directory of D:\ ....ac. [DIR] 1998-03-07 22:47 Dev ....a.. [DIR] 1998-03-20 20:23 NT40 ....ac. [DIR] 1998-03-06 21:27 Program Files ....ac. [DIR] 1998-03-20 17:56 Temp ....ac. [DIR] 1998-02-14 07:34 Users ....ac. [DIR] 1998-03-20 23:27 Work ....a.. 16 1998-03-20 22:20 visible.txt ....a.m 16 1998-03-20 22:20 visible.txt:hidden.txt 8 File(s) 32 bytes 147,417,088 bytes free In conclusion, what about security? The limited testing I've done here indicates that the permissions associated with the Mft record, i.e. in the "Security Descriptor" attribute, are applied to any multiple data streams that exist on the record. In example, if a user is able to create a file, then that user will be able to create an additional data attribute on that file. On the other hand, if a user cannot update an existing file, then that user is not able to add an additional data attribute on that file. Create Create Acl File Mds ------------------------------------ Everyone:Read N N Everyone:Change Y Y Everyone:FullControl Y Y Note that "Create" means both create and update. So, it appears that Multiple Data Streams do not pose any additional security threat beyond that embodied in "normal" files. But what of the notion forwarded of creating a "hidden web site" living inside Multiple Data Streams? I believe that the issue here is the manner in which the files are loaded to the Web site. Testing I've done with FrontPage indicates that it does NOT deal with Mds's at all. It is also not very likely there's an Ftp client out there that deals with Mds's either. For example, the standard Ftp client that ships with NT silently fails if you do something like: "put visible.txt:hidden.txt", as well as with other combinations of source and destination names. [It's possible, but IMO unlikely, that the WinInet functions might deal with Mds's; it would have to be tested]. So, it appears that the only likely scenario that would result in the retention of the Mds's is a direct copy of the files from the local Ntfs volume onto the Web servers Ntfs volume via a Netbios session. And I'm not too sure how likely that would be. BTW, Mds's are only relevant to Ntfs. If a file containing Mds's is copied to any other file system, the Mds's are NOT carried along. This means, of course, that copying such a file to a floppy disk will not retain the Mds's, (unless you've been able to format the floppy with Ntfs). Bill Potvin, II mersoft mailto:bpotvin@merxsoft.com http://www.merxsoft.com -----Original Message----- From: Kevin Houston [SMTP:khouston@onel.com] Sent: Friday, March 20, 1998 17:49 To: ntsecurity@iss.net Subject: Re: [NTSEC] NTFS alternate data streams TO UNSUBSCRIBE: email "unsubscribe ntsecurity" to majordomo@iss.net Contact ntsecurity-owner@iss.net for help with any problems! --------------------------------------------------------------------------- Pardon the uninformed question, But what _IS_ an "alternate data stream" what is it's purpose etc. If I hide 5 megs worth of data in a 1 Meg text file, can I copy the 1 Meg to a floppy? Will I then be able to carry the floppy to another computer and then extract the 5megs of data? this does not seem right at all. is stream just another way of doing a shortcut?????? I am very confused.