Bug #2005
closedIncoherent sizes between request, capture and http length
Description
The information in fileinfo section about file size is not matching the http length and the size of the stored file.
For instance in the following event:
```
{
"timestamp": "2017-01-17T12:45:54.979958-0800",
"flow_id": 588945285071930,
"in_iface": "wlan0",
"event_type": "fileinfo",
"src_ip": "82.165.177.154",
"src_port": 80,
"dest_ip": "10.10.17.19",
"dest_port": 49086,
"proto": "TCP",
"http": {
"hostname": "testmyids.com",
"url": "/CVE/AR/CVE-2010-2883.pdf",
"http_user_agent": "Wget/1.18 (linux-gnu)",
"http_content_type": "application/pdf",
"http_method": "GET",
"protocol": "HTTP/1.1",
"status": 200,
"length": 46518
},
"app_proto": "http",
"fileinfo": {
"filename": "/CVE/AR/CVE-2010-2883.pdf",
"state": "CLOSED",
"md5": "e3c907b79797ecd7454bf76cc5b79196",
"sha256": "6e8070cd974d275351a557148df0d486792541f4c3b9aec12fa065699cebebe7",
"stored": false,
"size": 1170,
"tx_id": 0
}
}
```
The file size is around 46518 and not near to 1170. In this event, the hash values are correct.
Updated by Victor Julien almost 8 years ago
If you enable file store, is it correct then?
The FileSize function looks a bit suspicious, it may depend on storing data.
Updated by Eric Leblond almost 8 years ago
yes, size is correct if filestore is used.
Updated by Victor Julien almost 8 years ago
Looking a bit more, it looks like the size depends on AppendData. However, in the no-store case this isn't called. I think we may need to bring back a separate size tracker.
Updated by Eric Leblond almost 8 years ago
Came to the same conclusion. I'm gonna spend a few hours on this today.
Updated by Victor Julien almost 8 years ago
In the old code the size was incremented before the 'no store' check: https://github.com/inliniac/suricata/commit/e43ce0a9ecc32fa1e574fc3c9e1bfc246a45bc01#diff-c55860046f9110db7359adf0c01b6f1cL495
Updated by Victor Julien almost 8 years ago
- Status changed from New to Closed
- Target version set to 3.2.1