https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79879
Bug ID: 79879
Summary: Integer overflow in functions from scanf() family in
MinGW, Cygwin, Borland/Embarcadero C environments
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: wyporek at poczta dot onet.pl
Target Milestone: ---
Created attachment 40884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40884&action=edit
Exploit
Good morning,
I find out a strange and bad beaviour of functions from scanf() family when
reading one-byte int variable in MinGW, Cygwin and Borland/Embarcadero C
environments (on Windows, on Linux this doesn't happen). This bug is corelated
with MSVCRT library which isn't written in C99 standard (it's written in C89 i
think).
So, the point is, when you're reading one byte using scanf() function, AND you
are using %hhu format specifier, you have Integer Overflow bug in your code,
because MinGW links to old MSVCRT (C89 version) even if you compile with
-std=c99 parameter.
This works, because scanf() in old MSVCRT library doesn't know "h" format
specifier. BUT! The problem is, that scanf try to interpret format specifier
anyway, omits unsupported "h" specifier and it's loading full integer ("u") to
memory (it should omit not supported part of format - whole "%hhu" format part,
not just only "h"). The C99 specification says on 361 page: "If a conversion
specification is invalid, the behavior is undefined." - but it is WRONG,
because the behaviour SHOULD BE DEFINED AS OMITING THE WHOLE UNSUPPORTED PART
OF FORMAT (not only single specifier, but whole part).
In exploit (in attachment), compiler doesn't even display warnings (event if
you compile program with -std=c99 and -Wextra parameters). I compile using that
command:
gcc main.c -o main.exe -std=c99 -Wextra
