[sleuthkit-developers] [ sleuthkit-Bugs-3393960 ] hfind does not correctly parse input file on Windows

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

Bugs item #3393960, was opened at 2011-08-18 14:41
Message generated for change (Tracker Item Submitted) made by wilbal1087
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=477889&aid=3393960&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: Hash Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Willi Ballenthin (wilbal1087)
Assigned to: Nobody/Anonymous (nobody)
Summary: hfind does not correctly parse input file on Windows 

Initial Comment:
Platform: Win32
TSK: 3.2.2 source

BUG:
hfind does not correctly parse input file on Windows

DETAILS:

hfind accepts the optional argument '-f' and a filename that points to a file containing a list of hashes.  The hashes should be separated by newlines.  On Linux, the input file is parsed correctly.  On Windows, the hashes are not parsed correctly, and the program exits with the error "Invalid argument (hdb_lookup: Invalid hash length".

This appears to be due to the use of fgets vs ReadFile on Linux and Windows, respectively.   fgets stops reading at a newline (or 100 bytes), while ReadFile reads 100 bytes regardless. A fix for this is to manually look for the newline in the resulting buffer.  For example, a potential fix may beto replace the Win32 code around 251 in hfind.cpp:

+	    int done = 0;
+	    int i;
+
+	    for (i = 0; i < 100; i++) {
+	      if (FALSE == ReadFile(handle, &buf[i], 1, &nread, NULL)) {
+		done = 1;
+		break;
+	      }
+	      if (buf[i] == '\n') {
+		break;
+	      }
+	    }
+	    if (done) {
+	      break;
+	    }

This fix is attached a patch against TSK 3.2.2.  Unfortunately, I have not tested the code, as I don't have a Windows dev environment.

Also note that the current code may have a security vulnerability due to the same bug.  Line 265 in hfind.cpp writes a NULL to buf[strlen(buf) - 1].  If a null is not read by ReadFile, then the write will occur outside the string buffer. I do not know if this is exploitable.


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

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