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.3 required=5.0 tests=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 9515 invoked from network); 5 Sep 2021 23:11:51 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 5 Sep 2021 23:11:51 -0000 Received: (qmail 26451 invoked by uid 550); 5 Sep 2021 23:11:49 -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 26427 invoked from network); 5 Sep 2021 23:11:48 -0000 Date: Sun, 5 Sep 2021 19:11:35 -0400 From: Rich Felker To: =?utf-8?B?U8O2cmVu?= Tempel Cc: musl@lists.openwall.com Message-ID: <20210905231135.GG13220@brightrain.aerifal.cx> References: <2R2YR9WZKQ66Q.2ITJ44PGSICVN@8pit.net> <20210905173949.GE3090@voyager> <38ZW90QHEA9XD.3GB2I1P1ZLKDB@8pit.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <38ZW90QHEA9XD.3GB2I1P1ZLKDB@8pit.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] tzset() cannot handle arbitrary inputs On Sun, Sep 05, 2021 at 11:26:08PM +0200, Sören Tempel wrote: > Markus Wichmann wrote: > > Hi all, > > Hi, > > > The user setting TZ is also the one getting the crashes. The > > assumption is less that the input is always valid, but more that if it > > is invalid, the user will only be hacking themselves. > > This is only true under the assumption that $TZ itself is never set to a > value derived from an untrusted source. See the aforementioned calcurse > code for example where this assumption does not hold. If you search > GitHub or use codesearch.debian.net you will find plenty additional > examples where people "abuse" $TZ to query information about zonefiles > by name. Please also note that these spatial memory safety violations > are UB and thus might or might not lead to a crash. There are all sorts of reasons this is a really bad idea, especially if no filtering on the accepted names is performed. For instance, TZ strings taken from malicious data files could cause device files with side effects to be opened (including acquisition of a controlling tty), or coule potentially leak private data. If applications are doing this, they really should be ensuring that the string fits a reasonably "safe" form -- for example, not starting with ./ or / and not containing .. components, or even more restrictive like just /[[:alnum:]]+(/[[:alnum:]]+)?/ I think we could and should do some basic things on the musl side to ensure at least memory safety (bounding all accesses within the mapped region) but as long as we're using mmap on systems that lack MAP_COPY, that's about the limit of what can be done. And I want to approach this topic with some care not to give the impression that, after changes are made, it will be "safe" to use untrusted zone files. Rich