From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11160 invoked from network); 5 Sep 2021 13:36:33 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 5 Sep 2021 13:36:33 -0000 Received: (qmail 12207 invoked by uid 550); 5 Sep 2021 13:36:30 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 12174 invoked from network); 5 Sep 2021 13:36:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=opensmtpd; bh=wGGGgKlS9r 9DjW09Afi7HeOs61S58gaiWF9hmJ6Necg=; h=from:subject:to:date; d=soeren-tempel.net; b=peQ1YdISNg/bDcZLGRRmAApUiBjb/NNogR34WQZH8QPMYgt DAHkk6GRt2wGW0kQO7EqcARq34HfKHxFV4BgZEKTSqUE0FMjy0EJsMjtx/yoMN1FcTnGS6 VTIzW+lHWJVPoaPDnJdZu+Z4BNRssJi+3a3oWECRehLMC0brz1EK5k= Date: Sun, 05 Sep 2021 15:36:12 +0200 To: musl@lists.openwall.com From: =?UTF-8?Q?S=C3=B6ren?= Tempel Message-Id: <2R2YR9WZKQ66Q.2ITJ44PGSICVN@8pit.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_6a396e6b29bf775359398bba_=_" Subject: [musl] tzset() cannot handle arbitrary inputs This is a multipart message in MIME format. ------_=_6a396e6b29bf775359398bba_=_ Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, This is a follow-up to a discussion on the IRC channel regarding musl's tzset() implementation. I did some tests of the tzset() code. The code basically provides parsers for two kinds of input formats: 1. TZ env values (e.g. in the TZ POSIX format [1]) 2. Zoneinfo files as provided by the IANA [2] As part of my performed tests I found various spatial memory safety violations in these two parsers. Both of them parse input through a pointer which is continuously advanced using pointer arithmetic and then dereferenced to access individual fields of the input formats. Unfortunately, the parsing code is largely lacking boundary checks to ensure that the pointer is still in bounds when dereferenced. As an example, consider the attached zoneinfo file. This file will cause musl to perform an out-of-bounds memory read which likely results in a segmentation fault on most systems: $ TZ=3D./zonefile-musl-crash.bin busybox date Segmentation fault (core dumped) This particular zoneinfo file causes a segmentation fault due to the calculation of the types pointer: types =3D index + zi_read32(trans-12); (gdb) p zi_read32(trans-12) $1 =3D 4286962800 The resulting types pointer value is outside the bounds of the mapped zoneinfo file (which is only 2048 bytes large). The value is also dereferenced later as part of the following code: for (p=3Dtypes; p