Fuzzing RTC @ Kamailio World 2019

Please download to get full document.

View again

of 50
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Similar Documents
Information Report
Category:

Technology

Published:

Views: 0 | Pages: 50

Extension: PDF | Download: 0

Share
Description
My talk on the excellent work Alessandro Toppi did at Meetecho on investigating the different code fuzzing options, and how it was eventually integrated in Janus for improving the robustness of the WebRTC stack (RTP, RTCP and SDP currently). It includes considerations on sharing corpora files and making this all distributed via OSS-Fuzz.
Transcript
  • 1. What The Fuzz! Or Why You Should Really Fuzz Your RTC Code Lorenzo Miniero @elminiero Kamailio World May 7th 2019,
  • 2. A fuzzy intro Lorenzo Miniero • Ph.D @ UniNA • Chairman @ Meetecho • Barber shop avoider Contacts and info • lorenzo@meetecho.com • https://twitter.com/elminiero • https://www.slideshare.net/LorenzoMiniero
  • 3. Just a few words on Meetecho • Co-founded in 2009 as an academic spin-off • University research efforts brought to the market • Completely independent from the University • Focus on real-time multimedia applications • Strong perspective on standardization and open source • Several activities • Consulting services • Commercial support and Janus licenses • Streaming of live events (IETF, ACM, etc.) • Proudly brewed in sunny Napoli(*), Italy
  • 4. ((*) You may have heard of it)
  • 5. Kudos to Alessandro Toppi for this content!
  • 6. Hot topic in Kamailio talks already! https://www.youtube.com/watch?v=bhy7-uxZGqk
  • 7. Kamailio lovers know fuzzing already https://www.youtube.com/watch?v=CuxKD5zljVI
  • 8. Why another talk on fuzzing, then? • Project Zero is a team of security analysts employed by Google • https://googleprojectzero.blogspot.com/ • Recently focused on videoconferencing applications • Focus on end-to-end, and RTP testing • Malicious endpoint generating randomized input • Built new tools required for the task • Targeted many applications, and found dangerous bugs • Apple FaceTime • WhatsApp • WebRTC (yikes!) Philipp Hancke’s wakeup call (crashing Janus of all things!) https://webrtchacks.com/lets-get-better-at-fuzzing-in-2019-heres-how/
  • 9. Why another talk on fuzzing, then? • Project Zero is a team of security analysts employed by Google • https://googleprojectzero.blogspot.com/ • Recently focused on videoconferencing applications • Focus on end-to-end, and RTP testing • Malicious endpoint generating randomized input • Built new tools required for the task • Targeted many applications, and found dangerous bugs • Apple FaceTime • WhatsApp • WebRTC (yikes!) Philipp Hancke’s wakeup call (crashing Janus of all things!) https://webrtchacks.com/lets-get-better-at-fuzzing-in-2019-heres-how/
  • 10. Why another talk on fuzzing, then? • Project Zero is a team of security analysts employed by Google • https://googleprojectzero.blogspot.com/ • Recently focused on videoconferencing applications • Focus on end-to-end, and RTP testing • Malicious endpoint generating randomized input • Built new tools required for the task • Targeted many applications, and found dangerous bugs • Apple FaceTime • WhatsApp • WebRTC (yikes!) Philipp Hancke’s wakeup call (crashing Janus of all things!) https://webrtchacks.com/lets-get-better-at-fuzzing-in-2019-heres-how/
  • 11. Why another talk on fuzzing, then? • Project Zero is a team of security analysts employed by Google • https://googleprojectzero.blogspot.com/ • Recently focused on videoconferencing applications • Focus on end-to-end, and RTP testing • Malicious endpoint generating randomized input • Built new tools required for the task • Targeted many applications, and found dangerous bugs • Apple FaceTime • WhatsApp • WebRTC (yikes!) Philipp Hancke’s wakeup call (crashing Janus of all things!) https://webrtchacks.com/lets-get-better-at-fuzzing-in-2019-heres-how/
  • 12. Project Zero scaring the fuzz out of us • In Kamailio, focus is on SIP/SDP signalling, of course • Media often taken care of in other components • WebRTC is signalling agnostic, though • You can use SIP, or XMPP, or some JSON flavour, or [INSERT_PROTOCOL] • A lot of media-related protocols to worry about instead! • STUN/TURN (NAT traversal) • DTLS/DTLS-SRTP (secure exchange of keys and data) • RTP/RTCP (or actually, SRTP/SRTCP), including RTP extensions • SCTP (data channels) • ... and codec specific payloads! • Identifying keyframes (VP8, VP9, H.264) • VP8 simulcast (VP8 payload descriptor) • VP9 SVC (VP9 payload descriptor)
  • 13. Project Zero scaring the fuzz out of us • In Kamailio, focus is on SIP/SDP signalling, of course • Media often taken care of in other components • WebRTC is signalling agnostic, though • You can use SIP, or XMPP, or some JSON flavour, or [INSERT_PROTOCOL] • A lot of media-related protocols to worry about instead! • STUN/TURN (NAT traversal) • DTLS/DTLS-SRTP (secure exchange of keys and data) • RTP/RTCP (or actually, SRTP/SRTCP), including RTP extensions • SCTP (data channels) • ... and codec specific payloads! • Identifying keyframes (VP8, VP9, H.264) • VP8 simulcast (VP8 payload descriptor) • VP9 SVC (VP9 payload descriptor)
  • 14. Project Zero scaring the fuzz out of us • In Kamailio, focus is on SIP/SDP signalling, of course • Media often taken care of in other components • WebRTC is signalling agnostic, though • You can use SIP, or XMPP, or some JSON flavour, or [INSERT_PROTOCOL] • A lot of media-related protocols to worry about instead! • STUN/TURN (NAT traversal) • DTLS/DTLS-SRTP (secure exchange of keys and data) • RTP/RTCP (or actually, SRTP/SRTCP), including RTP extensions • SCTP (data channels) • ... and codec specific payloads! • Identifying keyframes (VP8, VP9, H.264) • VP8 simulcast (VP8 payload descriptor) • VP9 SVC (VP9 payload descriptor)
  • 15. Project Zero scaring the fuzz out of us • In Kamailio, focus is on SIP/SDP signalling, of course • Media often taken care of in other components • WebRTC is signalling agnostic, though • You can use SIP, or XMPP, or some JSON flavour, or [INSERT_PROTOCOL] • A lot of media-related protocols to worry about instead! • STUN/TURN (NAT traversal) • DTLS/DTLS-SRTP (secure exchange of keys and data) • RTP/RTCP (or actually, SRTP/SRTCP), including RTP extensions • SCTP (data channels) • ... and codec specific payloads! • Identifying keyframes (VP8, VP9, H.264) • VP8 simulcast (VP8 payload descriptor) • VP9 SVC (VP9 payload descriptor)
  • 16. Ok, we’re scared now... what is fuzz testing? • Automated software testing technique • Unexpected or invalid data submitted to a program • Input pattern modified according to a defined strategy (e.g., for coverage) • Typical workflow 1 Engine generates input 2 Pattern mutated depending on existing dataset (“Corpus”) 3 Input data passed to target function and monitored (e.g., via sanitizers) 4 Coverage of new lines updates stats and Corpus (new pattern) 5 Repeat until it crashes! • Repeatability can be ensured using the same seeds or previous dumps
  • 17. Ok, we’re scared now... what is fuzz testing? • Automated software testing technique • Unexpected or invalid data submitted to a program • Input pattern modified according to a defined strategy (e.g., for coverage) • Typical workflow 1 Engine generates input 2 Pattern mutated depending on existing dataset (“Corpus”) 3 Input data passed to target function and monitored (e.g., via sanitizers) 4 Coverage of new lines updates stats and Corpus (new pattern) 5 Repeat until it crashes! • Repeatability can be ensured using the same seeds or previous dumps
  • 18. Ok, we’re scared now... what is fuzz testing? • Automated software testing technique • Unexpected or invalid data submitted to a program • Input pattern modified according to a defined strategy (e.g., for coverage) • Typical workflow 1 Engine generates input 2 Pattern mutated depending on existing dataset (“Corpus”) 3 Input data passed to target function and monitored (e.g., via sanitizers) 4 Coverage of new lines updates stats and Corpus (new pattern) 5 Repeat until it crashes! • Repeatability can be ensured using the same seeds or previous dumps
  • 19. Enter Janus! Janus General purpose, open source WebRTC server • https://github.com/meetecho/janus-gateway • Demos and documentation: https://janus.conf.meetecho.com • Community: https://groups.google.com/forum/#!forum/meetecho-janus
  • 20. Modular architecture • The core only implements the WebRTC stack • JSEP/SDP, ICE, DTLS-SRTP, Data Channels, Simulcast, VP9-SVC, ... • Plugins expose Janus API over different “transports” • Currently HTTP / WebSockets / RabbitMQ / Unix Sockets / MQTT / Nanomsg • “Application” logic implemented in plugins too • Users attach to plugins via the Janus core • The core handles the WebRTC stuff • Plugins route/manipulate the media/data • Plugins can be combined on client side as “bricks” • Video SFU, Audio MCU, SIP gatewaying, broadcasting, etc.
  • 21. Modular architecture • The core only implements the WebRTC stack • JSEP/SDP, ICE, DTLS-SRTP, Data Channels, Simulcast, VP9-SVC, ... • Plugins expose Janus API over different “transports” • Currently HTTP / WebSockets / RabbitMQ / Unix Sockets / MQTT / Nanomsg • “Application” logic implemented in plugins too • Users attach to plugins via the Janus core • The core handles the WebRTC stuff • Plugins route/manipulate the media/data • Plugins can be combined on client side as “bricks” • Video SFU, Audio MCU, SIP gatewaying, broadcasting, etc.
  • 22. Modular architecture • The core only implements the WebRTC stack • JSEP/SDP, ICE, DTLS-SRTP, Data Channels, Simulcast, VP9-SVC, ... • Plugins expose Janus API over different “transports” • Currently HTTP / WebSockets / RabbitMQ / Unix Sockets / MQTT / Nanomsg • “Application” logic implemented in plugins too • Users attach to plugins via the Janus core • The core handles the WebRTC stuff • Plugins route/manipulate the media/data • Plugins can be combined on client side as “bricks” • Video SFU, Audio MCU, SIP gatewaying, broadcasting, etc.
  • 23. Modular architecture • The core only implements the WebRTC stack • JSEP/SDP, ICE, DTLS-SRTP, Data Channels, Simulcast, VP9-SVC, ... • Plugins expose Janus API over different “transports” • Currently HTTP / WebSockets / RabbitMQ / Unix Sockets / MQTT / Nanomsg • “Application” logic implemented in plugins too • Users attach to plugins via the Janus core • The core handles the WebRTC stuff • Plugins route/manipulate the media/data • Plugins can be combined on client side as “bricks” • Video SFU, Audio MCU, SIP gatewaying, broadcasting, etc.
  • 24. What should we fuzz, here? • Many protocols via dependencies are fuzzed already • ICE/STUN/TURN (libnice) • DTLS/DTLS-SRTP (OpenSSL/LibreSSL/BoringSSL) • SRTP/SRTCP (libsrtp) • SCTP (usrsctplib) • Some other dependencies MAY need fuzzing (but not in Janus?) • Transports (HTTP, WebSockets, RabbitMQ, etc.) • JSON support (Jansson) • Others were done by us, so DEFINITELY need fuzzing • RTCP parsing (e.g., compound packets) • RTP processing (e.g., RTP extensions, codec specific payloads) • SDP parsing and processing
  • 25. What should we fuzz, here? • Many protocols via dependencies are fuzzed already • ICE/STUN/TURN (libnice) • DTLS/DTLS-SRTP (OpenSSL/LibreSSL/BoringSSL) • SRTP/SRTCP (libsrtp) • SCTP (usrsctplib) • Some other dependencies MAY need fuzzing (but not in Janus?) • Transports (HTTP, WebSockets, RabbitMQ, etc.) • JSON support (Jansson) • Others were done by us, so DEFINITELY need fuzzing • RTCP parsing (e.g., compound packets) • RTP processing (e.g., RTP extensions, codec specific payloads) • SDP parsing and processing
  • 26. What should we fuzz, here? • Many protocols via dependencies are fuzzed already • ICE/STUN/TURN (libnice) • DTLS/DTLS-SRTP (OpenSSL/LibreSSL/BoringSSL) • SRTP/SRTCP (libsrtp) • SCTP (usrsctplib) • Some other dependencies MAY need fuzzing (but not in Janus?) • Transports (HTTP, WebSockets, RabbitMQ, etc.) • JSON support (Jansson) • Others were done by us, so DEFINITELY need fuzzing • RTCP parsing (e.g., compound packets) • RTP processing (e.g., RTP extensions, codec specific payloads) • SDP parsing and processing
  • 27. A quick intro to libFuzzer • Popular coverage-guided fuzzing engine, part of the LLVM project • https://llvm.org/docs/LibFuzzer.html • Used by several well known applications • glibc, OpenSSL/LibreSSL/BoringSSL, SQLite, FFmpeg and many more • Made sense for us to have a look at it too! • A few key characteristics • Needs sources to be compiled with Clang • Works in-process (linked with the library/application under test) • Feeds inputs to the target via a fuzzing entrypoint (target function) • Execution of the target function is monitored with sanitizers tools (e.g., libasan)
  • 28. A quick intro to libFuzzer • Popular coverage-guided fuzzing engine, part of the LLVM project • https://llvm.org/docs/LibFuzzer.html • Used by several well known applications • glibc, OpenSSL/LibreSSL/BoringSSL, SQLite, FFmpeg and many more • Made sense for us to have a look at it too! • A few key characteristics • Needs sources to be compiled with Clang • Works in-process (linked with the library/application under test) • Feeds inputs to the target via a fuzzing entrypoint (target function) • Execution of the target function is monitored with sanitizers tools (e.g., libasan)
  • 29. A quick intro to libFuzzer • Popular coverage-guided fuzzing engine, part of the LLVM project • https://llvm.org/docs/LibFuzzer.html • Used by several well known applications • glibc, OpenSSL/LibreSSL/BoringSSL, SQLite, FFmpeg and many more • Made sense for us to have a look at it too! • A few key characteristics • Needs sources to be compiled with Clang • Works in-process (linked with the library/application under test) • Feeds inputs to the target via a fuzzing entrypoint (target function) • Execution of the target function is monitored with sanitizers tools (e.g., libasan)
  • 30. Wait, “coverage-guided fuzzing”?
  • 31. libFuzzer in (simplified) practice 1 Implement the method to receive and process the input data // my_fuzzer.c int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { ProcessData(Data, Size); return 0; } 2 Compile with Clang and the right flags > clang -g -O1 -fsanitize=fuzzer,address,undefined my_fuzzer.c 3 Launch passing the Corpus folder as the argument > ./my_fuzzer CORPUS_DIR 4 In case of crashes, pass the dumped input! (e.g., via gdb, or to test regressions) > gdb --args ./my_fuzzer crash-file-dump
  • 32. libFuzzer in (simplified) practice 1 Implement the method to receive and process the input data // my_fuzzer.c int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { ProcessData(Data, Size); return 0; } 2 Compile with Clang and the right flags > clang -g -O1 -fsanitize=fuzzer,address,undefined my_fuzzer.c 3 Launch passing the Corpus folder as the argument > ./my_fuzzer CORPUS_DIR 4 In case of crashes, pass the dumped input! (e.g., via gdb, or to test regressions) > gdb --args ./my_fuzzer crash-file-dump
  • 33. libFuzzer in (simplified) practice 1 Implement the method to receive and process the input data // my_fuzzer.c int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { ProcessData(Data, Size); return 0; } 2 Compile with Clang and the right flags > clang -g -O1 -fsanitize=fuzzer,address,undefined my_fuzzer.c 3 Launch passing the Corpus folder as the argument > ./my_fuzzer CORPUS_DIR 4 In case of crashes, pass the dumped input! (e.g., via gdb, or to test regressions) > gdb --args ./my_fuzzer crash-file-dump
  • 34. libFuzzer in (simplified) practice 1 Implement the method to receive and process the input data // my_fuzzer.c int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { ProcessData(Data, Size); return 0; } 2 Compile with Clang and the right flags > clang -g -O1 -fsanitize=fuzzer,address,undefined my_fuzzer.c 3 Launch passing the Corpus folder as the argument > ./my_fuzzer CORPUS_DIR 4 In case of crashes, pass the dumped input! (e.g., via gdb, or to test regressions) > gdb --args ./my_fuzzer crash-file-dump
  • 35. Integrating libFuzzer in Janus • First step was Clang support (Janus normally built with gcc) • Streamlined compilation flags in the process • Got useful warnings that led to some fixes too! • Next step was choosing what to fuzz • Decided to start with RTCP • Compound packets + length values + overflows = “fun”! • Then worked on the libFuzzer workflow 1 Fuzzing target with critical RTCP-related functions 2 Helper script to build the fuzzer 3 Helper script to run the fuzzer Original pull request (now merged, with RTP and SDP fuzzing as well) https://github.com/meetecho/janus-gateway/pull/1492
  • 36. Integrating libFuzzer in Janus • First step was Clang support (Janus normally built with gcc) • Streamlined compilation flags in the process • Got useful warnings that led to some fixes too! • Next step was choosing what to fuzz • Decided to start with RTCP • Compound packets + length values + overflows = “fun”! • Then worked on the libFuzzer workflow 1 Fuzzing target with critical RTCP-related functions 2 Helper script to build the fuzzer 3 Helper script to run the fuzzer Original pull request (now merged, with RTP and SDP fuzzing as well) https://github.com/meetecho/janus-gateway/pull/1492
  • 37. Integrating libFuzzer in Janus • First step was Clang support (Janus normally built with gcc) • Streamlined compilation flags in the process • Got useful warnings that led to some fixes too! • Next step was choosing what to fuzz • Decided to start with RTCP • Compound packets + length values + overflows = “fun”! • Then worked on the libFuzzer workflow 1 Fuzzing target with critical RTCP-related functions 2 Helper script to build the fuzzer 3 Helper script to run the fuzzer Original pull request (now merged, with RTP and SDP fuzzing as well) https://github.com/meetecho/janus-gateway/pull/1492
  • 38. Integrating libFuzzer in Janus • First step was Clang support (Janus normally built with gcc) • Streamlined compilation flags in the process • Got useful warnings that led to some fixes too! • Next step was choosing what to fuzz • Decided to start with RTCP • Compound packets + length values + overflows = “fun”! • Then worked on the libFuzzer workflow 1 Fuzzing target with critical RTCP-related functions 2 Helper script to build the fuzzer 3 Helper script to run the fuzzer Original pull request (now merged, with RTP and SDP fuzzing as well) https://github.com/meetecho/janus-gateway/pull/1492
  • 39. Integrating libFuzzer in Janus // fuzz-rtcp.c #include "janus/rtcp.h" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) { if (size < 8 || size > 1472) return 0; if (!janus_is_rtcp(data, size)) return 0; /* Initialize an empty RTCP context */ janus_rtcp_context ctx; janus_rtcp_parse(ctx, (char *)data, size); GSList *list = janus_rtcp_get_nacks((char *)data, size); ... if (list) g_slist_free(list); return 0; }
  • 40. Presenting the code coverage
  • 41. Corpora files: a shared effort! https://github.com/RTC-Cartel/webrtc-fuzzer-corpora (thx, Iñaki!)
  • 42. Scalable distributed fuzzing via OSS-Fuzz https://github.com/google/oss-fuzz/pull/2241 (Janus is in, yay!)
  • 43. Scalable distributed fuzzing via OSS-Fuzz https://github.com/google/oss-fuzz/pull/2241 (Janus is in, yay!)
  • 44. A detailed tutorial on how to setup all this! https://webrtchacks.com/fuzzing-janus/
  • 45. What’s next? • So far, we only fuzzed RTP, RTCP and in part SDP in the core • SDP fuzzing should be improved (maybe with structure-aware fuzzing?) • Fuzzing signalling might be nice, but so many transports! • What about plugins and their custom interactions? • Definitely expand the corpora • The shared RTC-Cartel repo should help with that • Let’s see if what crashed you crashed us too, and viceversa! • libFuzzer is not the only option here • Henning and Sandro introduced AFL, Radamsa, Gasoline and others last year • KITE and its “weaponised” browsers can be very helpful as an orthogonal testing tool
  • 46. What’s next? • So far, we only fuzzed RTP, RTCP and in part SDP in the core • SDP fuzzing should be improved (maybe with structure-aware fuzzing?) • Fuzzing signalling might be nice, but so many transports! • What about plugins and th
  • We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks
    SAVE OUR EARTH

    We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

    More details...

    Sign Now!

    We are very appreciated for your Prompt Action!

    x