Bug discovery diaries: uncovering sngrep overflow issues with blackbox fuzzing

Table of contents

  1. Executive summary (TL;DR)
  2. sngrep crash during the live OpenSIPit event
  3. Setup a test environment to fuzz sngrep
  4. Manual code review and actual testing
  5. Reporting the issues upstream
  6. Conclusion

Executive summary (TL;DR)

During OpenSIPIt, we crashed by mistake while briefly fuzzing OpenSIPS. Later on we setup a docker environment to reproduce the issue, identified the actual bugs and reported them upstream. If you want to learn the simple steps to do this, you actually have to read the rest of the post :-)

sngrep crash during the live OpenSIPit event

Last year we participated in OpenSIPIt’s interoperability testing event which was held between the 14th and 15th of September 2020. Amongst the topics discussed were RFC8760 (SHA-digest), STIR/SHAKEN and RFC8599 (push notifications). Whilst trying to stick to the agenda, we couldn’t resist the temptation to fuzz test the servers that were available to us. An instance of OpenSIPS was tested for a very short period of time, however, we did not observe any server crashes.

But we did notice a crash somewhere else. Traffic was being monitored by the handy (and invaluable) little tool sngrep, which, during these tests was exiting abnormally at random times. One of these moments can also be seen on Youtube.

OpenSIPIt, online event for testing SIP implementations
OpenSIPIt, online event for testing SIP implementations

These random crashes prompted us to perform further fuzz testing against using SIPVicious PRO, which now includes black box fuzzing capabilities specific to SIP and VOIP systems.

Setup a test environment to fuzz sngrep

Since is relatively easy to build and setup, we thought that it could be used as the perfect example of how we build and test systems in isolation, for the discovery of potential security issues. By showing our methodologies, in this case, black box fuzzing, we aim to inspire system implementers, developers and vendors to include offensive techniques in their testing.

In this particular case, we commenced by creating a Docker image containing a compiled version of . The binary was compiled using the flag , which enables debugging, so that it was easier to analyze any crashes that occur. This can also allow testers to add breakpoints and step through the code of a target application with debugging tools such as .

The Docker image was created using:

And then a container was spun up by running:

Once the container was up and running, it was time for some SIPVicious PRO fun using its sip fuzzing tool.

The following command executed for a few seconds, and resulted in the first crash!

The following is one of the many backtraces that were gathered from :

Manual code review and actual testing

By looking at the code of the function sip_parse_msg_media, we noticed that there were two instances where the function was being used to read strings into fixed sized arrays. The first issue occurred while populating the variable .

The second issue occurred when populating the member of the structure instance , which is an array of characters of fixed size 16.

In order to confirm these issues, we used SIPVicious PRO’s repeater tool. The following SIPVicious template was saved to :

And then SIPVicious PRO was executed against the docker container:

Similarly, the second issue was confirmed by setting the template to:

And running SIPVicious PRO again:

Reporting the issues upstream

Once the issues were consistently reproduced, we contacted irontec via github:

Irontec started working on these issues immediately and officially released a fix in version 1.4.8.


This concludes the explanation of how we perform black box fuzzing against a target. This simple, yet effective technique has helped us uncover multiple bugs in both open source and proprietary, closed source solutions, which we usually attack during penetration tests.

Summary of our testing methodology:

  1. Use Docker to build and run the target application in isolation (optional)
  2. Compile the target application with debug information and no optimization (optional)
  3. Fuzz the application using tools such as SIPVicious PRO
  4. When a crash occurs, retrieve the backtrace from
  5. Identify the code causing the crash
  6. Produce a script which consistently reproduces the bug
  7. Report!

Originally published at https://www.rtcsec.com.

Sandro Gauci leads operations and research at Enable Security. To the real-time communications/VoIP world he is known as the original developer of SIPVicious.