Hacker News new | ask | show | jobs
by yamrzou 495 days ago
I tried to execute the PoC by running the following:

  git clone https://github.com/ggml-org/llama.cpp.git && cd llama.cpp
  git checkout c0d4843225eed38903ea71ef302a02fa0b27f048 # Checkout a revision prior to the exploit fix in 1d20e53c40c3cc848ba2b95f5bf7c075eeec8b19
  mkdir build-rpc && cd build-rpc
  cmake .. -DGGML_RPC=ON
  cmake --build . --config Release
  cd bin/
  ./rpc-server -p 50052
In a second terminal:

  nc -lvp 1337
Then running the exploit code in a third terminal (from llama.cpp/build-rpc/bin directory):

  pip install pwntools
  python exp.py # From https://gist.github.com/retr0reg/d13de3fde8f9d138fe1af48e59e630a9
It failed at Stage Three: Bypass boundary check via libggml and raised an EOFError. The RPC server exited with Segmentation fault. Any idea why?
1 comments

it can be both because of the unsuccessful leak / wrong `libggml-base` offset. We're building a fake `ggml_backend_buffer` table from the leaked base + offset (the hard-coded offset of `libggml-base` should be adjusted with the compiled release) However this exploitation is not actually `libggml-base` version dependent, the partial-writing space is always one byte, and you can leak the `libggml-base` version with after a successful leak if you build every release's `libggml-base`, and map the last-two-bytes with each version.

I am happy you read it and liked it; more glad you tried it yourself :D