diff options
author | Patrick Steinhardt <ps@pks.im> | 2022-12-01 14:47:23 (GMT) |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2022-12-09 05:26:21 (GMT) |
commit | 304a50adff6480ede46b68f7545baab542cbfb46 (patch) | |
tree | 865578d1011a7c2a3ba0b844887a1e96f0f9aaa9 /pretty.c | |
parent | f930a2394303b902e2973f4308f96529f736b8bc (diff) | |
download | git-304a50adff6480ede46b68f7545baab542cbfb46.zip git-304a50adff6480ede46b68f7545baab542cbfb46.tar.gz git-304a50adff6480ede46b68f7545baab542cbfb46.tar.bz2 |
pretty: restrict input lengths for padding and wrapping formats
Both the padding and wrapping formatting directives allow the caller to
specify an integer that ultimately leads to us adding this many chars to
the result buffer. As a consequence, it is trivial to e.g. allocate 2GB
of RAM via a single formatting directive and cause resource exhaustion
on the machine executing this logic. Furthermore, it is debatable
whether there are any sane usecases that require the user to pad data to
2GB boundaries or to indent wrapped data by 2GB.
Restrict the input sizes to 16 kilobytes at a maximum to limit the
amount of bytes that can be requested by the user. This is not meant
as a fix because there are ways to trivially amplify the amount of
data we generate via formatting directives; the real protection is
achieved by the changes in previous steps to catch and avoid integer
wraparound that causes us to under-allocate and access beyond the
end of allocated memory reagions. But having such a limit
significantly helps fuzzing the pretty format, because the fuzzer is
otherwise quite fast to run out-of-memory as it discovers these
formatters.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'pretty.c')
-rw-r--r-- | pretty.c | 26 |
1 files changed, 26 insertions, 0 deletions
@@ -13,6 +13,13 @@ #include "gpg-interface.h" #include "trailer.h" +/* + * The limit for formatting directives, which enable the caller to append + * arbitrarily many bytes to the formatted buffer. This includes padding + * and wrapping formatters. + */ +#define FORMATTING_LIMIT (16 * 1024) + static char *user_format; static struct cmt_fmt_map { const char *name; @@ -1046,6 +1053,15 @@ static size_t parse_padding_placeholder(const char *placeholder, if (!*end || end == start) return 0; width = strtol(start, &next, 10); + + /* + * We need to limit the amount of padding, or otherwise this + * would allow the user to pad the buffer by arbitrarily many + * bytes and thus cause resource exhaustion. + */ + if (width < -FORMATTING_LIMIT || width > FORMATTING_LIMIT) + return 0; + if (next == start || width == 0) return 0; if (width < 0) { @@ -1205,6 +1221,16 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */ if (*next != ')') return 0; } + + /* + * We need to limit the format here as it allows the + * user to prepend arbitrarily many bytes to the buffer + * when rewrapping. + */ + if (width > FORMATTING_LIMIT || + indent1 > FORMATTING_LIMIT || + indent2 > FORMATTING_LIMIT) + return 0; rewrap_message_tail(sb, c, width, indent1, indent2); return end - placeholder + 1; } else |