Bug 2075074 (CVE-2022-1348) - CVE-2022-1348 logrotate: potential DoS from unprivileged users via the state file
Summary: CVE-2022-1348 logrotate: potential DoS from unprivileged users via the state ...
Keywords:
Status: NEW
Alias: CVE-2022-1348
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 2075221 2090272
Blocks: 2073997 2075165
TreeView+ depends on / blocked
 
Reported: 2022-04-13 14:31 UTC by Guilherme de Almeida Suckevicz
Modified: 2022-05-25 15:37 UTC (History)
11 users (show)

Fixed In Version: logrotate-3.20.1
Doc Type: If docs needed, set a value
Doc Text:
A vulnerability was found in logrotate in how the state file is created. The state file is used to prevent parallel executions of multiple instances of logrotate by acquiring and releasing a file lock. When the state file does not exist, it is created with world-readable permission, allowing an unprivileged user to lock the state file, stopping any rotation.
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Guilherme de Almeida Suckevicz 2022-04-13 14:31:36 UTC
A vulnerability was found in logrotate in versions 3.17.0 and newer in the way the state file is created. The state file is used to prevent parallel executions of multiple instances of logrotate by acquiring and releasing a file lock. When the state file does not exist, it is created with a default permission mode of 0644, and with an umask of 0022 results in a world-readable file allowing an unprivileged user to lock the state file, stopping any rotation.

References:
https://github.com/logrotate/logrotate/blame/master/logrotate.c#L3015-L3017
https://github.com/logrotate/logrotate/commit/f46d0bdfc9c53515c13880c501f4d2e1e7dd8b25

Comment 5 Kamil Dudka 2022-05-05 13:01:17 UTC
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?

Comment 6 Guilherme de Almeida Suckevicz 2022-05-05 13:21:52 UTC
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.

Comment 7 Kamil Dudka 2022-05-05 14:09:46 UTC
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?

Comment 8 Guilherme de Almeida Suckevicz 2022-05-06 13:19:38 UTC
Yes, security announcements are usually not done on Fridays.

May 25th sounds good.

Comment 11 Kamil Dudka 2022-05-18 08:27:38 UTC
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

Comment 14 Kamil Dudka 2022-05-25 07:15:36 UTC
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

Comment 15 Kamil Dudka 2022-05-25 07:39:44 UTC
Upstream fix for CVE-2022-1348:

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

Comment 16 Kamil Dudka 2022-05-25 08:08:13 UTC
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

Comment 18 Guilherme de Almeida Suckevicz 2022-05-25 13:16:16 UTC
Created logrotate tracking bugs for this issue:

Affects: fedora-all [bug 2090272]

Comment 19 Kamil Dudka 2022-05-25 15:37:42 UTC
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


Note You need to log in before you can comment on or make changes to this bug.