summaryrefslogtreecommitdiff
path: root/fpdfsdk/fpdfview_c_api_test.c
diff options
context:
space:
mode:
authorTom Sepez <tsepez@chromium.org>2017-02-27 11:43:55 -0800
committerChromium commit bot <commit-bot@chromium.org>2017-02-27 20:24:33 +0000
commit3f72fb4a3c983de00bae9c8437a1c09df9c9955b (patch)
tree64d73f9b0448952e714eb71ea8483eef628acdd5 /fpdfsdk/fpdfview_c_api_test.c
parent9162ff85c323b05e3280b319a388934e871e4aea (diff)
downloadpdfium-3f72fb4a3c983de00bae9c8437a1c09df9c9955b.tar.xz
Explicitly tag fxjs native objects.
Native object callbacks have to distinguish whether the object they have been given is actually a native object and not some ordinary JS object. For method/property calls, this happens via v8's signature mechanism, but signature checks aren't applied to method arguments themselves. Currently, we do this by treating any object with an internal field count of 2 as being such, but this is fragile, and it has been pointed out that other objects with two internal fields are present. Additionally, that the first field points to a structure with a small zero-based object definition ID doesn't really have enough entropy to trust that it isn't some other entity. So add a pointer to an internal address in the second slot to make this safer. Note that we'll also get the same release_assert in the majority of cases as described in the bug. This is great from a security standpoint, but not great from a functional standpoint, except this likely only occurs in the wild if they are trying to mess with us. This just guards the theoretical cases that might pass the existing release_assert. BUG=695830 Change-Id: I42db27d6ed1143269a852805e4e4d862a8ab8773 Reviewed-on: https://pdfium-review.googlesource.com/2847 Commit-Queue: Tom Sepez <tsepez@chromium.org> Reviewed-by: dsinclair <dsinclair@chromium.org>
Diffstat (limited to 'fpdfsdk/fpdfview_c_api_test.c')
0 files changed, 0 insertions, 0 deletions