From: Yair Lenga <yair.lenga@gmail.com>
To: libc-alpha@sourceware.org
Subject: Improved Buffer overflow for scanf* functions
Date: Tue, 12 Jul 2022 10:02:38 +0300 [thread overview]
Message-ID: <CAK3_KpP0mwopfJXb9Kpyw+PB+=HSOfLNcDFK5g0D5ATpoHA-oQ@mail.gmail.com> (raw)
Hi,
I posting into libc-alpha, based on feedback that I got from libc-help
members on proposal to improve buffer checks for scanf* functions.
Short summary - scanf* are a constant source for buffer overflow issues.
There is no good mechanizm to address the very common use case:
char foo[FOOSIZE] ;
scanf("%s", foo) ; // How to limit the actual size
All proposed solution do not scale well - especially when the code base is
large. See few of them below:
* Use explicit width - scanf("%20s", foo) - does not work well for FOOSIZE
changes.
* Use dynamic allocation char *foobuff = NULL ;sscanf ("%ms", &value) ;
strcpy(foo, foobuff, sizeof(foo)-1) ; free(foobuff) ;
* Create dynamic format: char fmt[1000] ; sprintf(fmt, "%%ds", FOOSIZE-1) ;
scanf(fmt, foo) ;
One alternative is to allow "dynamic" width, following the '*' style used
by printf, where width field can be replaced by '*', which indicates the
argument list will contain an integer specifying the width. One unfortunate
issue: the '*' is already assigned a meaning of 'avoid assignment' flag.
The final suggestion that came up from the discussion is:
* Use a special character (my favorite: '@') in the scanf. It will be
allowed in the sequences '%@s', '%@[' and '%@S', etc. TThis should indicate
that the width will be picked from the next integer argument, which is
expected to be the sizeof, or the dynamic size (if malloc was used). The
number of characters will be one less the size, to ensure the string is
always null terminated. The implementation will look like:
sscanf("%@s", sizeof(foo), foo) ; // fixed size string: char
foo[FOOSIZE] ;
My question:
* Would like to get community feedback from the glibc maintainer - is there
a reasonable chance that this will be accepted as a GLIBC extension to
scanf. I understand that this is not a light decision - but considering the
security risks associated with the current state - anything is better than
the current alternative.
As far as implementing, I've reviewed the code for glibc scanf (and a few
other implementations) - looks like a very light effort.Since the '@' is
currently not allowed, it's not going to break any existing code.
Looking for feedback, comments, idea,
Yair
reply other threads:[~2022-07-12 7:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK3_KpP0mwopfJXb9Kpyw+PB+=HSOfLNcDFK5g0D5ATpoHA-oQ@mail.gmail.com' \
--to=yair.lenga@gmail.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).