-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add --libc libc.so
argument to pwn template
#2212
Conversation
Shells out to the `patchelf` tool to patch the ELF's RUNPATH. This lets the dynamic loader look for needed shared libraries in the given path first before the system libraries when running the binary.
Shells out to the `patchelf` tool to patch the ELF's PT_INTERP segment. This allows to change the ld.so used when running the binary.
A helper function to patch the ELF such that it uses the dynamic loader and other libraries in the given folder.
Download the matching libraries for the given libc binary and cache them in a local directory using `libcdb.download_libraries()`. The libraries are looked up using libc.rip and fetched from the official package repositories if available. Only .deb and .pkg.tar.* packages are currently supported (Debian/Ubuntu, Arch).
This generates code into the template which allows you to run the binary using the given libc. The foreign libc is used by default, but you can choose to run the binary against your system's local libc using the `LOCAL_LIBC` command line argument when executing the exploit script.
One useful thought I have is enumerating all libc builds on the host system in some useful order before downloading them from the net (possibly the default system libc and libc from every running docker container/image; it might surely be annoying if it requires sudo, but if containerd is accessible through The installation instructions for patchelf should mention installing from distro IMO; many pwntools users are not proficient with their own system. I think I will craft a PR adding more such user-friendly messages soon™. I also tend to use |
Looking for all available local libcs sounds good. Maybe your system libc is the one you're trying to run as. I've seen that bug as well a few times, but not on Ubuntu 22.04 anymore. I think setting the sysroot helped, but not sure. |
Would you add another dependency to access docker or shell out to the commandline tools? |
Honestly, however nice, I can live without From other things, I just found I would also prefer to hide py2 hacks inside |
I agree, harvesting docker images requires more thought. I wouldn't want to have to run my exploit as root e.g. The pyliblzma package appears to be broken 😞
We'll have to keep using the |
I wonder what container you are using for that; it worked for me on python:2.7-buster. Also, we should drop py2 as soon as jython3/ironpython3 becomes official, because it is a constant pain.
Email z poniedziałku 10 lipca 2023 od peace-makera:
… I agree, harvesting docker images requires more thought. I wouldn't want to have to run my exploit as root e.g.
The pyliblzma package appears to be broken 😞
```
***@***.***:~$ sudo apt install liblzma-dev
***@***.***:~$ pip2 install pyliblzma
***@***.***:~$ python2.7
Python 2.7.18 (default, Jul 1 2022, 10:30:50)
[GCC 11.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lzma
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: /home/pwntools/.local/lib/python2.7/site-packages/lzma.so: undefined symbol: lzma_alone_encoder
```
We'll have to keep using the `xz` utility then.
--
Reply to this email directly or view it on GitHub:
#2212 (comment)
You are receiving this because you commented.
Message ID: ***@***.***
--
Wysłane z mojego urządzenia Sailfish
|
I'm using our base Dockerfile |
Co-authored-by: Arusekk <[email protected]>
This mimics the way io12/pwninit obtains the ld.so. If the download from libc.rip fails, try launchpad.net.
The pylint warning is a false-positive, since |
Co-authored-by: Arusekk <[email protected]>
This adds a
--libc <path/to/libc.so>
option to thepwn template
pwnup template command which generates alibc
variable to use in the script pointing to anELF
object of the passed libc.In addition to this, it adds code to run the target binary using the provided libc inspired by pwninit. This is done in 3 steps:
The generated template code looks like this:
This is a bit bulky - suggestions welcome!
The default behavior is to use the specified libc instead of the system wide one when running the script locally. You can pass the
LOCAL_LIBC
argument to start the process with the system libc. The libraries are downloaded on first run of the exploit script and cached for subsequent executions. That way exploits stay portable given the challenge binary and initial libc.The current implementation only supports
.deb
and.pkg.tar.*
packages and could be improved to search launchpad.net like pwninit does. It might be useful to pass a libc's build id to--libc
and save it in the script instead of requiring an initial libc.so binary as well? That can be added later though.Closes #2076
Supercedes #2082