aboutsummaryrefslogtreecommitdiff
path: root/fuzz/Makefile.am
Commit message (Collapse)AuthorAge
* fuzz: extend fuzzing coverage (#2281)Ivan Nardi2024-01-24
|
* example: rework code between `ndpiReader.c` and `reader_util.c` (#2273)Ivan Nardi2024-01-22
|
* config: follow-up (#2268)Ivan Nardi2024-01-20
| | | | | | Some changes in the parameters names. Add a fuzzer to fuzz the configuration file format. Add the infrastructure to configuratin callbacks. Add an helper to map LRU cache indexes to names.
* New API for library configurationNardi Ivan2024-01-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first step into providing (more) configuration options in nDPI. The idea is to have a simple way to configure (most of) nDPI: only one function (`ndpi_set_config()`) to set any configuration parameters (in the present or on in the future) and we try to keep this function prototype as agnostic as possible. You can configure the library: * via API, using `ndpi_set_config()` * via a configuration file, in a text format This way, anytime we need to add a new configuration parameter: * we don't need to add two public functions (a getter and a setter) * we don't break API/ABI compatibility of the library; even changing the parameter type (from integer to a list of integer, for example) doesn't break the compatibility. The complete list of configuration options is provided in `doc/configuration_parameters.md`. As a first example, two configuration knobs are provided: * the ability to enable/disable the extraction of the sha1 fingerprint of the TLS certificates. * the upper limit on the number of packets per flow that will be subject to inspection
* fuzz: improve fuzzing coverage (#2239)Ivan Nardi2024-01-02
|
* fuzz: extend fuzzing coverage (#2208)Ivan Nardi2023-12-11
|
* Keep separating public and private API (#2157)Ivan Nardi2023-11-29
| | | See: b08c787fe
* Have a clear distinction between public and private/internal API (#2137)Ivan Nardi2023-11-09
| | | | | | 1) Public API/headers in `src/include/` [as it has always been] 2) Private API/headers in `src/lib/` Try to keep the "ndpi_" prefix only for the public functions
* STUN: major code rework (#2116)Ivan Nardi2023-10-30
| | | | | | | | | | | | Try to have a faster classification, on first packet; use standard extra dissection data path for sub-classification, metadata extraction and monitoring. STUN caches: * use the proper confidence value * lookup into the caches only once per flow, after having found a proper STUN classification Add identification of Telegram VoIP calls.
* IPv6: add support for custom categories (#2126)Ivan Nardi2023-10-29
|
* fuzz: extend fuzzing coverageNardi Ivan2023-10-15
|
* fuzzing: extend fuzzing coverageNardi Ivan2023-10-09
| | | | | Try fuzzing some functions which write to file/file descriptor; to avoid slowing the fuzzer, close its stdout
* fuzz: extend fuzzing coverageNardi Ivan2023-10-07
|
* fuzz: extend fuzzing coverageNardi Ivan2023-09-16
|
* fuzz: add fuzzers to test bitmap64 and domain_classify data structures (#2082)Ivan Nardi2023-09-10
|
* fuzz: add fuzzers to test reader_util code (#2080)Ivan Nardi2023-09-10
|
* Added `lists/gambling.list` to extra dist.Toni Uhlig2023-08-27
| | | | | | * make dist in `./fuzz`: fixed inconsistent `*.dict` file pattern Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* fuzz: extend coverage (#2073)Ivan Nardi2023-08-20
|
* fuzz: extend fuzzing coverage (#2052)Ivan Nardi2023-07-18
| | | | Added/merged some traces. Improved Socks identification
* fuzz: add fuzzer for DGA detection code (#2042)Ivan Nardi2023-07-13
|
* fuzz: extend fuzzing coverage (#2040)Ivan Nardi2023-07-11
| | | | | | | | | Some notes: * libinjection: according to https://github.com/libinjection/libinjection/issues/44, it seems NULL characters are valid in the input string; * RTP: `rtp_get_stream_type()` is called only for RTP packets; if you want to tell RTP from RTCP you should use `is_rtp_or_rtcp()`; * TLS: unnecessary check; we already make the same check just above, at the beginning of the `while` loop
* fuzz: extend fuzzers coverage (#1952)Ivan Nardi2023-04-25
|
* Test multiple `ndpiReader` configurations (#1931)Ivan Nardi2023-04-06
| | | | | | | | | Extend internal unit tests to handle multiple configurations. As some examples, add tests about: * disabling some protocols * disabling Ookla aggressiveness Every configurations data is stored in a dedicated directory under `tests\cfgs`
* fuzz: add a new fuzzer triggering the payload analyzer function(s) (#1926)Ivan Nardi2023-04-04
|
* fuzz: add fuzzer to test internal gcrypt code (#1920)Ivan Nardi2023-04-04
|
* fuzz: add a new fuzzer to test TLS certificates (#1901)Ivan Nardi2023-03-20
|
* fuzz: extend fuzz coverage (#1888)Ivan Nardi2023-02-16
|
* fuzz: some improvements and add two new fuzzers (#1881)Ivan Nardi2023-02-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove `FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION` define from `fuzz/Makefile.am`; it is already included by the main configure script (when fuzzing). Add a knob to force disabling of AESNI optimizations: this way we can fuzz also no-aesni crypto code. Move CRC32 algorithm into the library. Add some fake traces to extend fuzzing coverage. Note that these traces are hand-made (via scapy/curl) and must not be used as "proof" that the dissectors are really able to identify this kind of traffic. Some small updates to some dissectors: CSGO: remove a wrong rule (never triggered, BTW). Any UDP packet starting with "VS01" will be classified as STEAM (see steam.c around line 111). Googling it, it seems right so. XBOX: XBOX only analyses UDP flows while HTTP only TCP ones; therefore that condition is false. RTP, STUN: removed useless "break"s Zattoo: `flow->zattoo_stage` is never set to any values greater or equal to 5, so these checks are never true. PPStream: `flow->l4.udp.ppstream_stage` is never read. Delete it. TeamSpeak: we check for `flow->packet_counter == 3` just above, so the following check `flow->packet_counter >= 3` is always false.
* fuzz: add a new fuzzer to test serialization/deserialization code (#1876)Ivan Nardi2023-01-27
| | | | | | | | | | Autodetecting the needed buffer size is quite complex (especially with float/double values) so it is mandatory to properly check for `ndpi_snprintf` truncation. These issues have been undetected so far probably because the default buffer is big enough for all common cases. Add an example of usage of `ndpi_deserialize_clone_all()` (taken from `ntopng`)
* Add some fuzzers to test other data structures. (#1870)Ivan Nardi2023-01-25
| | | | | | | Start using a dictionary for fuzzing (see: https://llvm.org/docs/LibFuzzer.html#dictionaries). Remove some dead code. Fuzzing with debug enabled is not usually a great idea (from performance POV). Keep the code since it might be useful while debugging.
* fuzz: fix memory allocation failure logic (#1867)Ivan Nardi2023-01-20
| | | | | We *do* want to have some allocation errors. Fix some related bugs Fix: 29be01ef
* Fuzz: fix compilation with nBPF (#1860)Ivan Nardi2023-01-18
| | | Close #1859
* Add some fuzzers to test algorithms and data structures (#1852)Ivan Nardi2023-01-17
| | | Fix some issues found with these new fuzzers
* fuzz: add fuzzer testing nDPI (initial) configurations (#1830)Ivan Nardi2022-12-23
| | | | | | | | | | | | | | | | | The goal of this fuzzer is to test init and deinit of the library, with different configurations. In details: * random memory allocation failures, even during init phase * random `ndpi_init_prefs` parameter of `ndpi_init_detection_module()` * random LRU caches sizes * random bitmask of enabled protocols * random parameters of `ndpi_set_detection_preferences()` * random initialization of opportunistic TLS * random load/don't load of configuration files This new fuzzer is a C++ file, because it uses `FuzzedDataProvider` class (see https://github.com/google/fuzzing/blob/master/docs/split-inputs.md). Note that the (existing) fuzzers need to be linked with C++ compiler anyway, so this new fuzzer doesn't add any new requirements.
* fuzz: some enhancements (#1827)Ivan Nardi2022-12-10
| | | | | | | | | | Load some custom configuration (like in the unit tests) and factorize some (fuzzing) common code. There is no way to pass file paths to the fuzzers as parameters. The safe solution seems to be to load them from the process working dir. Anyway, missing file is not a blocking error. Remove some dead code (found looking at the coverage report)
* fuzz: add a new fuzzer testing memory allocation failures (#1818)Ivan Nardi2022-12-06
| | | | | | | | | Try to fuzz error paths triggered by allocation errors. Fix some errors already found by this new fuzzer. Basic idea taken from: https://github.com/harfbuzz/harfbuzz/pull/2566/files `FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION` is a standard define used to (not)compile specific code in fuzzing builds. See: https://llvm.org/docs/LibFuzzer.html
* Add support for LTO and Gold linker (#1812)Ivan Nardi2022-12-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit add (optional) support for Link-Time-Optimization and Gold linker. This is the first, mandatory step needed to make nDPI compliant with "introspector" sanitizer requirements in OSS-Fuzz: see https://github.com/google/oss-fuzz/issues/8939 Gold linker is not supported by Windows and by macOS, so this feature is disabled by default. It has been enable in CI in two linux targets ("latest" gcc and clang). Fix some warnings triggered by LTO. The changes in `src/lib/ndpi_serializer.c` seams reasonable. However, the change in `tests/unit/unit.c` is due to the following warning, which seems to be a false positive. ``` unit.c: In function ‘serializerUnitTest’: ndpi_serializer.c:2258:13: error: ‘MEM[(struct ndpi_private_serializer *)&deserializer].buffer.size’ may be used uninitialized in this function [-Werror=maybe-uninitialized] unit.c:67:31: note: ‘MEM[(struct ndpi_private_serializer *)&deserializer].buffer.size’ was declared here 67 | ndpi_serializer serializer, deserializer; | ^ ndpi_serializer.c:2605:10: error: ‘MEM[(struct ndpi_private_serializer *)&deserializer].status.buffer.size_used’ may be used uninitialized in this function [-Werror=maybe-uninitialized] unit.c:67:31: note: ‘MEM[(struct ndpi_private_serializer *)&deserializer].status.buffer.size_used’ was declared here 67 | ndpi_serializer serializer, deserializer; ``` Since this warning is triggered only with an old version of gcc and `tests/unit/unit.c` is used only during the tests, the easiest fix has been applied. Some (unknown to me) combinations of OS and compiler trigger the following warnings at linker time (with sanitizer and gold linker) ``` /usr/bin/ld.gold: warning: Cannot export local symbol '__asan_report_load1_asm' /usr/bin/ld.gold: warning: Cannot export local symbol '__asan_report_load2_asm' /usr/bin/ld.gold: warning: Cannot export local symbol '__asan_report_load4_asm' /usr/bin/ld.gold: warning: Cannot export local symbol '__asan_report_load8_asm' /usr/bin/ld.gold: warning: Cannot export local symbol '__asan_report_load16_asm' /usr/bin/ld.gold: warning: Cannot export local symbol '__asan_report_store1_asm' /usr/bin/ld.gold: warning: Cannot export local symbol '__asan_report_store2_asm' /usr/bin/ld.gold: warning: Cannot export local symbol '__asan_report_store4_asm' [..] ``` I have not found any references to this kind of message, with the only exception of https://sourceware.org/bugzilla/show_bug.cgi?id=25975 which seems to suggest that these messages can be safely ignored. In any case, the compilation results are sound. Fix `clean` target in the Makefile in the `example` directory. In OSS-Fuzz enviroments, `fuzz_ndpi_reader` reports a strange link error (as always, when the gold linker is involved...). It's come out that the culprit was the `tempnam` function: the code has been changed to use `tmpfile` instead. No sure why... :( Fuzzing target `fuzz_ndpi_reader.c` doesn't use `libndpiReader.a` anymore: this way we can use `--with-only-libndpi` flag on Oss-Fuzz builds as workaround for the "missing dependencies errors" described in https://github.com/google/oss-fuzz/issues/8939
* Remove some useless fuzzing target (#1813)Ivan Nardi2022-12-01
| | | | | We don't need specific targets to reproduce fuzzing issues. After all, calling `./fuzz/fuzz_process_packet_with_main $ARTIFACT_FILE` is equivalento to `./fuzz/fuzz_process_packet $ARTIFACT_FILE`
* Add a new fuzzer for QUIC (#1800)Ivan Nardi2022-12-01
| | | | | | | | | | | | QUIC packets are encrypted/obfuscated; that means that we need to decrypt them before parsing the real (TLS) message. Fuzzing is not effective here, since a random buffer is hardly a valid encrypted QUIC packet. Add a new fuzzer, testing *decrypted* QUIC packets. Add a basic corpus. Fix a few bugs already found by this fuzzer.
* Do not interfere with CFLAGS/LDFLAGS env anymore. (#1659)Toni2022-07-13
| | | | | | | * CI fixes * some build systems do not like that (e.g. OpenWrt) * fixed some rrdtool related build warnings/errors Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* Fix writes to `flow->protos` union fields (#1354)Ivan Nardi2021-11-15
| | | | | | | | | | | | | | | | | | | | | | | | | We can write to `flow->protos` only after a proper classification. This issue has been found in Kerberos, DHCP, HTTP, STUN, IMO, FTP, SMTP, IMAP and POP code. There are two kinds of fixes: * write to `flow->protos` only if a final protocol has been detected * move protocol state out of `flow->protos` The hard part is to find, for each protocol, the right tradeoff between memory usage and code complexity. Handle Kerberos like DNS: if we find a request, we set the protocol and an extra callback to further parsing the reply. For all the other protocols, move the state out of `flow->protos`. This is an issue only for the FTP/MAIL stuff. Add DHCP Class Identification value to the output of ndpiReader and to the Jason serialization. Extend code coverage of fuzz tests. Close #1343 Close #1342
* Fix broken fuzz_process_packet fuzzer by adding a call to ↵Toni2021-10-18
| | | | | | | | | | | | ndpi_finalize_initialization(). (#1334) * fixed several memory errors (heap-overflow, unitialized memory, etc) * ability to build fuzz_process_packet with a main() allowing to replay crash data generated with fuzz_process_packet by LLVMs libfuzzer * temporarily disable fuzzing if `tests/do.sh` executed with env FUZZY_TESTING_ENABLED=1 Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* Fixed memory leaks caused by conditional free'ing for some TLS connec… (#1132)Toni2021-02-10
| | | | | | | | | | | | | | | * Fixed memory leaks caused by conditional free'ing for some TLS connections. * Members of tls_quic struct should also free'd if the detected master protocol is IMAPS / POPS / SMTPS / etc. Signed-off-by: Toni Uhlig <matzeton@googlemail.com> * Prevent reader_util.c from exit()'ing if maximum flow count reached. This confuses the fuzzer. * Improved fuzz/Makefile.am to use LDADD for ../example/libndpiReader.a instead of LDFLAGS. That way, fuzz_ndpi_reader re-links to ../example/libndpiReader.a if something changed there. Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* Add (optional) dependency on external libraries: libgcrypt and libgpg-errorNardi Ivan2020-08-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support QUIC payload and header decryption, it is necessary to choose an external crypto library to handle the low-level crypto stuff. Since we will use some Wireshark code, it is quite natural to choose the same library used by Wireshark itself: libgcrypt. More precisely, we will use libgcrypt and libgpg-error. Both libraries have LGPL license, so there should be no issue from this point of view. These libraries are not required to build nDPI, and their usage is optional: nDPI will keep working (and compiling) even if they are not available. However, without them, QUIC sub-classification is next to impossible. The configure flag "--disable-gcrypt" forces the build system to ignore these libraries. libgpg-error is only used for debug to have meaningful error messages and its usage is trivial. The same cannot be said for libgcrypt because its initialization is a significant issue. The rest of this commit message try explaining how libgcrypt is initialized. According to the documentation https://gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html https://gnupg.org/documentation/manuals/gcrypt/Multi_002dThreading.html#Multi_002dThreading libgcrypt must be initialized before using it, but such initialization should be performed by the actual application and not by any library. Forcing the users to proper initialize libgcrypt in their own code seems unreasonable: most people using nDPI might be complete unaware of any crypto stuff and update each and every one application linking to nDPI with specific libgcrypt code should be out of question, anyway. Fortunately, it seems a workaround exists to initialize libgcrypt in a library https://lists.gnupg.org/pipermail/gcrypt-devel/2003-August/000458.html Therefore, we could provide a wrapper to this initialization stuff in a nDPI function. Unfortunately nDPI API lacks a global init function that must be called only once, before any other functions. We could add it, but that would be a major API break. AFAIK, ndpi_init_detection_module() might be called multiple times, for example to create multiple independent dpi engines in the same program. The proposed solution is to (optionally) initialize libgcrypt in ndpi_init_detection_module() anyway: * if the actual application doesn't directly use libgcrypt and only calls ndpi_init_detection_module() once, everything is formally correct and it should work out of the box [by far the most common user case]; * if the actual application already uses libgcrypt directly, it already performs the required initialization. In this case the ndpi_prefs.ndpi_dont_init_libgcrypt flag should be passed to ndpi_init_detection_module() to avoid further initializations. The only scenario not supported by this solution is when the application is unaware of libgcrypt and calls ndpi_init_detection_module() multiple times concurrently. But this scenario should be uncommon. A completely different option should be to switch to another crypto library, with a huge impact on the QUIC dissector code. Bottom line: crypto is hard, using libgcrypt is complex and the proposed initialization, even if not perfect, should cover the most frequent user cases and should work, for the time being. If anyone has some suggestions...
* Added fuzz_*_LDADD to give Automake the opportunity to do some dependency ↵Toni Uhlig2020-06-29
| | | | | | tracking. Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* Improved fuzz_ndpi_reader which supports now SMP/MT w/o race-coniditions.Toni Uhlig2020-06-29
| | | | | | | ./tests/do.sh can supports SMP/MT via environment variables. Removed -fno-sanitize=shift as well, was fixed by 317d3ffd. Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* Re-Added corpus zipfile generation required for google-oss fuzzerToni Uhlig2020-06-27
| | | | Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* fixed fuzzing tests in a way that ./tests/do.sh is now able to use corpus ↵Toni Uhlig2020-06-27
| | | | | | *.pcap files from ./tests/pcap Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* Disabled unused codeLuca Deri2020-06-25
|
* Libfuzz fixesLuca2020-02-02
|
Powered by cgit, Themed by Ted Yin.