This morning we were contacted by the security team saying that a vulerablity had been found on our Harvest server in regards to Unix World-Writable files. The files in question are in /opt/harvest/asup/payload/clusterORfsx_payload.json. Do these files need to be rwxrwxrwx? There is also another file in /opt/harvest/asup/spool/harvest with rw and it's a tgz file.
#Harvest and recent security scan
1 messages · Page 1 of 1 (latest)
hi @fleet bolt thanks for raising this. Those files are Harvest's auto-support files and they do not need to be world writable. We'll fix in nightly and ping you when the pull request has been reviewed and passed CI
https://github.com/NetApp/harvest/issues/2192
thanks!
Have the updates been made on the nightlies?
@fleet bolt It is not yet in. There is an ongoing PR. We'll update you once it is available.
ok thanks
@fleet bolt Could you please specify the type of installation for Harvest? Is it RPM, DEB, Docker, NaBox, or Native?
RPM
Thanks
hi @fleet bolt nightly has a fix for the issue you raised. When you get a chance, please let us know if this fixes the issue for you. Thanks! https://github.com/NetApp/harvest/releases/tag/nightly We've also added file/dir permissions linters to make sure this doesn't happen in the future
the payload files are still rwxrwxrwx
how long it has been since upgrade?
about two hours ago
could you share output of bin/harvest version if you run it from harvest installation dir. in rpm it should be /opt/harvest
oh wait, this is my fault I installed 23.07.10 by mistake
ok just upgraded, is there a way I can manually trigger an ASUP to see if the fix worked?
Permissions should get auto correct with in next 10 mins
There is no manual way to trigger asup generation currently.
ok
@fleet bolt Could you check the permissions now?
they are now rw------- so we're good
Thanks!
I don't see an /opt/harvest/asup/spool directory yet, I assume that will populate at some point?
yes that will get created after 24 hours.
ok thanks
So I just checked and the tar file in /opt/harvest/asup/spool/harvest is still rw-rw-rw-
hi @fleet bolt can you check with ls -la and see if the tar file with 666 permissions was created earlier, i.e. before this was fixed or if that tar gz was created after the nightly you deployed yesterday?
no it was created an hour ago
the spool directory wasn't there yesterday after I upgraded to the 7.11 nightly
thanks for the confirmation! right, I recall you mentioning that. Sorry about the miss here, we'll fix it. Feel free to rm the spool directory in the meantime if your system is getting flagged
ok
hi @fleet bolt I downloaded the rpm you used to a local linux box, uncompressed it and ran the asup executable directly so I could check the permissions of the spool and tgz files that are created. Here's what I did.
- uncompressed rpm into
/tmp - cd
/tmp/harvest-23.07.11-nightly.x86_64/opt/harvest/autosupport ./asup --payload /opt/harvest/asup/payload/umeng_aff300_payload.json --working-dir foo
theumeng_aff300_payload.jsonis from a previous run- checked permissions of
fooandfoo/spool/harvest- they all look correct
Let's check and make sure we are using the same version.
What does this print for you?
/opt/harvest/autosupport/asup --version
asup version 23.07.11-nightly (commit e25f18b) (build date 2023-07-11T00:23:48-0400) endpoint: stable linux/amd64
same
excellent, was getting ready to ask if you wanted to try that 🙂 the behavior you describe almost sounds like last night's tgz and spool directory were created by an earlier version of Harvest and the test you just did was done with nightly. That would happen if RPM upgrade installed the new files, but did not restart existing pollers. Let's check when the poller that wrote the wrong permissions was started via ps aux | grep poller This will show us the process start time and the date should be Jul11 in your case
Jul 11th before I ran the upgrade
ah! ok sounds like that's it
I did upgrade twice, I mistakenly installed the 7-10 nightly, realized my mistake and installed the 7-11 nightly
sounds like if you bounce your pollers, they'll restart using the 7-11 nightly code and you should be good to go. If you want to verify one of them without waiting you can run with an environment variable that tells Harvest to invoke autosupport 4m after startup instead of waiting 24 hours. Might be worth rm -rf the asup directory to start from a clean slate. To run with env var use this ASUP=1 bin/harvest restart $pollerName
Just wanted to confirm that the .tgz file has the correct permissions this morning. We're good.