Bad syscollector network iface values handling #21296

MiguelazoDS · 2024-01-09T07:56:34Z

Description

As a consequence of the error found

2024/01/04 13:51:53 :router[138953] logging_helper.c:25 at taggedLogFunction(): ERROR: Error sending message to provider: Error parsing message, 1: 573: error: invalid number: "-956995642", constant does not fit [0; 4294967295]

and addressed here #21194

After a little investigation, we found several mishandling values for some Syscollector fields

There's an implicit conversion from uint to int that causes invalid information stored in the Syscollector database for network iface provider. This specific case was discovered because of the log shared above.

The value stored in the manager database after a delta event does not match the one found with the testtool.

Expand

Agent

Manager

The uint data type is easy to overpass when we are talking about "bytes" for any interface and the value ends up containing wrong information.

The maximum size of a uint value is = 4294967295, which in bytes is almost 4GB. We can reach that number easily by downloading a single ISO file.

Also the MTU may be negative according to the issue studied here The router module can't process some agent messages due to flatbuffer schema constraint #21340 (comment)

DoD

Avoid implicit conversion from uint to int
Fix delta event wrong value
Evaluate the uint data type. Probably using long would be a better option even though the negative values will not be used.

The text was updated successfully, but these errors were encountered:

Dwordcito · 2024-01-09T14:10:13Z

This change is for a major version.

MiguelazoDS · 2024-04-30T19:33:04Z

Analysis

This issue is strongly related to this one #21194. This was not properly solved because it was so intrusive, but as a workaround, we changed the flatbuffer schema data type to allow negative values, which are a consequence of the bad data type conversion on the agent side. That leads to invalid values stored in the syscollector local database, and those are sent as sync messages to the manager, causing the issue we described above.

Also as part of the same issue, because of a delta message, we experience something similar. The value is casted somehow in wazuh_db and the value ends up showing incorrect information on the manager side.

We need to mention this issue as well #21340 which wrongly casts a uint32_t value into and int32_t.

Error reproduced

Using a mocked /proc/net/dev file

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo: 36278034   206260    0    0    0     0          0         0 36278034   206260    0    0    0     0       0          0
enp0s3: 3341848418 2382203    0    0    0     0          0         0 40075805  506967    0    0    0     0       0          0
enp0s8: 79699938   510663    0    0    0     0          0         0 8627671553   5968446    0    0    0     0       0          0
enp0s9:  574415     3453    0    0    0     0          0        311     2116      28    0    0    0     0       0          0
docker0:  3520716   86560    0    0    0     0          0         0   941439628   253045    0    0    0     0       0          0

We can see two values that cause issues here, 3341848418 and 8627671553.
The first one is bigger than the maximum representation of an integer, so it overflows. The second one is bigger than the maximum representation of an uint_t value, and considering that those values represent bytes, uint_t is so small to store that information.

sysinfo_tool output

Note

For interface enp0s3 rx_bytes field, the value does not change, because is not bigger than uint, but we have issues later casting to int.

Note

For interface enp0s8 tx_bytes field, the value is bigger than UINT_MAX. So it overflows.

local database

{"name":"enp0s3","adapter":"","type":"ethernet","state":"up","mtu":1500,"mac":"02:d0:f1:1a:d8:67","tx_packets":506967,"rx_packets":2382203,"tx_bytes":40075805,"rx_bytes":-953118878,"tx_errors":0,"rx_errors":0,"tx_dropped":0,"rx_dropped":0,"checksum":"805a5d2ea89c38cc35d38c66738c4620a143a589","item_id":"7a60750dd3c25c53f21ff7f44b4743664ddbb66a","db_status_field_dm":1},
{"name":"enp0s8","adapter":"","type":"ethernet","state":"up","mtu":1500,"mac":"08:00:27:af:c0:42","tx_packets":5968446,"rx_packets":510663,"tx_bytes":37736961,"rx_bytes":79699938,"tx_errors":0,"rx_errors":0,"tx_dropped":0,"rx_dropped":0,"checksum":"3b236826f633f3d92248708a464cbd4eb274385f","item_id":"989b6a387c8b314c67793584881c06393b32923e","db_status_field_dm":1},

Syscollector sync case

2024/04/30 18:02:44 wazuh-modulesd:syscollector[66757] logging_helper.c:40 at taggedLogFunction(): DEBUG: Sync sent: {"component":"syscollector_network_iface","data":{"attributes":{"adapter":null,"checksum":"805a5d2ea89c38cc35d38c66738c4620a143a589","item_id":"7a60750dd3c25c53f21ff7f44b4743664ddbb66a","mac":"02:d0:f1:1a:d8:67","mtu":1500,"name":"enp0s3","rx_bytes":-953118878,"rx_dropped":0,"rx_errors":0,"rx_packets":2382203,"scan_time":"2024/04/30 21:02:44","state":"up","tx_bytes":40075805,"tx_dropped":0,"tx_errors":0,"tx_packets":506967,"type":"ethernet"},"index":"7a60750dd3c25c53f21ff7f44b4743664ddbb66a","timestamp":""},"type":"state"}
2024/04/30 18:02:44 wazuh-modulesd:syscollector[66757] logging_helper.c:40 at taggedLogFunction(): DEBUG: Sync sent: {"component":"syscollector_network_iface","data":{"attributes":{"adapter":null,"checksum":"3b236826f633f3d92248708a464cbd4eb274385f","item_id":"989b6a387c8b314c67793584881c06393b32923e","mac":"08:00:27:af:c0:42","mtu":1500,"name":"enp0s8","rx_bytes":79699938,"rx_dropped":0,"rx_errors":0,"rx_packets":510663,"scan_time":"2024/04/30 21:02:44","state":"up","tx_bytes":37736961,"tx_dropped":0,"tx_errors":0,"tx_packets":5968446,"type":"ethernet"},"index":"989b6a387c8b314c67793584881c06393b32923e","timestamp":""},"type":"state"}

First log "rx_bytes":-953118878
Second log "tx_bytes":37736961

Both values are wrong

Syscollector delta case

2024/04/30 18:35:18 wazuh-modulesd:syscollector[67797] logging_helper.c:40 at taggedLogFunction(): DEBUG: Delta sent: {"data":{"adapter":null,"checksum":"805a5d2ea89c38cc35d38c66738c4620a143a589","item_id":"7a60750dd3c25c53f21ff7f44b4743664ddbb66a","mac":"02:d0:f1:1a:d8:67","mtu":1500,"name":"enp0s3","rx_bytes":3341848418,"rx_dropped":0,"rx_errors":0,"rx_packets":2382203,"scan_time":"2024/04/30 21:35:17","state":"up","tx_bytes":40075805,"tx_dropped":0,"tx_errors":0,"tx_packets":506967,"type":"ethernet"},"operation":"MODIFIED","type":"dbsync_network_iface"}
2024/04/30 18:35:18 wazuh-modulesd:syscollector[67797] logging_helper.c:40 at taggedLogFunction(): DEBUG: Delta sent: {"data":{"adapter":null,"checksum":"3b236826f633f3d92248708a464cbd4eb274385f","item_id":"989b6a387c8b314c67793584881c06393b32923e","mac":"08:00:27:af:c0:42","mtu":1500,"name":"enp0s8","rx_bytes":79699938,"rx_dropped":0,"rx_errors":0,"rx_packets":510663,"scan_time":"2024/04/30 21:35:17","state":"up","tx_bytes":37736961,"tx_dropped":0,"tx_errors":0,"tx_packets":5968446,"type":"ethernet"},"operation":"MODIFIED","type":"dbsync_network_iface"}

First log "rx_bytes":3341848418
This value is correct but is wrongly stored in the manager database as "2147483647"
And that is because we are storing in valueint.

wazuh/src/wazuh_db/wdb_delta_event.c

Line 269 in 1b05095

if (IS_VALID_VALUE(table_name, field_name, value->valueint)) {

   scan_id = 0
 scan_time = 2024/04/30 21:39:27
      name = enp0s3
   adapter =
      type = ethernet
     state = up
       mtu = 1500
       mac = 02:d0:f1:1a:d8:67
tx_packets = 506967
rx_packets = 2382203
  tx_bytes = 40075805
  rx_bytes = 2147483647
 tx_errors = 0
 rx_errors = 0
tx_dropped = 0
rx_dropped = 0
  checksum = 805a5d2ea89c38cc35d38c66738c4620a143a589
   item_id = 7a60750dd3c25c53f21ff7f44b4743664ddbb66a

Second log "tx_bytes":37736961
Which is incorrect.

Proposal

Change all the fields causing issues to int64_t type, because the maximum value an INTEGER can take in a SQLite database is an INTEGER 8 bytes.

https://www.sqlite.org/datatype3.html

sebasfalcone · 2024-05-03T15:44:20Z

Issue blocked

Due to the update of the CTI content, which is handled in 4.8.0, some tests will continue to fail

We will wait until 4.8.0 is merged in this branch

MiguelazoDS added type/enhancement New feature or request level/task labels Jan 9, 2024

MiguelazoDS mentioned this issue Jan 18, 2024

router: ERROR: Error sending message to provider: Error parsing message 1: 563: error: invalid number: "-1960568724" #21539

Closed

vikman90 mentioned this issue Jan 29, 2024

Prevent macOS agent installation to start automatically #21637

Merged

2 tasks

MiguelazoDS self-assigned this Apr 30, 2024

MiguelazoDS linked a pull request May 1, 2024 that will close this issue

Fix network iface data type handling #23209

Open

4 tasks

sebasfalcone unassigned MiguelazoDS May 14, 2024

vikman90 added the module/syscollector label May 21, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bad syscollector network iface values handling #21296

Bad syscollector network iface values handling #21296

MiguelazoDS commented Jan 9, 2024 •

edited

Dwordcito commented Jan 9, 2024 •

edited

MiguelazoDS commented Apr 30, 2024 •

edited

sebasfalcone commented May 3, 2024

Bad syscollector network iface values handling #21296

Bad syscollector network iface values handling #21296

Comments

MiguelazoDS commented Jan 9, 2024 • edited

Description

DoD

Dwordcito commented Jan 9, 2024 • edited

MiguelazoDS commented Apr 30, 2024 • edited

Analysis

Error reproduced

Syscollector sync case

Syscollector delta case

Proposal

sebasfalcone commented May 3, 2024

Issue blocked

MiguelazoDS commented Jan 9, 2024 •

edited

Dwordcito commented Jan 9, 2024 •

edited

MiguelazoDS commented Apr 30, 2024 •

edited