There was a vulnerability brought to attention of a privelege escalation in how FOG has previously used NFS.

The specific vulnerability was using options “no_root_squash” and “insecure” as definitions of the exports file.

The insecure option effectively allowed any system on non-priveleged ports (anything > 1024 which we defaulted to for NFS) had root level access to the filesystem.

The no_root_squash allowed a client system to mount the NFS share and if a client UID matched the UID of the server the files would be created as that user (say client had user named bob with UID 1000, and server had user named admin with UID 1000, NFS on the server would show “admin” created the file). It also allowed root (UID 0) on a clients machine to create files - scripts and all - as root on the server.

If I understand the depth, once that client root level created a file that contained code to escalate privilege, anyone could mount the NFS share and use that bad acting file to elevate as root on the server system.

Luckily this had a relatively easy fix and this fix has been implemented to dev-branch and working-1.6 from an installer standpoint.

Since I don’t know when a “full” release will be made I am outlining the steps you should/will need to take to correct the issue in the meantime.

Here’s a diff of the master to include these changes in an automated fashion if you feel comfortable doing this:

diff --git a/lib/common/functions.sh b/lib/common/functions.sh
index b20b0e482..44f8657f5 100755
--- a/lib/common/functions.sh
+++ b/lib/common/functions.sh
@@ -1357,7 +1357,9 @@ configureNFS() {
         echo "Skipped"
     else
         mv -fv "${nfsconfig}" "${nfsconfig}.${timestamp}" >>$error_log 2>&1
-        echo -e "$storageLocation *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)\n$storageLocation/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)" > "$nfsconfig"
+        userId=$(id -u $username)
+        groupId=$(id -g $username)
+        echo -e "$storageLocation *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,all_squash,anonuid=${userId},anongid=${groupId},fsid=0)\n$storageLocation/dev *(rw,async,no_wdelay,no_subtree_check,all_squash,anonuid=${userId},anongid=${groupId},fsid=1)" > "$nfsconfig"
         diffconfig "${nfsconfig}"
         errorStat $?
         dots "Setting up and starting RPCBind"
@@ -1569,8 +1571,8 @@ configureStorage() {
     else
         (head -1 "$storageLocationCapture/postinitscripts/fog.postinit" | grep -q '^#!/bin/bash') || sed -i '1i#!/bin/bash' "$storageLocationCapture/postinitscripts/fog.postinit" >/dev/null 2>&1
     fi
-    chmod -R 777 $storageLocation $storageLocationCapture >>$error_log 2>&1
-    chown -R $username $storageLocation $storageLocationCapture >>$error_log 2>&1
+    chmod -R 775 $storageLocation $storageLocationCapture >>$error_log 2>&1
+    chown -R $username:$username $storageLocation $storageLocationCapture >>$error_log 2>&1
     errorStat $?
 }
 clearScreen() {

Steps:
(If you rerun the installer please re-perform these steps to ensure things are as secure as possible)

1. Get your fogproject user’s user and group ids:
   echo "UserID: "$(id -u fogproject); echo "GroupID: "$(id -g fogproject)
2. Note these down and edit your systems export file (usually located in /etc/exports)
   Remove the no_root_squash and replace with all_squash in both instances
   Remove the insecure, from both instances
3. Add: anonuid=<UserID>,anongid=<GroupID> to both instances
   Please replace <UserID> with the actual userID returned, and <GroupID> with the actual groupID returned.
   You should end up with an exports that looks like:

/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,all_squash,anonuid=1001,anongid=1001,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,all_squash,anonuid=1001,anongid=1001,fsid=1)

4. Change filesystem permissions of /images to at least chmod -R 775 /images (Not necessary, but useful for an extra bit of security)
5. Change owner ship of /images to fogproject/fogproject chown -R fogproject:fogproject /images
6. Restart nfsd: systemctl restart nfsd
7. Test.

This should address the vulnerabilty. While it won’t prevent a “bad actor” from placing a new file on your system the max level of that escalation could only be that of your fogproject user.

I know this isn’t a good way to start a Monday, but when is a good time when it comes to security issues?

Hopefully this will help and is simple enough to work in the mean time. Those who don’t mind, please use dev-branch for simplicity as it should address this in a more autonomous method.

Thank you all in advance!

Particularly, thank you Christophe Hugueny (Advens) @IronBlackBird

I don’t recall, and it has been a while since I did direct troubleshooting with fog. I can still read of course and probabaly help in that way, but my systems are limited as of late and as such harder for me to troubleshoot issues to try to replicate.

Majority of the time the Inits are built one off for some specific need. No where near the frequency of the kernels needing to be updated.

I don’t think that’s true. We do bug fixes and add features to the inits way more often than once a year (when at least the buildroot update is to be done). Take a look at the last dozen or so fos repo commits.

I don’t want to stop contributing, I just am taking time for myself after my workly duties.

I have to give a big gratitude and thanks for everyone here trying to help out whether by code, by helping the rest of the community, or documentation.

@Sebastian-Roth I know you’re busy but you’ve kept the project rolling even with the minimal availability you have. Thank you.
@george1421 I’m sure you’re busy, but I still see you posting and helping where possible and amenible. Thank you.
@Wayne-Workman I know you’re helping where you can as well. (Of course I can’t exactly post everybody because I’ve been busy and honestly not keeping up with the forums as much as I probably should.)

@everyone Thank you. Thank you for still believing in this project. We’re doing the best with what we have. Please understand in we’re lacking, it’s most likely unintentional. I know I’m just busy.

Yes here -> https://github.com/FOGProject/fogproject/compare/1.5.8...1.5.9

I wanted to inform you all that on attempting to upgrade the forum software this morning, the folder was accidentally cleaned. While we do keep backups of most of our stuff, the forum folders is not one of them due to the dynamic nature of all the data contained within.

The database was unaffected, just the upload of images were.

I’m attempting to see if any of the backups we have contain some of the data, but I’m not holding my breath at this point.

I’m sorry for any issue this may have caused. I will repost here with any update I can provide.

Thank you,

https://news.fogproject.org/fog-1-5-9-rc2-available/

https://news.fogproject.org/fog-1-5-9-rc1-available/

Just wanted to state that I’ve made a slight feature adjustment/improvement to the LDAP plugin.

You can now decide to use an AD displayName field for the environment.

Hopefully this makes sense and makes things a little nicer. It does mean to see the changes and make changes, you will have to remove and re-add the plugin. This isn’t overly difficult, just try to remember to get your configuration before hand.

Just an example:

And for creating the new LDAP item:

is there No Effect on Stored Images after upgrading FOG ?

No, there shouldn’t be any effect on the images but make sure you read all the information on upgrading in the link posted by Tom if you have storage nodes!!!

nice to hear from you, all the best…

It’s not time to make a change
Just relax, take it easy
You’re still young, that’s your fault
There’s so much you have to know
Look at me
I am old, but I’m happy

I was once like you are now
And I know that it’s not easy
To be calm when you’ve found
Something going on
But take your time, think a lot
Why, think of everything you’ve got
For you will still be here tomorrow
But your dreams may not

Regards Cat 😉