X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=oEW8PUz8K9ct7EKj
	F6SIqamRF0GNtdhSBED8ifyFyugzWf0ipKXfrUMxYo6xGnp6hQxyV+vYjhJW8sYA
	TSWWul/kFj8sXnLBsiJDsug525VBpaF+h8c7myfWBB1uloHTM2geWRY5bZfBSWnv
	V1dQSAfu2cMLv6qzGg0NebMMP00=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=bJScUyerREwzEOol0Dtr0p
	ih/bQ=; b=v6JGrxQbxteo+zQggtwvJFo5Kt8ri4ELXdnjGiUeDvp3SNwv8mgYdv
	wy/njvgs5SA35dKLlxh+VmMSuetKt7uqKCvMarO9k6RiUiemBEnFok3r7fMXqIEa
	TGciOPOxgsmTCwfrOXMRXSyyIfBIR2v1VmjyVktgguN1x0u/iRx60=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=3.0 required=5.0 tests=AWL,BAYES_50,FOREIGN_BODY,GIT_PATCH_2,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=diese, wurde, H*RU:sk:mrelaye, H*r:sk:mrelaye
X-HELO:	mout.kundenserver.de
Subject:	Re: Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments (Windows)
To:	cygwin AT cygwin DOT com
References:	<001101d295e9$65841800$308c4800$@gmail.com>
From:	Thomas Wolff <towo AT towo DOT net>
Message-ID:	<dcedfe68-2abb-1b78-e58d-b12a1bc1682c@towo.net>
Date:	Mon, 6 Mar 2017 08:09:47 +0100
User-Agent:	Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version:	1.0
In-Reply-To:	<001101d295e9$65841800$308c4800$@gmail.com>
X-UI-Out-Filterresults:	notjunk:1;V01:K0:/0Wj5Ncmw8E=:72ma50YNWI/ei6HWoeL6ok Hy/coISAqCZMhgGKz7zCF1kUA2v7jdI4ppas5SGcHtxyJJ4e4TbDQWqH8rZIESTcp56VOaf+B qN9XAFR/KJr4UUROxpO2b0Cai2Ki+eNtBElyJO5S3tv+rch2rIkp3GPOxoiuNStru6rqi5ACb te/xlZ9PKqTKFDetprpEChL0XSWzBoM4q71lQoja+ZMNfndFr8Kp26+pY2dFDMksHUpYFton2 F9g+6pQlIZmtGDL2OV0RLWicsdYfS2To5ldqgrnIg1lH3JdEo7kTE/fM/G9pTnTjFBpc3zmw+ /l7S5RLywuO2ylTsLYi4D4AQ9qQQoG/lSyEYvGjoOa6G/90Cue9y64d5OJUZcfNCftO+T9W/Z pm2Ir3skPYw6oi0enSxd2TIgy7CmNJFicto1Fk9YLISEJCC4QZ1+Bae4HvnJN9sJoBq+TOcC0 fRj5GwmyCJiJ0CNMkx1DCFcYVXf399itjLIlR9PmuqZ5+ocp/D7VxKCJz7OVuBAwIqwzyUg1g 59he9qxb1A3s/zk020witpAyAbKlBk+ark49feqzYDbySNpxK5BqE/zuTAZzji8apb2pqHtzc RzpyJHWBRwJcglJCVKXSy8ulik8zoGGvXqAcdwGHultYz8f1JYj5ZacRB4X5+dtm3XwA2uzK+ V2G/KzyxX1Rw0DEuB7jbK9TIRtxoro6DLNOSzGHVxiGTHZxxYcfytjSr347WQ0OPPUTtWpjb7 FdikycJOtiXz5s4H
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id v267AcKm018281

Am 05.03.2017 um 20:48 schrieb Lukas' Home Page:
> Good morning,
>
> I find out a strange and bad beaviour in 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 (below), compiler doesn't even display warnings (event if you
> compile program with -std=c99 and -Wextra parameters). I compile on Windows
> 7 using that command:
>
> gcc main.c -o main.exe -Wextra
>
>
> Exploit example:
> ===============================
>
> #include <stdio.h>
> #include <stdbool.h>
>
> typedef volatile unsigned char uint8_t;
>
> int main()
> {
>      bool allowAccess = false; // allowAccess should be always FALSE
>      uint8_t userNumber;
>      char format[] = "%hhu";
>      char buffer[] = "257\n";
>      sscanf(buffer, format, &userNumber);
>      if (allowAccess)
>      {
>          printf("Access granted: secret information - Lech Walesa was a Bolek
> agent\n");
>      }
>      printf("Entered number is: %d\n", userNumber);
>      return 0;
> }
What output do you get (and on which of the mentioned systems),
what output do you expect (and why),
and how is Lech Walesa involved in the issue?
For me, the program produces correct output on cygwin, according to
cygwin's man page of sscanf, and I don't care which library is being used.
Thomas

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -