Skip to content

Off by One Underflow on hfind #1575

Open
@nicowaisman

Description

@nicowaisman

Dear sleuthkit team,

I would like to report a security vulnerability in SleuthKit.

There is an off-by-one overwrite due to an underflow on hfind.cpp while using a bogus hash table.

On the main function, when a hash table is used, it read the first line and try to remove the newline character, however, if a bogus hash file is used with a NULL as the first character, the fgets will work however when it try to clean the new line using strlen(buf), it will return zero and as a consequence a zero will be written at the position buf[-1] = '\0'.

int
main(int argc, char ** argv1) {
int ch;
TSK_TCHAR *idx_type = NULL;
TSK_TCHAR *db_file = NULL;
[..]
char buf[100];
[..]

if (NULL == fgets(buf, 100, handle)) {
break;
}
#endif
 
/* Remove the newline */
buf[strlen(buf) - 1] = '\0';

A simple proof of concept consists of using a hash lookup file with NULL as the first character:

$ hfind -f boom.hex any.db
nico@genmaicha:~/Semmle/Projects/SleuthKit/sleuthkit/tools/hashtools$ hexdump /tmp/boom.hex
0000000 aa00 aaaa aaaa aaaa aaaa aaaa aaaa aaaa
0000010 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
*
0000110 aaaa aaaa 00aa

The exact line could be found here:
https://lgtm.com/projects/g/sleuthkit/sleuthkit/snapshot/09ed6f84870b18aec51cbb9373e226d04264da8f/files/tools/hashtools/hfind.cpp?sort=name&dir=ASC&mode=heatmap#L351

Please let me know when you have fixed the vulnerability so that I can coordinate my disclosure with yours. For reference, here is a link to Semmle's vulnerability disclosure policy: https://lgtm.com/security#disclosure_policy

Thank you,

Nico Waisman
Semmle Security Research Team

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions