Skip to content
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

Host-built sample challenge not guaranteed to work in challenge container #384

Open
gkelly opened this issue Aug 20, 2022 · 3 comments
Open

Comments

@gkelly
Copy link
Contributor

gkelly commented Aug 20, 2022

In the local testing walkthrough there's an instruction to build the challenge binary using the host toolchain:

make -C challenge

However, my Ubuntu 22.04 host builds a binary with a different glibc version requirement and this results in the challenge not running in the container:

[I][2022-08-20T20:44:18+0000] Executing '/home/user/chal' for '[STANDALONE MODE]'
/home/user/chal: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /home/user/chal)
gkelly added a commit to gkelly/kctf that referenced this issue Aug 21, 2022
Because the challenge runtime container and host build environment might
diverge, link the sample challenge statically to give a higher
likelihood that it can still run inside the challenge container.
sroettger pushed a commit that referenced this issue Aug 22, 2022
Because the challenge runtime container and host build environment might
diverge, link the sample challenge statically to give a higher
likelihood that it can still run inside the challenge container.
@sroettger
Copy link
Collaborator

Yeah, for the GoogleCTF we solved this by building all challenge binaries in a Dockerfile themselves:
https://github.com/google/google-ctf/blob/master/2021/quals/kctf/challenge-templates/pwn/challenge/Makefile

We should probably upstream that change. The original motivation for it was to allow anyone to rebuild all challenge binaries without depending on certain packages on the host.

@sroettger
Copy link
Collaborator

@sirdarckcat wdyt?

@sirdarckcat
Copy link
Member

I feel it's a little bit weird it's in a Makefile though (I would expect the Makefile to be called within the Dockerfile, not the other way around).

We had some ideas about making all attachments "scratch" docker images iirc? Although I don't remember how we were planning to reference them

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants