Skip to content

Latest commit

 

History

History
123 lines (98 loc) · 3.39 KB

File metadata and controls

123 lines (98 loc) · 3.39 KB

dot -Tpng doc/airlock_state.dot -o doc/airlock_state.png

-exec p (enum SDNDeviceType)devices[0].device_type

tasks.json:

{
    "tasks": [
        {
            "type": "shell",
            "label": "Debug Build",
            "command": "make clean && make debug",
            "problemMatcher": [
                "$gcc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
        }
    ],
    "version": "2.0.0"
}

launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/bin/airlock_ctrl",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "preLaunchTask": "Debug Build",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                {
                    "description": "Set Disassembly Flavor to Intel",
                    "text": "-gdb-set disassembly-flavor intel",
                    "ignoreFailures": true
                }
            ]
        }

    ]
}

make && ./bin/airlock_ctrl | grep -v DEBUG

pwndbg -x minimal_example/analysis.gdbinit bin/airlock_ctrl

Sequence of events:

  1. Maintenance puts controller into debug mode.
  2. Possibly additional maintenance?
  3. ??? Updates the in memory max buffer size to be big enough to hold code for payload making it inconsistent with the actual buffer size. ???. This causes the data after the loaded max buffer size to smash the stack.
    1. This could be done as code bug where the value can be loaded without reallocating buffer
    2. Bug where buffer is reallocated but there's a mistake
    3. Could be done through GDB modifying value (this might be hard to leave clue for)
  4. N users use door normally.
  5. Malicious payload is loaded by unwitting user
  6. When the user X tries to checkout the spacesuit, it instead runs the payload causing the room to vent and
env -i setarch $(uname -m) -R /home/jdiamond/src/fatal_core_dump/bin/airlock_ctrl
coredumpctl -o core.dump dump bin/airlock_ctrl
pwndbg bin/airlock_ctrl  core.dump -x minimal_example/analysis.gdbinit
x/20i $pc - 64
x/32s $pc - 8

info symbol  0x555555555e7e
info symbol  0x555555555269
info frame
sqlite3 :memory:
sqlite> .read site/access_log.sql
docker build -f Dockerfile_build -t core_dump_build .
docker run --rm --privileged -v "$PWD":/fatal_core_dump core_dump_build sh ./scripts/generate_hack.sh

# docker run --rm --privileged -it -v "$PWD":/fatal_core_dump -w /fatal_core_dump core_dump_build bash

docker run --rm -it --privileged -v "$PWD":/fatal_core_dump core_dump_build ./scripts/trigger_crash.sh

sudo chown -R $USER:$USER bin
docker build -f Dockerfile_debug -t core_dump_debug .

docker run --rm -p 5000:5000 -it core_dump_debug bash



docker run --rm core_dump_debug pwndbg --core=core.dump airlock_ctrl

docker run --rm -p 5000:5000 core_dump_debug gdbgui -r --gdb-cmd "/usr/bin/gdb-multiarch --core=core.dump airlock_ctrl"
disassemble $pc-64,$pc+16
info symbol 0x55555555539c