Sheet Bonus

General Information

All solutions must be Python 3 scripts if not stated otherwise. If you are new to Python 3, have a look online, there are many good resources to get started such as this intro course, this advanced course, this blog post, and this slide deck.

Please keep in mind that you should:

  • read the task description carefully

  • push all your changes to the GitLab repository (main branch) before the deadline. Make also sure that the file permissions are set correctly! If you are new to Git check out this site!

  • Make sure that your solution (also) runs in the CI environment (and not just your local machine); this also means that you must install all additional packages yourself from within the solution script (see our blog post for details how to do that).

  • Check the CI-Pipeline status and output for any errors. If the Pipeline is green and the output looks right, your solution should be correct.

  • Make sure that the solution is an executable Python 3 script named solution (chmod +x ./solution) with a working shebang line at the top (i.e. #!/usr/bin/env python3) so that it can be executed like this: ./solution (do not name your script solution.py, Solution, solution.sh, … – just solution)

  • The final solution string, and only that, must be written to stdout and could be a number, a string, a string with the format FLAG{some letters and digits here}, depending on the specific task.

  • Describe what you are doing using detailed comments for all your solution scripts! For example, use Docstrings (link) or inline comments:

    1
2
3
4
5
6
7
8

    def check_input_length(input_string):
    """
    The input string must have a length greater than 42 and must also be even.
    """
    length = len(input_string)

    # the final check happens here
    return (length > 42) and (length % 2 == 0)

    This helps us to find out if you really understood the task and you are not just brute-forcing some solutions. Please do not leave any commented code (i.e., code that is not needed to solve the task) in your solution files!

  • Make sure that your solution executes within 10 seconds (this is a hard timeout on our server).

  • Violating any of the points above might lead to reduced final points for the specific task!

The deadline for this sheet is 2024-06-30 22:00:00 UTC

Task 1337 – Rusty Interactive LLM (8 Points, individual Task)

We finally developed our first, interactive version of a large language model (LLM) using the memory - safe programming language Rust. Although the market is already full of LLMs, our LLM outperforms any existing LLM in terms of speed by at least 200%. This is due to the fact that Rust is the perfect programming language that makes it impossible to create slow programs or programs with memory errors. As this is our first version, some features are still experimental.

Although the project is closed - source for now, contributions were made from several affiliates. We are aware that supply chain attacks (e.g. xz supply chain attack) are a thing! This is why we ask you to figure out whether our project has been backdoored by any of our contributors. As usual, if you find any security relevant bug, you must provide a proof of concept (PoC) exploit that actually triggers the bug within the execution environment defined by the docker container. The PoC must at least provide the arbitrary command execution capability. Make the PoC read a test flag.txt file located within the same directory as the binary of the LLM.

For a starting point, an intern of an affiliate of ours, going under the tag xXRustGod42Xx, came up with an optimization technique using Rust’s special unsafe feature to speed up token processing. He even stated that this fully filters any malicious user input. Of course, the core developer team has followed the ABE lecture during their studies, which is why none of them blindly believes such claims!

NOTE: You are explicitly allowed to use any kind of tooling regarding ROP chain generation and the like. For example, you may use ropper --file rusty-rust --chain execve! However, you must still exploit bugs within the application :)

Output format:

1
2

$ ./solution
FLAG{XYZ}

General Hints

  • Try to explore the program by providing various inputs. Look through the menus and think about how you would implement such an application. Especially, what (custom) data structure would you use?
  • Applications often operate based on an internal application state. Can you determine any menus requesting user input that could affect such a state?
  • Backdoors are tricky and often complex. You need to exploit two bugs (plus info leak). The first bug enables the second bug.
  • Read the above task description carefully!

Rust - Specific Hints

  • Use rustfilt to demangle rust symbols. Can you find a pattern for symbols that reference application - specific functions?
  • Rust allows to build binaries in debug and release mode. There are various differences, among which are how integers are managed! This binary is built in release mode (without any optimizations).
  • When corrupting memory, try to set pointers you cannot avoid and that do not contribute to exploitation to NULL. Heuristically speaking, often there is special logic for NULL pointers that may prevent SEGFAULTS and the like! You can use cyclic patterns to find out what parts of your payload are interpreted as pointers.
  • Rust binaries are big, which in turn means there are plenty of gadgets :) I.e. “stay” inside the Rust binary. No need to get a hand on libc.so addresses or the like.
  • Do not try to reverse engineer the entire binary! Try to work superficial first to identify what functions are mapped to what functionality. You do not want to start analysing any functional programming features!!!
4 Jun 2024