#174 NULL attribute 'name' in 3.2.0 and 3.2.1

[rob@klpd]

In the 2.3 release of OCFA libtsk is used by the tsklf module. This module was working OK in the 3.1 version of libtsk. Now with the 3.2 releases tskfs seems to have broken as a result of the fact that the attribute name now has become a NULL character pointer instead of a pointer to a real name.

Currently tskfs uses the name info to determine if it is handling the main content of the file, or some other attribute. The following is code from tskfs that has broken as a result of this problem:

//Helper function for constructor for processing data attribute.
attributetype TskFsInode::processAttribute(const TSK_FS_ATTR *attribute,std::string name) {
if (attribute->size == 0) {
return ATTR_NODATA;
}
if (((attribute->name) && ( (std::string(attribute->name) == "$Data")))||(attribute->type == TSK_FS_ATTR_TYPE_DEFAULT)) { //Process normal data attribute.
if (name =="EFS0.TMP") { //Special marker for EFS0.TMP file.
ocfa::misc::metautil::addMetaToMap(mMeta,"specialmarker", new ocfa::misc::ScalarMetaValue(ocfa::misc::Scalar("efs-crypto-temp")));
}
return ATTR_PRIMARY;
}
if ((attribute->name) && (std::string(attribute->name)) == "$I30") {
return ATTR_NODATA;
}
if (attribute->type == TSK_FS_ATTR_TYPE_NTFS_BITMAP) {
return ATTR_NODATA;
}
if (attribute->flags & TSK_FS_ATTR_NONRES) { //All non resident attributes are processed as data attributes.
return ATTR_DATA;
} else {
switch (attribute->type) {
case TSK_FS_ATTR_TYPE_NTFS_SI:
if (mVerboseMeta) { //Only process SI information in verbose meta mode.
processNtfsStandardInfo(attribute);
}
//fall trough OK.
case TSK_FS_ATTR_TYPE_NTFS_FNAME:
//fall trough OK.
case TSK_FS_ATTR_TYPE_NTFS_VVER:
return ATTR_NODATA;
default:
return ATTR_DATA;
}
}
}

Currently this means that ATTR_PRIMARY is no longer recognized correctly by the code above, and tskfs processes NTFS images severely wrong.

[rob@klpd]

The tskfs file where the above occurs

[rob@klpd]

The one level up source file where the TfkFsInode is created.

[rob@klpd]

The 2 levels up source file where the image is opened, the file system is opened and the one level up TskFsDirectory object is created.

[rob@klpd]

Added the 3 possibly relevant OCFA tskfs module files so the libtsk calls can easily be seen in the sequence that led to the given symptoms.

[rob@klpd]

A simple peice of code that demonstrates the bug.

[rob@klpd]

brokenlibstkdemo output with (non broken) 3.1.3 version of libtsk

[rob@klpd]

brokenlibstkdemo output with (broken) 3.2.1 version of libtsk

[rob@klpd]

I've added a small piece of code that demonstrates the difference between the two versions of libtsk. This code has an hardcoded image name for an ntfs partition image and a hardcoded inumber for a file with an alternate stream.

Also added two output files for this code, one generated with the 3.1 and one with the 3.2 version of libtsk. These files show that the old libtsk named its steam '$Data' and its altstreams something user defined. The new libtsk returns NULL for the name of the primary stream.

Currently the OCFA tskfs module uses the magic '$Data' name to distinguish between the primary stream and any alternative stream, and for this reason the tskfs module breaks completely by this bug/feature, mis-qualifying all normal files as empty files with an alternative stream.

So possibly this might actualy be a bug in tskfs, but with no reliable cross-versionalternative way to distinguish between the primary and alternate streams, it appears on first sight to be a libtsk bug.