Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #141805
| Message-ID | <9069lf-q2j.ln1@wilbur.25thandClement.com> (permalink) |
|---|---|
| From | William Ahern <william@25thandClement.com> |
| Subject | Re: Safer and more convenient strcpy() |
| Newsgroups | comp.lang.c |
| References | (5 earlier) <8f69ad8b-a898-4423-8781-0df209e92782@googlegroups.com> <slrnq8374v.4jo.grahn+nntp@frailea.sa.invalid> <8dn8lf-9mt2.ln1@wilbur.25thandClement.com> <v5q8lf-saq.ln1@wilbur.25thandClement.com> <lnmum6ksdi.fsf@kst-u.example.com> |
| Date | 2019-03-07 20:00 -0800 |
Keith Thompson <kst-u@mib.org> wrote:
> William Ahern <william@25thandClement.com> writes:
>> William Ahern <william@25thandclement.com> wrote:
> [...]
>>> And then there's the matter that snprintf takes an int parameter for the
>>> buffer size as well as returning an int, raising the spectre of unexpected
>>> and undefined conversions and overflows. Indeed, the two issues
>>> combined--integer conversions and managing error conditions--makes the above
>>> example snprintf usage poorly written code, IMO.
>>
>> Correction: it only returns an int; it takes size_t. However, there's the
>> issue of the treatment of a buffer size value greater than INT_MAX.
>
> I think that's a matter of historical precedence, and likely not that
> much of a problem in practice.
>
> The *printf() functions have been defined to return int since before
> size_t even existed. size_t would make more sense, since the value is a
> size in bytes.
>
> But on a modern system with 16-bit int you aren't likely to need
> character arrays longer than 32767 bytes (in fact it's not likely to be
> a hosted implementation), and 2**31 bytes should be enough for anybody.
>
> Yes, the irony in that last claim is deliberate, but you won't often see
> buffers that big treated as strings.
In the intended, normal course of things I agree such a situation would be
rare or non-existent in most contexts. However, one must always be mindful
of malicious inputs. For example, the recent (January 2019) systemd journald
exploits rely on the ability send to build long, multi-gigabyte strings:
If we send a large "native" message to /run/systemd/journal/socket:
since the maximum size of a "native" entry is 768MB, and the minimum
length of a "native" item is 3 ("A=\n"), and the size of an EntryItem
structure is 16 (a 64-bit offset and a 64-bit hash), the maximum size of
the attacker-controlled alloca() in journal_file_append_entry() is 768MB
/ 3 * 16 = 4GB, large enough to jump from journald's main stack into the
mmap region, even on amd64.
-- https://www.qualys.com/2019/01/09/system-down/system-down.txt
String concatenation is often performed over a set of strings, providing an
attacker a multiplier. The maximum size of generated strings from user input
can grow very quickly.
On Linux/x86_64 one can potentially pass roughly 281474976579584
(MAX_ARG_STRLEN * MAX_ARG_STRINGS) bytes of string data through main().
https://github.com/torvalds/linux/blob/master/include/uapi/linux/binfmts.h
A program could easily blow INT_MAX just by concatenating argv to generate a
simple status or log message. These limits can even be hit unintentionally
in the wild.
https://github.com/ninja-build/ninja/issues/1261
(In that case only hitting MAX_ARG_STRLEN.)
Even if one were inclined to exclude the possibility of malicious inputs,
such a decision can require more consideration and effort than simply
writing robust code in the first place. Most programmers (the defenders)
don't and can't think like attackers, including myself. We're horrible at
assessing real risk, particularly when it comes to the mechanics of
exploits. The famous last words of the authors of many vulnerabilities are
doubtless, "I can't imagine how this could be exploited." (I know this
because I regularly see programmers literally recite this on forums.)
Defenders have poor imaginations. Conversely, judging by their code most
attackers are horrible at writing good code. But that's not their
responsibility. All an attacker needs is a good imagination, tenacity, and a
little luck.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-06 03:45 -0800
Re: Safer and more convenient strcpy() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-06 03:58 -0800
Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-06 04:31 -0800
Re: Safer and more convenient strcpy() "I Set My Girlfriend's Pantyhose on Fire" <cdalten@gmail.com> - 2019-03-06 05:18 -0800
Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-06 13:03 -0800
Re: Safer and more convenient strcpy() William Ahern <william@25thandClement.com> - 2019-03-06 16:51 -0800
Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-07 07:40 -0800
Re: Safer and more convenient strcpy() scott@slp53.sl.home (Scott Lurndal) - 2019-03-07 16:12 +0000
Re: Safer and more convenient strcpy() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-07 08:28 -0800
Re: Safer and more convenient strcpy() scott@slp53.sl.home (Scott Lurndal) - 2019-03-07 16:51 +0000
Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-07 09:31 -0800
Re: Safer and more convenient strcpy() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-07 11:17 -0800
Re: Safer and more convenient strcpy() Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-07 22:35 +0000
Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-07 15:32 -0800
Re: Safer and more convenient strcpy() scott@slp53.sl.home (Scott Lurndal) - 2019-03-08 14:29 +0000
Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-08 07:09 -0800
Re: Safer and more convenient strcpy() Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-08 15:39 +0000
Re: Safer and more convenient strcpy() Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-08 07:56 -0800
Re: Safer and more convenient strcpy() Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-09 08:12 +0000
Re: Safer and more convenient strcpy() William Ahern <william@25thandClement.com> - 2019-03-07 15:51 -0800
Re: Safer and more convenient strcpy() William Ahern <william@25thandClement.com> - 2019-03-07 16:38 -0800
Re: Safer and more convenient strcpy() Keith Thompson <kst-u@mib.org> - 2019-03-07 18:32 -0800
Re: Safer and more convenient strcpy() William Ahern <william@25thandClement.com> - 2019-03-07 20:00 -0800
Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-08 04:15 -0800
Re: Safer and more convenient strcpy() "I Set My Girlfriend's Pantyhose on Fire" <cdalten@gmail.com> - 2019-03-07 12:15 -0800
Re: Safer and more convenient strcpy() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 09:12 -0800
Re: Safer and more convenient strcpy() mark.bluemel@gmail.com - 2019-03-06 08:27 -0800
Re: Safer and more convenient strcpy() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 09:22 -0800
Re: Safer and more convenient strcpy() Rosario19 <Ros@invalid.invalid> - 2019-03-07 09:10 +0100
Re: Safer and more convenient strcpy() Rosario19 <Ros@invalid.invalid> - 2019-03-07 09:12 +0100
Re: Safer and more convenient strcpy() mark.bluemel@gmail.com - 2019-03-07 00:55 -0800
Re: Safer and more convenient strcpy() William Ahern <william@25thandClement.com> - 2019-03-07 16:09 -0800
Re: Safer and more convenient strcpy() Howard Chu <highlandsun@gmail.com> - 2019-03-08 04:04 -0800
Re: Safer and more convenient strcpy() eric.sanchis@iut-rodez.fr - 2019-04-15 04:40 -0700
Re: Safer and more convenient strcpy() nobody@example.org (Scott) - 2019-04-16 03:33 +0000
Re: Safer and more convenient strcpy() eric.sanchis@iut-rodez.fr - 2019-04-16 05:35 -0700
Re: Safer and more convenient strcpy() nobody@example.org (Scott) - 2019-04-17 01:19 +0000
Re: Safer and more convenient strcpy() eric.sanchis@iut-rodez.fr - 2019-04-17 05:35 -0700
Re: Safer and more convenient strcpy() nobody@example.org (Scott) - 2019-04-17 16:59 +0000
Re: Safer and more convenient strcpy() eric.sanchis@iut-rodez.fr - 2019-04-17 23:40 -0700
Re: Safer and more convenient strcpy() Philipp Klaus Krause <pkk@spth.de> - 2019-03-20 11:10 +0100
Re: Safer and more convenient strcpy() Philipp Klaus Krause <pkk@spth.de> - 2019-03-20 11:13 +0100
csiph-web