Off by One Underflow on hfind

[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

[nluedtke]

This was assigned CVE-2019-14532.