From 6b28772660ce673e1c9a30dbcea6a06bdcd2a3c7 Mon Sep 17 00:00:00 2001 From: Guy Harris Date: Mon, 2 Sep 2019 19:08:36 -0700 Subject: [PATCH] Strengthen the JSON validator. jsmn_parse() is handed a buffer and a count of octets in the buffer; it treats either running out of octets, as specified by the count, *OR* seeing a NUL as meaning "end of JSON string". That means that a buffer, of arbitrary size, the first octet of which is zero is a null string and considered valid JSON. That is clearly bogus; it messes up both tests for JSON files *and*, potentially, heuristic checks for JSON in packet payloads. Bug: 16031 Change-Id: I5ee78b613df3358f19787f2ce28ddc883368f03d Reviewed-on: https://code.wireshark.org/review/34438 Petri-Dish: Guy Harris Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris --- wsutil/wsjson.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/wsutil/wsjson.c b/wsutil/wsjson.c index 96145af81f..087c510894 100644 --- a/wsutil/wsjson.c +++ b/wsutil/wsjson.c @@ -36,6 +36,18 @@ json_validate(const guint8 *buf, const size_t len) if (!t) return FALSE; + /* + * Make sure the first octet isn't a NUL; otherwise, the parser will + * immediately stop parsing and not validate anything after that, + * so it'll just think it was handed an empty string. + * + * XXX - should we check for NULs anywhere in the buffer? + */ + if (buf[0] == '\0') { + g_log(LOG_DOMAIN_MAIN, G_LOG_LEVEL_DEBUG, "jsmn: invalid character inside JSON string"); + return FALSE; + } + jsmn_init(&p); rcode = jsmn_parse(&p, buf, len, t, max_tokens); if (rcode < 0) {