Patches item #1298813, was opened at 2005-09-22 16:54
Message generated for change (Comment added) made by spektrum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298813&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai Ibanescu (misa)
Assigned to: Nobody/Anonymous (nobody)
Summary: sysmodule.c: realpath() is unsafe
Initial Comment:
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.
----------------------------------------------------------------------
Comment By: Matejcik (spektrum)
Date: 2006-09-01 16:12
Message:
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)
----------------------------------------------------------------------
Comment By: Peter Jones (pjones)
Date: 2005-09-26 21:14
Message:
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.
----------------------------------------------------------------------
Comment By: Peter Jones (pjones)
Date: 2005-09-26 21:11
Message:
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.
----------------------------------------------------------------------
Comment By: Matejcik (spektrum)
Date: 2005-09-26 15:21
Message:
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?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1298813&group_id=5470
_______________________________________________
Patches mailing list
Patches@python.org
http://mail.python.org/mailman/listinfo/patches
