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