Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Files not scanned on update or change #147

Closed
kriegerse opened this issue Oct 9, 2024 · 5 comments
Closed

Files not scanned on update or change #147

kriegerse opened this issue Oct 9, 2024 · 5 comments
Assignees

Comments

@kriegerse
Copy link

Description

I recognized that files once scanned are not re-scanned on update or change by (remote) clients.
This open a door to distribute corrupted files marked as clean and is not the expected behavior of end users.

Reproduce

  1. upload a clean file with nextcloud client to the server
  2. wait until initial scan happen and file is marked with the clean tag
  3. upload a file with eicar signature overwriting the file created before (e.g. from https://www.eicar.org/download/eicar_com-zip)
  4. wait a couple of hours (the updated file is not scanned anymore)

This can easily misused by replace files marked as clean before to distribute vulnerable files afterwards.

Expected behavior / Proposal

  • GData VaaS should re-scan any files received an activity/change since initial scan

It might be related to #144 and can be addressed by an own managed database table keeping track of files processed as mentioned in #144 (comment).

My idea would be to store the date scanned or checksum of an file id within that GData_VaaS_table (etag might be also a candidate).

  • If a fileid in oc_filecache does not appear in GData_VaaS_table: scan it
  • If a fileid in oc_filecache appear in GData_VaaS_table has the same (mtime and checksum and etag): skip scan
  • If a fileid in oc_filecache appear in GData_VaaS_table but has different (mtime or checksum or etag): scan it

The tags on the file are just informative to the end user to easily identify potential dangerously files. But should not be the source of truth about what to scan.

Versions

  • Nextcloud Hub 8 [29.0.7]
  • Gdatavaas [29.4.3]
@GermanCoding
Copy link
Contributor

Hi again, thanks for reporting!

FYI, we currently have kind of a "sick wave" with influenza and such being passed around. We therefore haven't had much time to look into this yet, but we will get to it when we can. We appreciate the reports!

@pstadermann
Copy link
Contributor

We cannot reproduce this with the Web UI.

Which Nextcloud client are you using?

@kriegerse
Copy link
Author

Sorry for the delayed response, was on a business trip past week.

My scenario is not about the file upload within the web UI what is working well but the remote client(s).

Specifically I running a Linux Box (Linux Mint 22 aka Ubuntu 24.04 LTS) with the nextcloud desktop client.

  • upload a clean file will mark the file as "clean" on next scan job (cron) - I enforced it by manual scan
  • than replace the clean file on the desktop by one with e.g. eicar signature
  • the file will upload but keep the clean tag
  • the file is never scanned again (because it was marked as "clean" by a tag) and if I understood the SQL in Possibly expensive SQL Query on determining files to process #144 correct this will never elect the file again for scan

I assume other remote clients and OS behave similar.

From my point of view rely on tags here is not a good idea as they are not reset on file update (for good reasons).

@lennartdohmann lennartdohmann self-assigned this Oct 28, 2024
@lennartdohmann lennartdohmann linked a pull request Nov 5, 2024 that will close this issue
@lennartdohmann
Copy link
Contributor

Linked to #157

@lennartdohmann
Copy link
Contributor

Done with #160 in next release 30.1.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants