Preamble

Author: Emmanuel Odeke, Orijtech Inc, Cybersecurity and Software divisions

Versioning updates

Version Date Author Comments
v1.0.0 January 20th 2025 Emmanuel Odeke Initial draft
v1.0.5 February 22nd 2025 Emmanuel Odeke Findings from prototypes and experiments along with the laborious results of manually trying to fuzz a specific target
v1.0.8 March 9th 2025 Emmanuel Odeke Fleshed out details and improvements

Table of contents

Executive brief/summary

A platform that automates and scales the very laborious and specialized process of fuzzing, triggered by updates or periodic refreshing with the source code repository for patches and improvements and reporting failures to the end consumers who can then examine failures, make updates and the system can track changes, but also code bissections can be performed so as to determine when a fix for a change occured or if a failure persists.

Aurelius currently is intended for the Go programming language but fuzzing other languages and systems is entirely possible by a retrofit.

Why is a trustless continuous fuzzing platform necessary?

Running fuzzers is an attention intensive process that is necessary to fortify the security of software; humans can think of test cases but the sheer state explosion and complexity of modern software makes it impossible for a human to reasonably write as many valid test cases. When fuzzers are written, they need to run, most fuzzers perform coverage based mutations using a genetic algorithm that is resource incentive and requires you to give up use of your computer. The longer that mutations occur the better the coverage and the better the security. If developers have to manually run fuzzers and wait for hours, keep their computers awake, check back on updates etc, that means that bugs remain undiscovered due to the sheer inconvenience and continuous attention required which allows for negligence.

Many users might not want to use conventional and public fuzzing platforms due to mistrust of large companies that make money from selling data and have been accused of various collusions in recent privacy scandals and revelations.

By harnessing the power of computers to perform repetitive tasks, we implement a platform to schedule and run fuzzers with a pool of machines manned by a coordinator and on any failures, inform the designated security teams through a mailing list or their desired form of communication.

Aurelius is a solution to the intensely laborious process and wastage of potential by developers: a philosophical atrophying of talent and valuable time, the thesis to harnessing division of labour! We take the mundane laborious task of running fuzzing and with all the heavy lifting, you can rest assured that your security will be fortified with Aurelius. Aurelius can be deployed entirely within your infrastructure, all managed within your organization without anyone else gaining access to your systems, not even the authors knowing what you use it for.

We liken this democratization to Prometheus stealing fire from the Gods on Mount Olympus, to give to the humans!

prometheusStealingFireFromTheGods.jpg

Motivations and experience report

We’ve been helping out the Gno language march closer to their mainnet launch and this process has entailed a very laborious process of writing a whole lot of fuzzers and running them locally, as well as on our cloud virtual machines but given that fuzzing can even take 6+ days without finding a failure yet you need to continuously monitor for failures and then report them, even the promises of bounties cannot come close to the amount of time that we’ve spent for which we spend 4+ hours almost every single day finding problems, fuzzing, checking against the accepted structure, validate failures, re-run, monitor etc for example per https://github.com/gnolang/gno/issues?q=is%3Aissue state%3Aclosed author%3Aodeke-em Our labour on the fuzzing effort has yield some good issues and some of them severe security issues and particularly our fuzzer https://github.com/gnolang/gno/pull/3715 explores the differences between Gno and Go and those have been very instrumental in getting Gno stable and with our work, we are able to make our focus be on writing code rather than the 90% effort of keeping the fuzzer running while unable to use our machines. This is exactly exhibited by the screenshot of an email notification sent to me this morning by our systems