threads / patch / 51240
Subject: [PATCH v2 0/2] Harden url.c URL-decoding logic
Matthew DeVoreThis roll-up includes simple but important fixes from Brian Carlson and René Scharfe.
- fix typo of "NUL" in commit heading - re-enable %-decoding in non-NULL-terminated strings
Matthew DeVore (2): url: do not read past end of buffer url: do not allow %00 to represent NUL in URLs
url.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
-- 2.21.0
Matthew DeVore[PATCH v2 1/2] url: do not read past end of buffer
url_decode_internal could have been tricked into reading past the length of the **query buffer if there are fewer than 2 characters after a % (in a null-terminated string, % would have to be the last character). Prevent this from happening by checking len before decoding the % sequence.
Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: Matthew DeVore <matvore@google.com> --- url.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/url.c b/url.c index 25576c390b..9ea9d5611b 100644 --- a/url.c +++ b/url.c @@ -39,21 +39,21 @@ static char *url_decode_internal(const char **query, int len, unsigned char c = *q; if (!c) break; if (stop_at && strchr(stop_at, c)) { q++; len--; break; } - if (c == '%') { + if (c == '%' && (len < 0 || len >= 3)) { int val = hex2chr(q + 1); if (0 <= val) { strbuf_addch(out, val); q += 3; len -= 3; continue; } } if (decode_plus && c == '+')
-- 2.21.0
Junio C HamanoRe: [PATCH v2 1/2] url: do not read past end of buffer
Matthew DeVore <matvore@google.com> writes:
> url_decode_internal could have been tricked into reading past the length
> of the **query buffer if there are fewer than 2 characters after a % (in
> a null-terminated string, % would have to be the last character).
> Prevent this from happening by checking len before decoding the %
> sequence.
>
> Helped-by: René Scharfe <l.s.r@web.de>
> Signed-off-by: Matthew DeVore <matvore@google.com>
> ---
> url.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/url.c b/url.c
> index 25576c390b..9ea9d5611b 100644
> --- a/url.c
> +++ b/url.c
> @@ -39,21 +39,21 @@ static char *url_decode_internal(const char **query, int len,
> unsigned char c = *q;
>
> if (!c)
> break;
> if (stop_at && strchr(stop_at, c)) {
> q++;
> len--;
> break;
> }
>
> - if (c == '%') {
> + if (c == '%' && (len < 0 || len >= 3)) {
> int val = hex2chr(q + 1);This made me wonder what happens when the caller sent -1 in len, but hex2chr() stops on such a string with % plus one hexadecimal at the end of the string, and we'd end up copying these two bytes one at a time, which is what we want, so it is OK. And the rejection of %00 done in 2/2 follows the same codeflow here, which is quite straight forward.
Nice.
> if (0 <= val) {
> strbuf_addch(out, val);
> q += 3;
> len -= 3;
> continue;
> }
> }
>
> if (decode_plus && c == '+')Matthew DeVore[PATCH v2 2/2] url: do not allow %00 to represent NUL in URLs
There is no reason to allow %00 to terminate a string, so do not allow it. Otherwise, we end up returning arbitrary content in the string (that which is after the %00) which is effectively hidden from callers and can escape sanity checks and validation, and possible be used in tandem with a security vulnerability to introduce a payload.
Helped-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Matthew DeVore <matvore@google.com> --- url.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/url.c b/url.c index 9ea9d5611b..1b8ef78cea 100644 --- a/url.c +++ b/url.c @@ -41,21 +41,21 @@ static char *url_decode_internal(const char **query, int len, if (!c) break; if (stop_at && strchr(stop_at, c)) { q++; len--; break; } if (c == '%' && (len < 0 || len >= 3)) { int val = hex2chr(q + 1); - if (0 <= val) { + if (0 < val) { strbuf_addch(out, val); q += 3; len -= 3; continue; } } if (decode_plus && c == '+') strbuf_addch(out, ' '); else
-- 2.21.0
Matthew DeVoreRe: [PATCH v2 0/2] Harden url.c URL-decoding logic
First message had incorrect recipient list. Re-sending with non-typo'd Jeff's e-mail address.
Someone also politely reminded me off-band that I should make subsequent versions of patchsets be respond-to on the cover-letter of v1 of that patchset. I will do that from next time.