search for: rootoffs

...+ (((off) & 3) == 0 && \ + (off) >= 0x1000 && \ + (off) < (h)->size && \ + BITMAP_TST((h)->bitmap,(off))) + + /* Fields from the header, extracted from little-endianness hell. */ + size_t rootoffs; /* Root key offset (always an nk-block). */ + size_t endpages; /* Offset of end of pages. */ + char *last_modified; /* mtime of base block. */ + + /* For writing. */ + size_t endblocks; /* Offset to next block allocation (0 +...

...there might be an issue if the file is truncated after a page offset. "off < h->size” will return true, but accesses to page contents will be out-of-bounds. So I think that would need to be “off + sizeof(ntreg_hbin_page) < h->size”? For example, truncating a registry file at h->rootoffs and with a purposely-wrong hdr->offset = 0, I think you’ll get past "if (off >= h->endpages)” and you’ll be reading the page out-of-bounds while checking hbin magic. I have to run, but I think there may be a few more instances of things like this.. I know these are only reads, but I...

...,7 @@ #include <sys/mman.h> #include <sys/stat.h> #include <assert.h> +#include <time.h> #include "c-ctype.h" #include "full-read.h" @@ -93,6 +94,7 @@ struct hive_h { /* Fields from the header, extracted from little-endianness hell. */ size_t rootoffs; /* Root key offset (always an nk-block). */ size_t endpages; /* Offset of end of pages. */ + char *last_modified; /* mtime of base block. */ /* For writing. */ size_t endblocks; /* Offset to next block allocation (0 @@ -104,7 +106,7 @@ str...

Hello all, I know that one of the original design goals of libhivex was to be resilient to corrupt, invalid, or malicious registry hives. I've encountered some undefined behavior in libhivex when attempting to open registry files that are too small. I'm not sure if this is a known issue per-se or not, so I figured I'd ask here on the mailing list before I jumped in and started adding

...izeof(ntreg_hbin_page) < h->size”? I added a second check that the page we're reading in the loop at line ~ 220 doesn't extend beyond the end of the file, which I think should be sufficient. That's the second attached patch. > For example, truncating a registry file at h->rootoffs and with a > purposely-wrong hdr->offset = 0, I think you’ll get past "if (off >= > h->endpages)” and you’ll be reading the page out-of-bounds while > checking hbin magic. > I have to run, but I think there may be a few more instances of > things like this.. I know the...

...ne TIMESTAMP_BUF_LEN 32 + /* Pre-defined types. */ enum hive_type { "; diff --git a/lib/hivex.c b/lib/hivex.c index fedbb6c..1e77831 100644 --- a/lib/hivex.c +++ b/lib/hivex.c @@ -93,6 +93,7 @@ struct hive_h { /* Fields from the header, extracted from little-endianness hell. */ size_t rootoffs; /* Root key offset (always an nk-block). */ size_t endpages; /* Offset of end of pages. */ + int64_t last_modified; /* mtime of base block. */ /* For writing. */ size_t endblocks; /* Offset to next block allocation (0 @@ -104,7 +105,7 @@ str...

This is, hopefully, a full fix for handling of li-records. See: https://bugzilla.redhat.com/show_bug.cgi?id=717583 https://bugzilla.redhat.com/show_bug.cgi?id=987463 Rich.