5210R: Critical Security Flaw identified. Updates available

Posted by: mstauber Category: General

A critical security flaw in BlueOnyx 5210R has been found, which allows privilege escalation of users that are not jailed. You are urged to install the BlueOnyx 5210R security updates ASAP.

This is a full disclosure press release and it certainly will see several revisions and updates until it gets all necessary facts across and all information out that need to be out. This is the first time I've had to report a critical security flaw in BlueOnyx in 12 years, so I'll try to get it right:

Affected Platforms:

BlueOnyx 5210R on CentOS 8

Type of vulnerability:

Root privilege escalation. Already logged in (but not jailed) users could potentially abuse a root level (UID:0, GID:0) account that had been created without password, but with shell.

Mitigation:

YUM updates have been released. To make sure you are fully up to date please run these commands on your BlueOnyx 5210R:

yum clean all
yum update

To confirm that your BlueOnyx 5210R is fully up to date and no longer affected by this security issue, you can run this command:

/usr/sausalito/sbin/root-admin-fix.sh

The returned information should then make it clear if the issue was fixed.

Acknowledgement:

Many thanks to Maurice de Laat for reporting this issue.

Timeline of the events:

08:31 GMT-5 Initial notification of potential problem posted to the BlueOnyx mailing list.
13:45 GMT-5 Reply sent to mailing list, but still not grasping the initial problem.
14:57 GMT-5 Second message on list that clearly outlines the severity of the reported issue.
15:09 GMT-5 Mailing list taken offline to curtail information flow while issue is diagnosed and patches are being worked on.
15:15 GMT-5 Installation of fresh 5210R off latest ISO into test-VM started in unattended mode.
15:16 GMT-5 Start of development of Hotfix in "Swatch" component of "Active Monitor" on existing (older) test-5210R started.
16:14 GMT-5 Published "Swatch" Hotfix to SVN
16:17 GMT-5 "Swatch" Hotfix published to Mirrors
16:19 GMT-5 Mirrors synched manually
16:20 GMT-5 Diagnostics on post-install in VM with freshly installed 5210R started
18:50 GMT-5 All problems identified and fixed on test-VM
19:12 GMT-5 Code changes in base-user.mod uploaded to SVN
19:15 GMT-5 RPMs built, tested and published
19:30 GMT-5 Start of documenting said issue in this text.
20:00 GMT-5 Initial publication of first draft of this text

Detailed Post-Mortem of the underlying issue:

One of the key differences of BlueOnyx 5210R which sets it apart from its predecessors is the integration of Jailkit jails. This has been an integral feature of BlueOnyx 5210R since its release in early October 2019. This security flaw was introduced into BlueOnyx 5210R due to coding errors in our integration of the Jailkit functionality. Our custom Perl module Base::User now had different exit states for some transactions and in one handler it had been forgotten to take the new exit states into account. If that handler was called, it would try to do it's job, failed at it and the error message was ignored.

This created a failure cascade that ran unnoticed, because the only indication would have been a briefly noticed handler failure during initial setup of the server.

So here is what happened during a typical BlueOnyx 5210R initial setup. And it didn't matter if it was off an ISO image, via YUM install or any other way: During first start of CCEd the constructors run and one of them checks if the "admin" account is already present on the server.

If it is not, then this constructor will create user "admin" with password "blueonyx". This also triggers the creation of user "root-admin", which we need for the way our server administrator integration handles allowed privilege escalation from server admin to "root". After all, there can be multiple server administrators with granted root privileges.

During the creation of the super-user 'root-admin' he is supposed to get the same password (or password-hash) as user 'admin'. And this is where the failure cascade now starts:

  1. Creation of user "admin" has started. While it is running, it already triggers creation of user "root-admin".
  2. Handler for creation of "root-admin" checks what password or password-hash should be set for user "root-admin".
  3. Special clause fires: "root-*" users inherit the password-hash from the server admin account they belong to. We pull this information from CODB.
  4. But: User "admin" has not yet finished creation and the password-hash for him is not yet stored in CODB.
  5. Module Base::User's "useradd" command receives the order to create user "root-admin" and uses -p "$password" to create the user. But $password is empty. Ideally (and done so in previous versions of BlueOnyx) the -p "$password" should have been left out entirely. Which would have created the account, but left it in the state "locked". Instead the faulty code left us with a "root-admin" account that had no password.

So far, so bad.

You'd think that at least changing the "admin" password would fix it, no? Sadly, it didn't: At the end of the Web Based Initial Setup of BlueOnyx 5210R the "admin" password set by the server owner is stored into CODB. The "root" password is updated with it, too. Likewise the backend attempts to set the same new password hash for "root-admin", but fails. The password for "root-admin" was in fact never changed or updated again and remained empty.

The only saving grace: This only happened during initial setup. All other server administrator accounts that were later on created via the GUI and received "root" privileges all got their password set correctly. Still: Bad enough.

The fixes boil down to changes in one handler where the correct exit state from Base::User::usermod() needed to be taken into account. Then a runtime issue needed to be addressed in Base::User and it had to be made sure that useradd or usermod do NOT run with the parameter to set an empty password. Lastly some changes needed to be made to the handler that deals with the creation of server administrator accounts such as "root-admin". Provisions were added to it to check the presence of a password after account creation and a mechanism was added which would set the password-hash if it was still missing.

Closing words:

4082 days have passed since the first release of BlueOnyx and we now have to report the first home made critical security flaw that wasn't introduced by the OS itself. So today was not a good day. We'll try to do better.


Return
General
Mar 5, 2020 Category: General Posted by: mstauber
Previous page: API Documentation Next page: Downloads