Dear FOG security team,
Summary
There is a security issue with the NFS configuration in /etc/exports generated by the installer that allows an attacker to modify files outside the export in the default installation.
I have tested this on commit f993bcf on the dev-branch.
Description
Currently /etc/exports has the following configuration.
/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)
Both exports have the no_subtree_check option.
The no_subtree_check option means that if a client performs a file operation, the server will only check if the requested file is on the correct filesystem, not if it is in the correct directory.
This can lead to three possible attacks.
All three attacks have been successfully tested on the default installation of the FOG server on Debian 12 where everything is installed on a single ext4 filesystem.
The attacks should also work on Red Hat with xfs but I haven't tested it.
1. Modifying files in /images
If the directories /images and /images/dev are on the same partition, an attacker can modify the files in /images.
This would allow an unauthenticated attacker to modify the images without knowing the FTP password.
The attack works by taking the file handle of the /images/dev directory and replacing the inode and generation number with the values that can be found in the file handle of the /images directory. The NFS server will not check if the directory is actually in the export but will allow write operations because it assumes that /images is inside the /images/dev export.
2. Accessing other files on the same filesystem
If all directories related to FOG are on the same partition, an attacker can also read and modify other files that are accessible to the fogproject user, for example the ones in /tftpboot.
Other files cannot be accessed because all UIDs are squashed to fogproject.
Debian and Red Hat use ext4 and xfs where the filesystem root directory always has the same inode and generation number.
An attacker can take the file handle of /images/dev and replace the inode and generation number with these known values in order to get access to the filesystem root directory.
The attacker can use this manipulated file handle to request file handles for all other files on the same filesystem from the server.
3. Accessing files on other filesystems
If /images and /images/dev are on the same partition, an attacker can remove the /images/dev directory and replace it with a symbolic link to any other directory on the server.
When the NFS service restarts, it will export the directory that the symlink points to, which allows an attacker to also access any filesystem on the server, not just the one that contains the NFS export.
Like the previous attack, the impact of this attack is limited because all file operations will be performed as the fogproject user.
PoC
There is no simple PoC because it requires a malicious NFS client that manipulates file handles.
I am currently developing such a tool which is not yet public in order to automatically detect this type of misconfiguration.
I successfully performed all three attacks using that tool.
Suggested fix
To fix this issue, the option no_subtree_check should be replaced with subtree_check for both exports.
I wasn't able to perform any of the attacks after enabling subtree_check.
However, subtree_check can cause errors if a file is moved while a client is still accessing it.
I tested some captures and deploys on a small test system with subtree_check enabled and it worked but I don't know if there is a case where this access pattern occurs in FOG.
The recommendation for Linux NFS is to only export the root of a filesystem and to use the subtree_check option if that is not possible.
More information can be found in the exports(5) man page in the nfs-utils repository.
Nesting subdirectory exports (in this case /images/dev inside of /images) is problematic in general but it should be fine in this case because /images is readonly. If it was writable an attacker could still perform the third attack even if subtree_check was enabled.
If you have any questions or need more information, feel free to ask me.
Kind Regards,
Philipp Tekeser-Glasz <[email protected]>
philipp-tg Reporter
Dear FOG security team,
Summary
There is a security issue with the NFS configuration in /etc/exports generated by the installer that allows an attacker to modify files outside the export in the default installation.
I have tested this on commit f993bcf on the dev-branch.
Description
Currently /etc/exports has the following configuration.
Both exports have the no_subtree_check option.
The no_subtree_check option means that if a client performs a file operation, the server will only check if the requested file is on the correct filesystem, not if it is in the correct directory.
This can lead to three possible attacks.
All three attacks have been successfully tested on the default installation of the FOG server on Debian 12 where everything is installed on a single ext4 filesystem.
The attacks should also work on Red Hat with xfs but I haven't tested it.
1. Modifying files in /images
If the directories /images and /images/dev are on the same partition, an attacker can modify the files in /images.
This would allow an unauthenticated attacker to modify the images without knowing the FTP password.
The attack works by taking the file handle of the /images/dev directory and replacing the inode and generation number with the values that can be found in the file handle of the /images directory. The NFS server will not check if the directory is actually in the export but will allow write operations because it assumes that /images is inside the /images/dev export.
2. Accessing other files on the same filesystem
If all directories related to FOG are on the same partition, an attacker can also read and modify other files that are accessible to the fogproject user, for example the ones in /tftpboot.
Other files cannot be accessed because all UIDs are squashed to fogproject.
Debian and Red Hat use ext4 and xfs where the filesystem root directory always has the same inode and generation number.
An attacker can take the file handle of /images/dev and replace the inode and generation number with these known values in order to get access to the filesystem root directory.
The attacker can use this manipulated file handle to request file handles for all other files on the same filesystem from the server.
3. Accessing files on other filesystems
If /images and /images/dev are on the same partition, an attacker can remove the /images/dev directory and replace it with a symbolic link to any other directory on the server.
When the NFS service restarts, it will export the directory that the symlink points to, which allows an attacker to also access any filesystem on the server, not just the one that contains the NFS export.
Like the previous attack, the impact of this attack is limited because all file operations will be performed as the fogproject user.
PoC
There is no simple PoC because it requires a malicious NFS client that manipulates file handles.
I am currently developing such a tool which is not yet public in order to automatically detect this type of misconfiguration.
I successfully performed all three attacks using that tool.
Suggested fix
To fix this issue, the option no_subtree_check should be replaced with subtree_check for both exports.
I wasn't able to perform any of the attacks after enabling subtree_check.
However, subtree_check can cause errors if a file is moved while a client is still accessing it.
I tested some captures and deploys on a small test system with subtree_check enabled and it worked but I don't know if there is a case where this access pattern occurs in FOG.
The recommendation for Linux NFS is to only export the root of a filesystem and to use the subtree_check option if that is not possible.
More information can be found in the exports(5) man page in the nfs-utils repository.
Nesting subdirectory exports (in this case /images/dev inside of /images) is problematic in general but it should be fine in this case because /images is readonly. If it was writable an attacker could still perform the third attack even if subtree_check was enabled.
If you have any questions or need more information, feel free to ask me.
Kind Regards,
Philipp Tekeser-Glasz <[email protected]>