BugHog is a powerful framework designed specifically to address the challenging task of pinpointing the exact code revisions in which a particular browser bug was introduced or fixed.
This framework has been developed as part of the "A Bug’s Life: Analyzing the Lifecycle and Mitigation Process of Content Security Policy Bugs" paper to identify Content Security Policy bug lifecycles, published at USENIX Security ’23. Since then, it has continued to evolve and has been exhibited at major cybersecurity conferences, including Black Hat USA.
Getting started 🚀
BugHog is compatible with UNIX systems running Docker, including WSL on Wind…
BugHog is a powerful framework designed specifically to address the challenging task of pinpointing the exact code revisions in which a particular browser bug was introduced or fixed.
This framework has been developed as part of the "A Bug’s Life: Analyzing the Lifecycle and Mitigation Process of Content Security Policy Bugs" paper to identify Content Security Policy bug lifecycles, published at USENIX Security ’23. Since then, it has continued to evolve and has been exhibited at major cybersecurity conferences, including Black Hat USA.
Getting started 🚀
BugHog is compatible with UNIX systems running Docker, including WSL on Windows. You will need at least 5 GB of disk space.
Follow these steps to get started:
# Clone this repository
git clone https://github.com/DistriNet/BugHog
cd BugHog
# Pull our pre-built Docker images
./scripts/pull.sh
# Start the pulled images
./scripts/start.sh
Open your web browser and navigate to http://localhost:80 to access the graphical user interface. If BugHog is started on a remote server, substitute ‘localhost’ with the appropriate IP address.
Note
Depending on your Docker configuration, you might have to use sudo ./scripts/[..].
BugHog in default configuration will spin up its own MongoDB container, which persists data in the /database folder. Configuring BugHog to use your own MongoDB and other options are explained here.
Tip
Our 30-minute tutorial will guide you on how to use BugHog to trace a real bug’s lifecycle!
To stop BugHog, simply run this in the project root:
./scripts/stop.sh
Development 🛠️
Use the following commands to build the Docker images yourself, for instance after you made changes to the source code:
# Build BugHog images
./scripts/build.sh
# Run the freshly built images
./scripts/start.sh
Note
For reference, building takes about 4 minutes on a machine with 8 CPU cores and 8 GB of RAM.
Debugging
The most convenient debugging approach is to launch an interactive Node environment. The UI can be visited at http://localhost:5173.
./scripts/node_dev.sh
For debugging the core application, consider using the VS Code dev container. You can utilize the configuration in .devcontainer for this.
Support and contact ☎️
More information on how to use BugHog can be found here.
For questions, remarks or collaboration, you can reach out to Gertjan Franken.