On Thu 2020-12-24 09:37:46 -0400, Joey Hess wrote: > Daniel Kahn Gillmor wrote: >> thanks for the diagnosis, Joey! this looks like a change between the >> ctypes module between python 3.8 and 3.9. I'll fix it in python3-xdo, >> and hopefully that will resolve your problem. > > Independent of getting this fixed, I think it's concerning that ctypes > falls back to looking for library files in cwd when a shared library is > unavailable. That has potential to be part of a security exploit chain, > although I have not dug deeply enough to know if it's exploitable.
I agree with you that this sounds sketchy, but i think the functionality
you're concerned about is in the find_library function:
https://docs.python.org/3/library/ctypes.html#finding-shared-libraries
which says:
>>> On Linux, find_library() tries to run external programs
>>> (/sbin/ldconfig, gcc, objdump and ld) to find the library file. It
>>> returns the filename of the library file.
Not sure what to make of this, but if you end up reporting it upstream
i'd be interested to see a pointer.
I didn't see any report that is obviously related to security and
find_library.
https://bugs.python.org/issue?%40columns=id%2Cactivity%2Ctitle%2Ccreator%2Cassignee%2Cstatus%2Ctype&%40sort=-activity&%40filter=status&%40action=searchid&ignore=file%3Acontent&%40search_text=find_library+security&submit=search&status=-1%2C1%2C2%2C3
for the python xdo module bindings for libxdo, i suppose we could also
avoid calling find_library("xdo") on linux, since it won't work against
SONAMEs other than 3. that is, we could maybe just hardcode
"libxdo.so.3" as the library name, assuming that these bindings are only
used on GNU/Linux systems. I don't know whether i'd be as comfortable
hardcoding "libc.so.6" though.
--dkg
signature.asc
Description: PGP signature
_______________________________________________ Python-modules-team mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team
