[Python-Dev] unintentional and unsafe use of realpath()

[Peter Jones]

On Mon, 2005-09-12 at 17:23 +1200, Greg Ewing wrote:
> Peter Jones wrote:
> 
> > Another problem (which I have not fixed) is that when realpath() is
> > used, in some cases MAXPATHLEN is smaller than the system's
> > PATH_MAX/pathconf(path, _PC_PATH_MAX).
> 
> The linux man page for realpath() has this at the bottom:
> 
> BUGS
>         Never  use this function. It is broken by design since it is impossible
>         to determine a suitable size for the output buffer.  According to POSIX
>         a  buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined
>         constant, and may have to be obtained  using  pathconf().   And  asking
>         pathconf() does not really help, since on the one hand POSIX warns that
>         the result of pathconf() may be huge and unsuitable for mallocing  mem-
>         ory.  And  on  the  other hand pathconf() may return -1 to signify that
>         PATH_MAX is not bounded.
> 
> So maybe it shouldn't be using realpath() at all?

Well, the intent is clearly that OSes that have a better option, we
shouldn't be using it.

But that wasn't really my second point.  When use of realpath is
unavoidable, it is vitally important that MAXPATHLEN is set to the same
value that realpath() got when it was built.  If it's any smaller, it's
a straightforward overflow, with something like $SYSTEM_MAXPATHLEN -
$PYTHON_MAXPATHLEN of space to write nasty bits into.  At least on one
box I looked at, system's was 4096 and python wound up doing the
fallback of 256 (I'm not entirely sure why) so that's 3768 bytes of
stack potentially overwritten.

In this case, it's not realistically exploitable, because it means a
user has to trick root into running "python foo" where foo is a symlink
that's built terrifyingly weirdly.  So since the user is supplying the
symlink, there are much more trivial attacks.  But I haven't checked all
the uses of realpath in python, some of them could be dangerous.

-- 
  Peter