From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13026 Path: news.gmane.org!.POSTED!not-for-mail From: Dhiraj Newsgroups: gmane.linux.lib.musl.general Subject: Re: overflow() at stdlib.h Date: Thu, 12 Jul 2018 21:21:38 +0530 Message-ID: References: <20180712154209.GJ4418@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000b051a00570cf56c8" X-Trace: blaine.gmane.org 1531410587 31924 195.159.176.226 (12 Jul 2018 15:49:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Jul 2018 15:49:47 +0000 (UTC) To: musl@lists.openwall.com, "m0rtal f!w" Original-X-From: musl-return-13042-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 12 17:49:43 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fddqg-0008Ds-J4 for gllmg-musl@m.gmane.org; Thu, 12 Jul 2018 17:49:42 +0200 Original-Received: (qmail 16029 invoked by uid 550); 12 Jul 2018 15:51:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 16011 invoked from network); 12 Jul 2018 15:51:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qNQhuoMRvbACgWVMvSAEBpXVFsxZQLK7teL3DVQOULU=; b=Ezu1kW1+ejbtWQlxPnAQtHR1sjRmkv0mk2pYV+jHRs5IOoxHMGPDuxT33gLAAcg442 Glz+NM0Vk9YOiukS2AdaAMXm2r39tXmdIiBM/o/k81hO3sVjElubqzSxocF/Mdp+uIEA TgTl5Xsg44X9brhnSZgBVFtv5fTT7fUYSG7LwzXIfUoZpSYISRnpZwj0I2ScUehzRx96 HUTzY74MlhZUrxKdn6ZDCBUIi5PR26PTmLv/pG/fcjF8ZQxbD8EFTBUnVZvLv8TEt6nz hBLgqlwdgrS5Tl/ng4HqQgwPfvx/kbLrewReiqeTNWTLQmhQHIndC1hFs4rwaX5NJCv/ xFhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qNQhuoMRvbACgWVMvSAEBpXVFsxZQLK7teL3DVQOULU=; b=LYBJcaGb//6/EiIzk1DbTcj0un7YREZCghPXj//cNQ5fBuatoM8haqciph9gPbjHPW +/Wt50bKF0ZbM0maShKudJNLoL9nlB3wYNHyEPMmj9Y5AsdgwiwnUEklagJM1WGyLfKk cx9RqtmHvmTuJ/aCYSYEZvYx0l6eEGfle4d1zz0V4+VXoz7ZbnqLvq6R2cGWQxvCZrvS EgDNd+ftXd4YH3H8EOfqBUelGjtqHUjgKq2N98reuaClQWEG4cf0CrYL48z2bTSZ09ey KH2Z3WTkrQ7ElJzB7GF0oNLMoZ4vNdfWXbR1owhynri0mhUVSMgmx/7grKAlGV+wl8Bp 1vlw== X-Gm-Message-State: AOUpUlEkGN01UYPTWrTOIJmVNL+Mc0jjCdaWBMfECs0JSOb5zNsnKJn9 w7OoDQa3CpX2+f/C34sOuD58HAnDhgQKI37QUvuGttqBeVU= X-Google-Smtp-Source: AAOMgpc1snR9+B2k2UPi/0iqJ3LaRNThRGD2j2mxOAtnn/IrlHml/fkpircFF1xwfpDVNKx1ds1qCaKeGj4u7XVCwTY= X-Received: by 2002:a1c:928c:: with SMTP id u134-v6mr1667268wmd.106.1531410698487; Thu, 12 Jul 2018 08:51:38 -0700 (PDT) In-Reply-To: <20180712154209.GJ4418@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:13026 Archived-At: --000000000000b051a00570cf56c8 Content-Type: text/plain; charset="UTF-8" Thanks Szabolcs for taking look into this, > But over here uv__fs_pathmax_size() nor pathconf(path, _PC_PATH_MAX) is > used. > > where? In stdlib.h file. However, we can allocate a "PATH_MAX + 1" or POSIX.1-2008 would allow us to pass in a NULL poiter and have realpath allocating enough memory. Regards Dhiraj On Thu, Jul 12, 2018 at 9:12 PM, Szabolcs Nagy wrote: > * m0rtal f!w [2018-07-12 19:55:56 +0530]: > > Team, > > > > File: stdlib.h#L:113 > > > > i.e > > char *realpath (const char *__restrict, char *__restrict); > > > > According to the documentation of realpath() the output buffer needs to > be > > at least of size PATH_MAX specifying output buffers large enough to > handle > > the maximum-size possible result from path manipulation functions. (In > that > > instance, buf's size comes from uv__fs_pathmax_size(). That function > > attempts to use pathconf(path, _PC_PATH_MAX) as noted in the realpath(3) > > docs) > > > > sounds like a portability bug in uv__fs_pathmax_size() > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html > > it should use PATH_MAX if defined or null pointer if not > to be portable to posix conforming targets. > > > But over here uv__fs_pathmax_size() nor pathconf(path, _PC_PATH_MAX) is > > used. > > > > where? > > > Passing an inadequately-sized output buffer to a path manipulation > function > > can result in a buffer overflow. Such functions include realpath() > > readlink() PathAppend() and others. > > > > Request team to have a look and validate. > > > > > > Thank you > --000000000000b051a00570cf56c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Szabolcs for taking look into this,
=
> But over here uv__fs_pathmax_size() nor pathc= onf(path, _PC_PATH_MAX) is
> used.
>

> where?=C2=A0

In=20 stdlib.h file.

However, we can allocate a "PA= TH_MAX + 1" or=20 POSIX.1-2008 would allow us to pass in a NULL poiter and have realpath allo= cating enough memory.



Regards
D= hiraj

On Thu, Jul 12, 2018 at 9:12 PM, Szabolcs Nagy <nsz@port70.net> wrote:
* m0rtal f!w <mortalfw@gmail.com> [2018-07-12 19:55:56 += 0530]:
> Team,
>
> File: stdlib.h#L:113
>
> i.e
> char *realpath (const char *__restrict, char *__restrict);
>
> According to the documentation of realpath() the output buffer needs t= o be
> at least of size PATH_MAX specifying output buffers large enough to ha= ndle
> the maximum-size possible result from path manipulation functions. (In= that
> instance, buf's size comes from uv__fs_pathmax_size(). That functi= on
> attempts to use pathconf(path, _PC_PATH_MAX) as noted in the realpath(= 3)
> docs)
>

sounds like a portability bug in uv__fs_pathmax_size()

http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html

it should use PATH_MAX if defined or null pointer if not
to be portable to posix conforming targets.

> But over here uv__fs_pathmax_size() nor pathconf(path, _PC_PATH_MAX) i= s
> used.
>

where?

> Passing an inadequately-sized output buffer to a path manipulation fun= ction
> can result in a buffer overflow. Such functions include realpath()
> readlink() PathAppend() and others.
>
> Request team to have a look and validate.
>
>
> Thank you

--000000000000b051a00570cf56c8--