Bugzilla – Bug 1190474
VUL-0: CVE-2021-46705: grub2: grub2-once uses fixed file name in /var/tmp
Last modified: 2023-05-11 06:57:35 UTC
In /sbin/grub2-once: 181 my $cleanup = "/var/tmp/grub2-cleanup-once"; 182 183 open(my $fh, ">", $cleanup) or die "open: $cleanup $!\n"; 184 close($fh); Looks like that could be exploited by unprivileged users to get the sysadmin truncate arbitrary files by placing a symlink. Better use eg /run instead. # rpm -q grub2 grub2-2.06-6.1.x86_64
I decided to go for /var/tmp because I was reading the fhs doc [1] and /var/tmp looked appealing > Filesystem Hierarchy Standard - 5.15 /var/tmp : Temporary files preserved between system reboots ... The /run seems not able to preserve files across reboots. Actually Raymund has raised the same concern and we did have a discussion and planned to fix this problem a while back. The conclusion was to use /var/lib/misc for this well-known transient file iirc. Cc Raymund. [1] https://www.pathname.com/fhs/2.2/fhs-5.15.html
yeah if you need it preserved between reboots then /run is not the right place. I'd probably use a dedicated /var/lib/grub2 directory for that then though
(In reply to Ludwig Nussel from comment #2) > yeah if you need it preserved between reboots then /run is not the right > place. I'd probably use a dedicated /var/lib/grub2 directory for that then > though The directory will be empty most of the time given that grub2-once usually followed by reboot and file is cleared right on next boot up. That's the reason we prefer /var/lib/misc as it may be confusing to create a seemingly empty directory by the grub package. Thanks.
(In reply to Michael Chang from comment #3) > The directory will be empty most of the time given that grub2-once usually > followed by reboot and file is cleared right on next boot up. That's the > reason we prefer /var/lib/misc as it may be confusing to create a seemingly > empty directory by the grub package. You could place a README then explaining why the dir is most of the time empty ;)
(In reply to Franck Bui from comment #4) > (In reply to Michael Chang from comment #3) > > The directory will be empty most of the time given that grub2-once usually > > followed by reboot and file is cleared right on next boot up. That's the > > reason we prefer /var/lib/misc as it may be confusing to create a seemingly > > empty directory by the grub package. > > You could place a README then explaining why the dir is most of the time > empty ;) Then it is less confusing but becomes more irony. I'll drop README in a directory to signify it is going to be deprecated but not in a mandatory one. :)
I may need security team's advice on how to proceed. So far I have created a hidden obs project to verify a fix of using /var/lib/misc and that worked for me. 1. Should I publish the project so everyone can access and review it ? If we agree this can be fixed publicly. 2. If not, who should be added to the project if review is required ? 3. Did we have any plan to get CVE assignment for this one ? Thanks in advanced.
This is an embargoed bug. This means that this information is not public. Please do NOT: - talk to other people about this unless they're involved in fixing the issue - make this bug public - submit this into OBS (e.g. fix Leap/Tumbleweed) until this bug becomes public (e.g. no EMBARGOED tag on the header) Consult with security team if you think that the issue is public and the bug is still private (e.g. subject still contains "EMBARGOED"). Please do NOT make the bug public yourself! Please be aware that the SUSE:SLE-15-SP4:GA codestream is available via OBS, so do NOT submit there before this is public. These are the steps that are asked from you: 1, Your primary responsibility is to submit a fix for this issue. Here's a how-to for submitting packages for maintenance releases in IBS: https://confluence.suse.com/display/maintenance/How+to+Submit+Packages+or+Containers+to+Maintenance Apart from the GA codestreams mentioned above, you can submit to IBS anytime. This is private and allows us to start testing as soon as possible. 2, We also want to fix openSUSE if it's affected. $ is_maintained $PACKAGE will tell you if the package is inherited from SLES or if it is branched for openSUSE. There are two cases: - It's coming from SLES: The update will automatically be released for openSUSE. Nothing to do for you. - It's branched for openSUSE: You need to submit AFTER the bug became public, to the current openSUSE codestreams. For openSUSE Factory please submit to the devel project of your package AFTER the bug became public. Security will then take the following steps: - We wait for your submission and package them into an incident for QA testing. The QA tester might reach out to you if they find issues with the update. - Once the coordinated release date (CRD), the date this issue should become public, is reached (or for internal findings: once we're done testing), we remove the EMBARGOED tag from this bug and publish the updates. - Only if the bug here is public you may submit to public repositories (OBS). You can contact us at: * IRC: irc.suse.de #security * Do NOT use Slack or any non-SUSE hosted messaging services * Email: security-team@suse.de
opening bug
The fix has been submitted to openSUSE and SLE-15-SP4. Older SLE code streams doesn't require the fix because it is caused by recent openSUSE changes so I think it is all covered. Thanks.
Please use CVE-2021-46705 for this. Adding it to the changelog only is fine, no need to re-release
(In reply to Johannes Segitz from comment #12) > Please use CVE-2021-46705 for this. Adding it to the changelog only is fine, > no need to re-release Hi Johannes, Thanks for the heads up. I've modified changelog for the CVE reference and included that in new openSUSE and SLE-15-SP4 submission. openSUSE:Factory https://build.opensuse.org/request/show/961558 SLE15-SP4:GA https://build.suse.de/request/show/267435