| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
If hivex_value_multiple_strings was given a value which had an odd
length or if the data in the value was unterminated,
hivex_value_multiple_strings could read uninitialized data.
Potentially (although very unlikely) this could cause a
non-exploitable segfault in the calling program.
|
| |
|
|
|
| |
If the length of the buffer is not even, then this would read a byte
of uninitialized data. Fix the length check to avoid this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In real registries, often the length declared in the header does not
match the length of the block. In this case hivex_value_value would
only allocate a value with a size which is the shorter of the two
length values, which is correct and safe.
However user code could do:
buf = hivex_value_value (h, v, &t, &len);
memcpy (somewhere, buf, len);
which would copy uninitialized data.
If hivex_value_value truncates a value like this, we also need to
return the shorter length to the user as well.
|
| |
|
|
|
|
| |
The previous commit b71b88f588f8660935a7d462e97b84aa2d669249 attempted
to fix this, but got the test the wrong way round so the length would
never be shorter.
|
| |
|
|
| |
Found using valgrind.
|
| | |
|
| |
|
|
|
| |
Thanks to Hilko Bengen for characterizing the issue and
providing an initial version of this patch.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Make sure all new block allocations (from allocate_block)
are zeroed. It can happen that junk from previous hive pages
can end up in new block allocations, if the hive previously
shrank.
(Thanks to Marko Myllynen for finding an example where this
happened).
|
| |
|
|
|
| |
I was sent a genuine Windows XP hive by Marko Myllynen which
had a key with > 1000 values attached.
|
| |
|
|
|
|
| |
Windows 7 registry has a hive key which contains 11908 subkeys,
larger than the existing limit (10000). The key is:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners
|
| | |
|
| |
|
