Bug 2075074 (CVE-2022-1348)

What are the next steps?

I believe we can use the patch provided to me privately by Christian.

We should schedule the unembargo date to match the next release of logrotate (no specific date planned yet) and announce the issue securely to other software vendors, along with unembargo date and the patch?

The next step is to unembargo the flaw and to report the CVE to Mitre.

The unembargo date is up to reporter and upstream, Christian and you on this case. For us, the sooner the better, as this issue was rated with a moderate severity.

We can announce this issue to linux-distros mailing list, but they have a embargo policy and the maximum acceptable embargo period there is 14 days.

We used to release logrotate on Fridays, which is not optimal for announcement of a security issue I guess...

If we released logrotate-3.20.0 on Wednesday May 25th, would it work as unembargo date?

Yes, security announcements are usually not done on Fridays.

May 25th sounds good.

As pointed out by a member of openwall, we should also change the upstream spec file to reflect the permission change (and perhaps to defer its creation to the first run of logrotate?):

--- a/logrotate.spec.in
+++ b/logrotate.spec.in
@@ -41,7 +41,6 @@ install -p -m 644 examples/logrotate.conf $RPM_BUILD_ROOT%{_sysconfdir}/logrotat
 install -p -m 644 examples/btmp $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d/btmp
 install -p -m 644 examples/wtmp $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d/wtmp
 install -p -m 755 examples/logrotate.cron $RPM_BUILD_ROOT%{_sysconfdir}/cron.daily/logrotate
-touch $RPM_BUILD_ROOT%{_localstatedir}/lib/logrotate.status

 %clean
 rm -rf $RPM_BUILD_ROOT
@@ -55,4 +54,4 @@ rm -rf $RPM_BUILD_ROOT
 %attr(0755, root, root) %{_sysconfdir}/cron.daily/logrotate
 %attr(0644, root, root) %config(noreplace) %{_sysconfdir}/logrotate.conf
 %attr(0755, root, root) %{_sysconfdir}/logrotate.d
-%attr(0644, root, root) %verify(not size md5 mtime) %config(noreplace) %{_localstatedir}/lib/logrotate.status
+%ghost %attr(0640, root, root) %verify(not size md5 mtime) %{_localstatedir}/lib/logrotate.status

logrotate-3.20.0, which contains the fix for this security issue, has been released:

    https://github.com/logrotate/logrotate/releases/tag/3.20.0

Upstream fix for CVE-2022-1348:

    https://github.com/logrotate/logrotate/commit/1f76a381e2caa0603ae3dbc51ed0f1aa0d6658b9

I have realized that the code to remove the worl-readable permission bit on state file did not work well with ACLs.  The following upstream pull request should fix it:

    https://github.com/logrotate/logrotate/pull/446

Created logrotate tracking bugs for this issue:

Affects: fedora-all [bug 2090272]

A bug-fix release logrotate-3.20.1 has been released:

    https://github.com/logrotate/logrotate/releases/tag/3.20.1

The following two commits should be cherry-picked for older releases of logrotate (from 3.17.0 to 3.19.0):

    https://github.com/logrotate/logrotate/commit/1f76a381e2caa0603ae3dbc51ed0f1aa0d6658b9
    https://github.com/logrotate/logrotate/commit/addbd293242b0b78aa54f054e6c1d249451f137d

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2022:8393 https://access.redhat.com/errata/RHSA-2022:8393

the test for this issue fails also on older RHELs ... aren't we going to fix it there too, at least rhel8 which will have an erratum in 8.8?

In reply to comment #21:
> the test for this issue fails also on older RHELs ... aren't we going to fix
> it there too, at least rhel8 which will have an erratum in 8.8?

Hi, this issue was introduced in upstream in versions 3.17.0 and newer, rhel-8 ships logrotate-3.14 and does not contain the vulnerable code, therefore it's not affected.

Also, the security-response-team address is not monitored, so needinfo for this address has no affect.

Thanks.

State file locking was introduced in logrotate-3.17.0 while we have logrotate-3.14.0 in RHEL-8.  The security issue does not affect RHEL-8 for sure.  How exactly did the test fail?

In an affected version of logrotate, the test would fail like this:
```
Running test 92
reading config file test-config.92
error: state file state is already locked
logrotate does not support parallel execution on the same set of logfiles.
```

(In reply to Kamil Dudka from comment #23)
> State file locking was introduced in logrotate-3.17.0 while we have
> logrotate-3.14.0 in RHEL-8.  The security issue does not affect RHEL-8 for
> sure.  How exactly did the test fail?
> 
> In an affected version of logrotate, the test would fail like this:
> ```
> Running test 92
> reading config file test-config.92
> error: state file state is already locked
> logrotate does not support parallel execution on the same set of logfiles.
> ```

no, this message is not present, the test complains about file being readable -

:: [ 07:36:48 ] :: [  BEGIN   ] :: Running 'logrotate /etc/logrotate.conf'
:: [ 07:36:48 ] :: [   PASS   ] :: Command 'logrotate /etc/logrotate.conf' (Expected 0, got 0)
:: [ 07:36:49 ] :: [  BEGIN   ] :: Unpriviliged user shouldnt be able to read state file :: actually running 'su tester-cve-2022-1348 -c 'cat /var/lib/logrotate/logrotate.status''
logrotate state -- version 2
"/var/log/sssd/sssd_implicit_files.log" 2022-11-29-7:0:0
"/var/log/firewalld" 2022-11-29-7:0:0
"/var/log/sssd/sssd_nss.log" 2022-11-29-7:0:0
"/var/log/boot.log" 2022-11-29-7:0:0
"/var/log/up2date" 2022-11-29-7:0:0
"/var/log/hawkey.log" 2022-11-29-7:0:0
"/var/log/kvm_stat.csv" 2022-11-29-7:0:0
"/var/log/wtmp" 2022-11-29-7:0:0
"/var/log/chrony/*.log" 2022-11-29-7:0:0
"/var/log/sssd/sssd.log" 2022-11-29-7:0:0
"/var/log/spooler" 2022-11-29-7:0:0
"/var/log/btmp" 2022-11-29-7:0:0
"/var/log/rhsm/rhsmcertd.log" 2022-11-29-7:0:0
"/var/log/maillog" 2022-11-29-7:0:0
"/var/log/my_logDZZ" 2022-11-29-7:0:0
"/var/log/secure" 2022-11-29-7:0:0
"/var/log/rhsm/rhsm.log" 2022-11-29-7:0:0
"/var/log/messages" 2022-11-29-7:0:0
"/var/log/cron" 2022-11-29-7:0:0
:: [ 07:36:49 ] :: [   FAIL   ] :: Unpriviliged user shouldnt be able to read state file (Expected 1, got 0)



https://beaker.engineering.redhat.com/tasks/executed?recipe_task_id=153042320&recipe_task_id=153042541&recipe_task_id=153042436&recipe_task_id=153042599&recipe_task_id=153042378&recipe_task_id=153042657&old_pkg_tasks=153042541,153042657,153042599&new_pkg_tasks=153042320,153042378,153042436


so, if I get that right, the patch doesn't fix the core of the problem but rather prevents it from triggering, so the test checks whether the prevention is in place and not whether the problem really happens, which is irrelevant for older releases?

guess I should limit the test to run on RHEL 9+ only then ... sorry for the noise, I'm not the test author and this scenario is not something I had expected

I though you were talking about the upstream test [1].  The downstream test [2] seems correct but it is just not applicable on RHEL-8 and older.

To clarify the fix, it is not an issue if the state file is readable by non-privileged users in RHEL-8.  There is nothing secret in the file and if the file is locked on RHEL-8, nobody cares.  If a non-privileged user locks the state file on RHEL-9, they cause the system job triggered by logrotate.timer to fail with the error pasted in comment #23.  The code raising the error does not exist in RHEL-8 logrotate, so there is no CVE-2022-1348 in RHEL-8 logrotate.

[1] https://pkgs.devel.redhat.com/cgit/rpms/logrotate/tree/0004-logrotate-3.18.0-CVE-2022-1348.patch?h=rhel-9-main&id=b90be9f1f55909b15ef5298883461e560e62f2d3#n108
[2] https://pkgs.devel.redhat.com/cgit/tests/logrotate/tree/Security/CVE-2022-1348-logrotate-potential-dos-from-unpriviliged-users-via-the-state-file/runtest.sh?id=c261d6ad7ab3f6c73f7d70f999f75efc773ce198

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2022-1348