Cobbler before 3.3.0 allows log poisoning, and resultant Remote Code Execution, via an XMLRPC method that logs to the logfile for template injection.

Cobbler before 3.3.0 allows arbitrary file write operations via uploadlogdata.

Cobbler before 3.3.0 allows authorization bypass for modification of settings.

Cobbler version up to 2.8.2 is vulnerable to a command injection vulnerability in the "add repo" component resulting in arbitrary code execution as root user.

An issue was discovered in Cobbler before 3.3.1. Files in /etc/cobbler are world readable. Two of those files contain some sensitive information that can be exposed to a local user who has non-privileged access to the server. The users.digest file contains the sha2-512 digest of users in a Cobbler local installation. In the case of an easy-to-guess password, it's trivial to obtain the plaintext string. The settings.yaml file contains secrets such as the hashed default password.

Impact

If PAM is correctly configured and a user account is set to expired, the expired user-account is still able to successfully log into Cobbler in all places (Web UI, CLI & XMLRPC-API).

The same applies to user accounts with passwords set to be expired.

Patches

There is a patch for the latest Cobbler 3.3.2 available, however a backport will be done for 3.2.x.

Workarounds

- Delete expired accounts which are able to access Cobbler via PAM. - Use chage -l <username> to lock the account. If the account has SSH-Keys attached then remove them completely.

References

- Originally discovered by @ysf at https://www.huntr.dev/bounties/c458b868-63df-414e-af10-47e3745caa1d/

How to test if my Cobbler instance is affected?

The following pytest test assumes that your PAM setup is correct. In case the added user is not able to login, this test does not make sense to be executed.

python def testpamloginwithexpireduser(): # Arrange # create pam testuser testusername = "expireduser" testpassword = "password" testapi = CobblerAPI() subprocess1 = subprocess.run( ["perl", "-e", "'print crypt(\"%s\", \"%s\")'" % (testusername, testpassword)], stdout=subprocess.PIPE ) subprocess.run(["useradd", "-p", subprocess1.stdout, testusername]) # change user to be expired subprocess.run(["chage", "-E0", testusername])

# Act result = pam.authenticate(testapi, testusername, testpassword)

# Assert - login should fail assert not result

For more information If you have any questions or comments about this advisory: Open an issue in the Cobbler repository Ask in the Gitter/Matrix Chat Email us at cobbler.project@gmail.com

An issue was discovered in Cobbler before 3.3.1. In the templar.py file, the function checkforinvalidimports can allow Cheetah code to import Python modules via the "#from MODULE import" substring. (Only lines beginning with #import are blocked.)

The setmgmtparameters function in item.py in cobbler before 2.2.2 allows context-dependent attackers to execute arbitrary code via vectors related to the use of the yaml.load function instead of the yaml.safeload function, as demonstrated using Puppet.

A flaw was found in cobbler software component version 2.6.11-1. It suffers from an invalid parameter validation vulnerability, leading the arbitrary file reading. The flaw is triggered by navigating to a vulnerable URL via cobbler-web on a default installation.

Cobbler CobblerXMLRPCInterface object exposes all its functions over XMLRPC. This allows an attacker to use internal the internal functions of the class, such as creating a token, or upload files.

Upstream issue:

https://github.com/cobbler/cobbler/issues/1916

Upstream patch:

https://github.com/cobbler/cobbler/pull/1921

References:

https://movermeyer.com/2018-08-02-privilege-escalation-exploits-in-cobblers-api/

An issue was discovered in Cobbler through 3.3.1. Routines in several files use the HTTP protocol instead of the more secure HTTPS.