overflow() at stdlib.h

overflow() at stdlib.h

[m0rtal f!w]

[-- Attachment #1: Type: text/plain, Size: 781 bytes --]

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)

But over here uv__fs_pathmax_size() nor pathconf(path, _PC_PATH_MAX) is
used.

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

[-- Attachment #2: Type: text/html, Size: 916 bytes --]

Re: overflow() at stdlib.h

[Szabolcs Nagy]

* 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 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

Re: overflow() at stdlib.h

[Dhiraj]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

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 <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 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
>

[-- Attachment #2: Type: text/html, Size: 2590 bytes --]

Re: overflow() at stdlib.h

[Szabolcs Nagy]

* Dhiraj <mortalfw@gmail.com> [2018-07-12 21:21:38 +0530]:
> 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.
> 

i don't understand what is the issue.

> 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.
> 

why +1?

PATH_MAX is the maximum amount of bytes realpath may write (i.e. it includes
the terminating nul byte).

> 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 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
> >

Re: overflow() at stdlib.h

[Dhiraj]

[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]

Reference: http://man7.org/linux/man-pages/man3/realpath.3.html

or as you suggested it might be a portability bug.




/D

On Thu 12 Jul, 2018 10:00 pm Szabolcs Nagy, <nsz@port70.net> wrote:

> * Dhiraj <mortalfw@gmail.com> [2018-07-12 21:21:38 +0530]:
> > 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.
> >
>
> i don't understand what is the issue.
>
> > 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.
> >
>
> why +1?
>
> PATH_MAX is the maximum amount of bytes realpath may write (i.e. it
> includes
> the terminating nul byte).
>
> > 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
> 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
> > >
>

[-- Attachment #2: Type: text/html, Size: 3686 bytes --]

Re: overflow() at stdlib.h

[Rich Felker]

On Thu, Jul 12, 2018 at 07:55:56PM +0530, m0rtal f!w wrote:
> 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)

There is no provision in the specification of realpath for use of
pathconf or other facilities for determining a maximum buffer size;
the resolved_name buffer argument must either point to an array of at
least PATH_MAX size, or must be a null pointer, in which case realpath
will allocate storage. Only the latter option when the implementation
does not define PATH_MAX, but musl always defines PATH_MAX.

> But over here uv__fs_pathmax_size() nor pathconf(path, _PC_PATH_MAX) is
> used.

I don't understand what you mean by "is used" here. The only file you
cited is header declarations only, no code, and the declaration is
exactly the only thing it's permitted to be (the one mandated by the
standard).

> 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.

If an application is not passing an adequately-sized (note: this means
PATH_MAX, not anything else!) buffer, that is an application bug and
the application has undefined behavior.

Rich