| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
Since 070a0908b we are able to detect P2P calls directly from the packet
content, without any correlation among flows
|
|
|
|
| |
Avoid that useless code is copy-and-pasted into new dissector, as in
https://github.com/ntop/nDPI/pull/2470#discussion_r1639384434
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==29508==ERROR: AddressSanitizer: SEGV on unknown address 0x50710145d51d (pc 0x55cb788f25fe bp 0x7ffcfefa15f0 sp 0x7ffcfefa1240 T0)
==29508==The signal is caused by a READ memory access.
#0 0x55cb788f25fe in ndpi_search_zoom /home/ivan/svnrepos/nDPI/src/lib/protocols/zoom.c:210:24
#1 0x55cb787e9418 in check_ndpi_detection_func /home/ivan/svnrepos/nDPI/src/lib/ndpi_main.c:7174:6
#2 0x55cb7883f753 in check_ndpi_udp_flow_func /home/ivan/svnrepos/nDPI/src/lib/ndpi_main.c:7209:10
#3 0x55cb7883bc9d in ndpi_check_flow_func /home/ivan/svnrepos/nDPI/src/lib/ndpi_main.c:7240:12
```
Found by oss-fuzzer
See: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=69520
|
|
|
|
|
|
|
|
|
|
| |
After a flow has been classified as RTP or RTCP, nDPI might analyse more
packets to look for STUN/DTLS packets, i.e. to try to tell if this flow
is a "pure" RTP/RTCP flow or if the RTP/RTCP packets are multiplexed with
STUN/DTLS.
Useful for proper (sub)classification when the beginning of the flows
are not captured or if there are lost packets in the the captured traffic.
Disabled by default
|
| |
|
| |
|
|
|
|
|
| |
TODO: TCP reassembler on top of UDP reassembler
See: #2414
|
|
|
|
| |
ndpi_internal_detection_process_packet()
|
|
|
|
|
|
| |
RFC4571 is not the only way to wrap RTP messages in TCP streams.
For example, when RTP is encapsulated over TURN flows (i.e. via DATA
attribute) there is no additional framing.
See also 6127e0490
|
|
|
|
|
| |
Support rtp/rtcp over tcp as per rfc4571.
Signed-off-by: mmaatuq <mahmoudmatook.mm@gmail.com>
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
|
|
| |
The original code handled also TCP/TLS, but it was removed in 6fc29b3ae
|
|
|
|
|
|
|
|
|
| |
* detect more Kafka request packet's
* requires less flow memory
* same detection behavior as before e.g. no asym detection implemented
(can be done by dissecting responses, requires more effort)
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
Co-authored-by: Nardi Ivan <nardi.ivan@gmail.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
* some `#ifdef`ed code dates back to 2019, 2020 and 2021
* some function signatures were still present in `ndpi_main.h`
which may cause linker errors for libnDPI dependee's
* return an error while trying to serialize a double instead
of `fprintf(stderr, ...)`
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Removed
- int ndpi_load_ipv4_ptree_file(ndpi_ptree_t *tree, const char *path, u_int16_t protocol_id);
- int ndpi_load_ipv6_ptree_file(ndpi_ptree_t *tree, const char *path, u_int16_t protocol_id);
Added (it supports both IPv4 and v6)
+ int ndpi_load_ptree_file(ndpi_ptree_t *tree, const char *path, u_int16_t protocol_id);
|
| |
|
| |
|
|
|
|
|
| |
New implementation fails tests 11b, 12 and 13.
Revert to the original (BSD) implementation (with also some basic
parameters check)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IRC has its best times well behind, but there are still some servers
using it.
We should try to simplify the detection logic, still based on OpenDPI
logic.
Let's start with some easy changes:
* try to detect TLS connection via standard hostname/SNI matching,
removing an old heuristic (we have never had any trace matching it);
* add some basic server names;
* once we detect that the flow is IRC, we don't have to perform
anything else;
* remove HTTP stuff; real HTTP flows never trigger that data path
* use `ndpi_memmem()` when possible
|
|
|
| |
Co-authored-by: Ivan Nardi <12729895+IvanNardi@users.noreply.github.com>
|
| |
|
| |
|
|
|
|
| |
Add an explicit upper limit on the number of packets processed before
giving up.
|
|
|
|
|
|
|
|
|
| |
There is some overlap between RTP and Raknet detection: give precedence
to RTP logic.
Consequences:
* Raknet might require a little bit more packets for some flows (not a
big issue)
* some very small (1-2 pkts) Raknet flows are not classified (not sure
what do do about that..)
|
| |
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```
SCARINESS: 12 (1-byte-read-heap-buffer-overflow)
#0 0x557f3a5b5100 in ndpi_get_host_domain /src/ndpi/src/lib/ndpi_domains.c:158:8
#1 0x557f3a59b561 in ndpi_check_dga_name /src/ndpi/src/lib/ndpi_main.c:10412:17
#2 0x557f3a51163a in process_chlo /src/ndpi/src/lib/protocols/quic.c:1467:7
#3 0x557f3a469f4b in LLVMFuzzerTestOneInput /src/ndpi/fuzz/fuzz_quic_get_crypto_data.c:44:7
#4 0x557f3a46abc8 in NaloFuzzerTestOneInput (/out/fuzz_quic_get_crypto_data+0x4cfbc8)
```
Some notes about the leak: if the insertion into the uthash fails (because of an
allocation failure), we need to free the just allocated entry. But the only
way to check if the `HASH_ADD_*` failed, is to perform a new lookup: a bit
costly, but we don't use that code in the fast-path.
See also efb261a95c5a
Credits for finding the issues to Philippe Antoine (@catenacyber) and his
`nallocfuzz` fuzzing engine
See: https://github.com/catenacyber/nallocfuzz
See: https://github.com/google/oss-fuzz/pull/9902
|
| |
|
|
|
|
|
| |
* credits goes to Vladimir Gavrilov
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
|
|
| |
- int ndpi_load_ipv4_ptree_file(ndpi_ptree_t *tree, const char *path, u_int16_t protocol_id);
- int ndpi_load_ipv6_ptree_file(ndpi_ptree_t *tree, const char *path, u_int16_t protocol_id);
|
|
|
|
| |
ndpi_domain_classify_xxx calls
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This cache was added in b6b4967aa, when there was no real Zoom support.
With 63f349319, a proper identification of multimedia stream has been
added, making this cache quite useless: any improvements on Zoom
classification should be properly done in Zoom dissector.
Tested for some months with a few 10Gbits links of residential traffic: the
cache pretty much never returned a valid hit.
|
|
|
|
|
| |
Deciding when a session starts and ends is responsability of the
applicationi (via its flow manager)i, not of the library.
BTW, the removed code is incomplete at beast
|
|
|
|
|
|
| |
See RFC8122: it is quite likely that STUN/DTLS/SRTP flows use
self-signed certificates
Follow-up of b287d6ec8
|