[sleuthkit-developers] regression bug in sleuthkit iso9660

[Michael C. <scu...@gm...>]

Hi All,
  There seems to be a regression bug in sk iso9660 handling. The
problem started during version 2.10 (i.e. 2.09 worked correctly).
Version 2.09 defines the following macro:

#define parseu32(foo, x) \
    (uint32_t)( (foo->endian & TSK_LIT_ENDIAN)  ? \
    ((uint32_t) \
        ((uint32_t)((uint8_t *)(x))[0] << 0) + \
        ((uint32_t)((uint8_t *)(x))[1] << 8) + \
        ((uint32_t)((uint8_t *)(x))[2] << 16) + \
        ((uint32_t)((uint8_t *)(x))[3] << 24)) \
        : \
    ((uint32_t) \
        ((uint32_t)((uint8_t *)(x))[7] << 0) + \
        ((uint32_t)((uint8_t *)(x))[6] << 8) + \
        ((uint32_t)((uint8_t *)(x))[5] << 16) + \
        ((uint32_t)((uint8_t *)(x))[4] << 24)) )

Note that x is an unsigned char [8]. In particular this is called from
iso9660_open as:
fs->block_count = parseu32(fs, iso->pvd->pvd.vol_spc)

In sk 2.10 the primary volume descriptor was redefined to have better
granularity. In particular the volume size was split into 2 parts:

    uint8_t vs_sz_l[ISODCL(81, 84)];    /* volume space size in blocks - le */
    uint8_t vs_sz_m[ISODCL(85, 88)];    /* volume space size in blocks - be */

presumable the iso header specifies the same quantity both in big and
little endian. iso9660_open then goes to calculate the block_count as:

if (iso->pvd) {
        fs->block_size = tsk_getu16(fs->endian, iso->pvd->pvd.blk_sz_m);
        fs->block_count = tsk_getu32(fs->endian, iso->pvd->pvd.vs_sz_m);
    }

This is wrong now because fs->endian can be big or little presumably,
but iso->pvd->pvd.vs_sz_m is always big endian. The correct call
should be (or equally we can choose the big endian version too):
if (iso->pvd) {
        fs->block_size = tsk_getu16(TSK_LIT_ENDIAN, iso->pvd->pvd.blk_sz_l);
        fs->block_count = tsk_getu32(TSK_LIT_ENDIAN, iso->pvd->pvd.vs_sz_l);
    }

That is we should just pick an endianess and use the corresponding
vs_sz_X.  I guess from a forensic pov what if they say different
things? Presumably the os which mounts it would only look at either
the big endian version or the little endian version. Maybe this can
result in a disk which shows more files if mounted on a big endian
machine vs a little endian machine???  Maybe SK should issue warnings
if the fields contradict.

Michael.