Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
plist_from_bin() fails
If the allocation fails, a lot of bad things can happen so we check the
result and return accordingly. We also check that the multiplication used
to calculate the buffer size doesn't overflow. Otherwise this could lead
to an allocation of a very small buffer compared to what we need, ultimately
leading to arbitrary writes later on.
|
|
offset_table_index is read from the file, so we have full control over it.
This means we can point offset_table essentially anywhere we want, which can
lead to an out-of-bounds read when it will be used later on.
|
|
the offset table
|
|
bounds checking
|
|
bounds checking
|
|
In case parsing inside `node_from_xml` called from line 842 fails, `data`
gets freed by the call to `plist_free` at line 899, since `subnode` is
actually created by making it point to `data` at line 684. This commit
prevents this situation by bailing out whenever parsing in a deeper level
of structured nodes fails.
|
|
If `ctx->pos - p - 1` is greater than `taglen`, we end up writing outside
the buffer pointed to by `tag`. This commit fixes it by checking the bounds
of the heap buffer before writing.
|
|
|
|
|
|
|
|
|
|
The main benefit of this is to allow date/time values outside of the 32bit time_t
range which is very important on 32bit platforms. But there are also some other
issues that will be fixed with this, for example on macOS, mktime() will not work
for dates < 1902 despite time_t being 64bit.
In the same run this commit will also use a reentrant version of gmtime64_r that
should help in multithreaded scenarios.
Original code taken from: https://github.com/evalEmpire/y2038
|
|
This removes the timeval union member from the plist_data_t structure.
Since struct timeval is 2x64bit on 64bit platforms this member unnecessarily
grew the union size to 16 bytes while a size of 8 bytes is sufficient.
Also, on 32bit platforms struct timeval is only 2x32bit of size, limiting the
range of possible time values. In addition the binary property list format
also stores PLIST_DATE nodes as double.
|
|
|
|
In node_to_xml nodes of type PLIST_UID are temporarily converted
to a PLIST_DICT for an appropriate XML output. Therefore a PLIST_KEY
and a PLIST_UINT node is created and inserted into the PLIST_DICT
node. Upon completion, the child nodes of the PLIST_DICT node are
detached from the original node and freed, however the data of the
child nodes - the key string and the uint value - are not.
This commit fixes it.
|
|
Without this check, e.g. the values -1 and 18446744073709551615 would yield in a
match, since the comparison will just compare the uint64_t values. However, any
value >= 9223372036854775808 and <= 18446744073709551615 is stored as a 128 bit
value in binary plist format to make sure it is recognized as an unsigned value.
We store it internally as a uint64_t value, but we set the size to 16 vs. 8
accordingly; so this commit will make sure the binary plist optimization will
not re-use matching uint64_t values of actually mismatching signed/unsigned values.
|
|
Rather than having everyone reimplement binary/XML plist detection by
looking at the first bytes of the plist content, it's better to do this
detection in libplist and hide that internal detail from library users.
|
|
It can be useful if one needs to know what type of plist a memory buffer
contains.
|
|
Using a better hashing algorithm and a larger hash table the conversion
is A LOT faster when processing large plists. Thanks to Xiao Deng for
reporting this issue and suggesting a fix.
|
|
|
|
Fixes libimobiledevice/libplist#50.
|
|
point values
|
|
|
|
When parsing binary plists with BPLIST_DICT or BPLIST_ARRAY nodes that are
referenced multiple times in a particular file, a buffer was allocated that
was not used, and also not freed, thus causing memory leaks.
|
|
freed memory
Given a specifically ordered binary plist the function plist_from_bin() would
free BPLIST_DICT or BPLIST_ARRAY raw node data that is still required for
parsing of following nodes. This commit addresses this issues by moving the
memory free to the end of the parsing process.
|
|
|
|
This is actually considered bad practice. However, it appears this
memory leak is otherwise not possible to fix due to a design flaw
in how libxml2 handles the lifecycle of it's XML parser.
We'll let the community test this in production now and decide.
In our tests this change had no drawbacks except fixing the last known
memory leak in libplist.
|
|
|
|
By using a specifically crafted XML file an attacker could use plistutil
to issue a GET request to an arbitrary URL or disclose a local file.
The crafted XML file would be using a custom DTD with an external entity
reference pointing to the file. Practical abuse is limited but let's still
fix it nevertheless. Related to CVE-2013-0339 for libxml2 and CWE-827.
Reported by Loïc Bénis from calypt.com. Thanks!
|
|
for WIN32.
|
|
The parsing logic for binary dictionaries wrongly enforced the key type even
on nodes that were already parsed as value nodes. This caused the resulting
plist_t node tree to have key nodes instead of value nodes within dictionaries
for some valid binary plists. This commit should also generally fixes parsing
of binary plist files which use an efficient dictionary reference table.
|
|
|
|
|
|
binary plist
|
|
strings
|
|
|
|
references and a const GetValue().
|
|
|
|
mismatch
|
|
|
|
|
|
|
|
|
|
|