Avoid using unsafe realpath

@pitrou

BPO	1298813
Nosy	@pitrou, @vstinner, @tiran, @devdanzin, @matejcik
Files	python-canonicalize.patch: Patch to make Python use canonicalize_file_name if available

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2005-09-22.14:54:06.000>
labels = ['type-security', 'interpreter-core']
title = 'sysmodule.c: realpath() is unsafe'
updated_at = <Date 2016-09-08.23:49:28.131>
user = 'https://bugs.python.org/misa'

bugs.python.org fields:

activity = <Date 2016-09-08.23:49:28.131>
actor = 'christian.heimes'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2005-09-22.14:54:06.000>
creator = 'misa'
dependencies = []
files = ['6791']
hgrepos = []
issue_num = 1298813
keywords = ['patch']
message_count = 13.0
messages = ['48753', '48754', '48755', '48756', '48757', '86585', '87090', '87446', '114627', '142586', '142664', '142927', '275217']
nosy_count = 10.0
nosy_names = ['misa', 'spektrum', 'pitrou', 'vstinner', 'christian.heimes', 'ajaksu2', 'pjones', 'matejcik', 'Arfrever', 'mibanescu']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'pending'
superseder = None
type = 'security'
url = 'https://bugs.python.org/issue1298813'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3', 'Python 3.4']

Linked PRs

gh-42400: Fix buffer overflow in _Py_wrealpath for long paths #141529

realpath() will dereference all symlinks and resolve
references to /./ and /../ (and so on). realpath
accepts a source buffer and a destination buffer to
copy the resolved path into. On certain systems
PATH_MAX can be of arbitrary size, while the buffer
passed in would be of a limiited size.

There is no way to specify how long your "resolved"
buffer is, therefore it is possible for one to overflow it.

According to the man page:

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.

glibc has certain extensions to avoid the buffer
overflow. One option is to use
canonicalize_file_name(), another is to specify a NULL
as the second argument to realpath() (which essentially
makes it behave like canonicalize_file_name(). Relevant
documentation:

info libc
http://www.delorie.com/gnu/docs/glibc/libc_279.html

Attached is a patch to use canonicalize_file_name if
available.

Logged In: YES
user_id=631694

there are two bugs in the patch: one is explained on
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169046
the other one is that with this patch, the value of n
(length to be copied) stays zero all the time, so no copy
occurs and various things happen.

i have a patch, but don't know how to attach it - should i
mail it to you?

Logged In: YES
user_id=27350

There are actually a few more, very subtle problems with the
new patch as well. I'll get misa to update a patch once
I've worked through them.

In general, regarding Red Hat's bz# 169046, there's no
reason to do readlink() or realpath() if you've got
canonicalize_file_name; it should provide both sets of
functionality just fine.

Logged In: YES
user_id=27350

... but I see you meant the condition different than I
parsed your explanation. Anyway, I'll get misa to upload a
new patch once I've figured out what's going wrong entirely.

Logged In: YES
user_id=631694

if I may kindly remind you that this is a good time to
implement some kind of a patch ;e) now that python 2.5 is
nearing completion, and there's even a security advisory
(http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-1542)...

I have a working patch, applicable against 2.5c1, at
http://users.suse.cz/~jmatejek/python-2.4.2-canonicalize2.patch
(note the version number - the affected function didn't
change since 2.4.2)

See http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-1542

The patch introduces a memory leak, canonicalize_file_name() returns a
new allocated string which is not freed later.

Disclaimer: this bug is more than 3 years old, I don't remember all the
details.

Victor, solely reading the patch I see:

+#ifdef HAVE_CANONICALIZE_FILE_NAME
+		free(argv0);
+#endif /* HAVE_CANONICALIZE_FILE_NAME */

so argv0 (the string where the results of canonicalize_file_name() is
stored) should be freed.

Is there another branch that does not hit this code, that would create
the memory leak?

Surely this security issue should be addressed?

The latest POSIX versions (*) allow NULL to be passed for the target memory area, meaning that realpath() will allocate as much memory as necessary by itself. This essentially does the same thing as canonicalize_file_name(), but in a standard way rather than by relying on a GNU extension.

I suppose that possibility could be checked at configure time.

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

It's a real shame the original patch was not applied before py3k was branched, the code is now different.

Antoine, my autoconf knowledge is limited, I don't know how you'd test for realpath accepting a NULL argument (and doing the right thing) at compile time.

My involvement with this bug is fairly limited at this point, I would like to see it fixed, but having seen no movement on it for almost 6 years now, maybe it's not as critical as I thought it was.

We do still use realpath(3), now inside the _Py_wrealpath function in fileutils.c, so I think the original issue still applies.

Ping. Is this issue still relevant?

_Py_wrealpath() calls realpath().

getpath_realpath() in Modules/getpath.c (if HAVE_READLINK macro is not defined) and _PyPathConfig_ComputeSysPath0() in Python/pathconfig.c still call _Py_wrealpath().

So yeah, this issue is still relevant.

By the way, "Ping. Is this issue still relevant?" doesn't bring much value to the issue. You should investigate by yourself to check if an issue is still relevant.

By the way, "Ping. Is this issue still relevant?" doesn't bring much value to the issue. You should investigate by yourself to check if an issue is still relevant.

Thanks for the note. I’ll avoid noise in the future and only comment when I have something concrete.
I checked the current main branch, and the issue is still present. I’m preparing a PR with a fix.

pythongh-42400: Fix buffer overflow in _Py_wrealpath for long paths

gh-42400: Fix buffer overflow in _Py_wrealpath() for very long paths (#…

pythongh-42400: Fix buffer overflow in _Py_wrealpath() for very long …

Navigation Menu

Repository navigation

Avoid using unsafe `realpath` #42400

Linked PRs

2 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Avoid using unsafe realpath #42400

Description

Linked PRs

Activity

misa commented on Sep 22, 2005

spektrum commented on Sep 26, 2005

pjones commented on Sep 26, 2005

pjones commented on Sep 26, 2005

spektrum commented on Sep 1, 2006

devdanzin commented on Apr 26, 2009

vstinner commented on May 4, 2009

mibanescu commented on May 8, 2009

BreamoreBoy commented on Aug 22, 2010

pitrou commented on Aug 20, 2011

mibanescu commented on Aug 22, 2011

2 remaining items

JelleZijlstra commented on Oct 5, 2022

ashm-dev commented on Nov 13, 2025

vstinner commented on Nov 13, 2025

ashm-dev commented on Nov 13, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Avoid using unsafe `realpath` #42400