[sleuthkit-developers] [ sleuthkit-Bugs-3523019 ] More checks on FAT "." entries

[SourceForge.net <no...@so...>]

Bugs item #3523019, was opened at 2012-05-02 06:36
Message generated for change (Comment added) made by timowpre
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&group_id=55685

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: File System Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brian Carrier (carrier)
Assigned to: Nobody/Anonymous (nobody)
Summary: More checks on FAT "." entries

Initial Comment:
Currently, TSK does special things with any "." entry it finds in the directory.  We should limit this to only the first couple of entires in the directory.  Otherwise, someone could manually change the name of a file to be "." and its content would not be accessible. 


----------------------------------------------------------------------

Comment By: Timo Warns (timowpre)
Date: 2012-12-12 04:16

Message:
The attached patch seems to fix the issue.

----------------------------------------------------------------------

Comment By: Timo Warns (timowpre)
Date: 2012-11-26 06:28

Message:
Here is a reproducer:

### create an empty image

$ dd if=/dev/zero of=empty.img bs=1M count=50
$ mkfs.vfat -F32 empty.img             


### create an image with FILE.txt

$ cp empty.img file.img
$ mount -o loop file.img /mnt/image/
$ echo "HELLO" > /mnt/image/FILE.TXT
$ umount /mnt/image/


### create an image with "." file (renamed from FILE.TXT)

$ xxd -p file.img | sed -e
's/46494c4520202020545854/2e20202020202020202020/' | xxd -r -p > dot.img


### use TSK

$ fls -V
The Sleuth Kit ver 4.0.1

$ fls -a empty.img
v/v 1612675:    $MBR
v/v 1612676:    $FAT1
v/v 1612677:    $FAT2
d/d 1612678:    $OrphanFiles

$ fls -a file.img
r/r 3:  FILE.TXT
v/v 1612675:    $MBR
v/v 1612676:    $FAT1
v/v 1612677:    $FAT2
d/d 1612678:    $OrphanFiles

$ fls -a dot.img
r/d 2:	.
v/v 1612675:	$MBR
v/v 1612676:	$FAT1
v/v 1612677:	$FAT2
d/d 1612678:	$OrphanFiles


----------------------------------------------------------------------

Comment By: Brian Carrier (carrier)
Date: 2012-11-26 06:22

Message:
Interesting. That side effect could also be because of the de-duping code
in TSK. It's strange in that report that entry 2 came up as r/d meaning
that it thought it was a file at the name level, but then mapped it to the
directory at the meta data level.


----------------------------------------------------------------------

Comment By: Timo Warns (timowpre)
Date: 2012-11-26 01:15

Message:
Note that this bug affects analyses of USB sticks that came in contact with
the Flame malware. On FAT file systems, Flame creates a file with short
name "HUB001.DAT"  and long name "." in the root directory (see
http://labs.bitdefender.com/2012/06/flame-the-story-of-leaked-data-carried-by-human-vector/).

TSK does not appropriately show such files (e.g., see
http://blog.crysys.hu/2012/06/flame-usb-dot-file-confirmed/).

If Flame writes its file to an empty USB stick, the file is the very first
entry of the root directory. Hence, a limitation of the "special things" to
the first couple of entries is not sufficient in this case.

----------------------------------------------------------------------

Comment By: Brian Carrier (carrier)
Date: 2012-05-02 06:37

Message:
Reported by Ilias Van Peer.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3523019&group_id=55685