The original Japanese version is available here.
I was looking at my company’s emails and I received a security update email for FreeBSD 13.1-RELEASE-p5. I thought I might see the same thing in my home laboratory, and I found the same email. I have temporarily set up system reports to be sent to gmail.com for sendmail in a different series of articles, so this will be a screenshot of a gmail.com email, but this is what the email looks like.
The last time 13.1-RELEASE-p4 was released, I tried to update p4 with the freebsd-update command and suffered badly. Upon careful investigation, I found out that it was a bug that was posted on the mailing list. When I remembered the list of update files from that time, it was mostly related to krb5 files. I thought since there was no kernel file, a restart was not necessary, so I quickly updated, but after that authentication failed and ipropd synchronization stopped, and kinit became unusable. I had to roll back to p3 because the password related functions went into serious situation. This time, as well, krb5 related files are mostly involved, so I can imagine it being an update to fix the bug. So let’s try to upgrade to p5. Let’s start by upgrading krb5 to p5.
I will update using the freebsd-update command.
According to what arrived in the email, it seems that the update to p5 is available.
It seems that the updates are mostly related to krb5, except for /rescue.
I will install the update using the freebsd-update command and try a restart as a test. Since there are no updates to the kernel files, a restart is not necessary, but I will try to reproduce the same situation for clarity and to verify the update.
Last time, the symptoms were discovered because I was unable to use the same kerberos ticket for ssh login that I had obtained with kinit. So, I will try to login with the same ticket using ssh.
It seems that the same ticket was usable without any issues this time. The kernel appears to still be on p3.
The next symptom was that I couldn’t get a ticket with kinit, so I’ll try the same thing.
It seems to be okay, so I guess it’s fine 🙂 Software created by humans can have bugs, and we often see bugs that appear under specific conditions, but it’s been a while since I’ve seen a bug that appears unconditionally 🙂 In addition to updating the OS, there was a security report in the email below that ruby has vulnerabilities, so let’s also update the ports to the latest version.
Since there was no similar security information after the last update, the ports tree remains unchanged, so I will update the tree.
After updating, it seems that ruby is still at the latest version.
Here is the detailed information. According to this information, it is necessary to update to ruby 3.0.5,1 or higher. The update is not yet available, so I will check again after a short time. The original can be viewed here.
Well, it’s been about three days since I checked last time. Let me check again if there are any updates.
It seems that there is an update for ruby.
I will compile and install the update, along with the other updates.
Incidentally, the root certificate package appears to be updated. It might be wise to also check the usage of the root certificate using a legitimate certificate in other parts in the operating system, in case it requires any changes in configuration. There may be instances where adjustments in configuration would be advisable.
After the update is completed, I will check if the version of ruby is the one without any known security issues. According to the site vuxml.org, ruby 3.0.5,1 is OK, so it seems to be safe.
Since some time has passed, I will double check if there are any updates for the OS as well.
It seems not. This time, it doesn’t seem like any updates were done to the processes running as a service, but updates were done to the libraries related to Kerberos. Some of the resident processes will need to be restarted. For example, the kdc. So, we will do the same on other FreeBSD. Let’s make sure to plug up any security holes.
Advertisement below
コメント