Packages are in the process of being submitted to the build system and should be available later today.

Advisory:
========================

Updated nss and firefox packages fix security vulnerabilities:

NSSToken objects were referenced via direct points, and could have been
accessed in an unsafe way on different threads, leading to a use-after-free
and potentially exploitable crash (CVE-2022-1097).

After a VR Process is destroyed, a reference to it may have been retained and
used, leading to a use-after-free and potentially exploitable crash
(CVE-2022-1196).

The rust regex crate did not properly prevent crafted regular expressions from
taking an arbitrary amount of time during parsing. If an attacker was able to
supply input to this crate, they could have caused a denial of service in the
browser (CVE-2022-24713).

If a compromised content process sent an unexpected number of WebAuthN
Extensions in a Register command to the parent process, an out of bounds write
would have occurred leading to memory corruption and a potentially exploitable
crash (CVE-2022-28281).

By using a link with rel="localization" a use-after-free in
DocumentL10n::TranslateDocument could have been triggered by destroying an
object during JavaScript execution and then referencing the object through a
freed pointer, leading to a potential exploitable crash (CVE-2022-28282).

When generating the assembly code for MLoadTypedArrayElementHole, an incorrect
AliasSet was used in JIT Codegen. In conjunction with another vulnerability
this could have been used for an out of bounds memory read (CVE-2022-28285).

Due to a layout change, iframe contents could have been rendered outside of
its border. This could have led to user confusion or spoofing attacks
(CVE-2022-28286).

Mozilla developers and community members Nika Layzell (ni? for response), the
Mozilla Fuzzing Team, Andrew McCreight, Gabriele Svelto (pto) reported memory
safety bugs present in Firefox ESR 91.7. Some of these bugs showed evidence of
memory corruption and we presume that with enough effort some of these could
have been exploited to run arbitrary code (CVE-2022-28289).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1097
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1196
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24713
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28281
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28282
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28285
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28286
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28289
https://firefox-source-docs.mozilla.org/security/nss/releases/nss_3_77.html
https://www.mozilla.org/en-US/security/advisories/mfsa2022-14/

Rust is broken in Cauldron:
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20220405193031.luigiwalser.duvel.3735040/log/firefox-91.8.0-1.mga9/install_deps-1.i586.0.20220405193433.log

I'm also wondering if we need to do anything rust-wise for Mageia 8 to address CVE-2022-24713.  I don't know exactly where that fix lies.

Version: 8 => Cauldron
Whiteboard: (none) => MGA8TOO
Assignee: luigiwalser => rverschelde

Advisory committed to svn. Tested on m8 x86_64, i586 (under vb), and aarch64
(rpi 4b).

If it's ready to assign to qa, it's ready to validate.

CC: (none) => davidwhodgins
Keywords: (none) => advisory

for CVE-2022-24713 it seems this is this patch : https://github.com/rust-lang/regex/commit/ae70b41d4f46641dbc45c7a4f87954aea356283e


cf: https://security-tracker.debian.org/tracker/CVE-2022-24713

CC: (none) => mageia

mga8-64 OK on Plasma, nvidia-current:
§ swedish locale
§ settings and opened tabs preserved
§ video sites

CC: (none) => fri

...and some web stores and banking sites, while fighting my energetic conure parrot on the keyboard...
- She wants to say it is coffe time :)

Thanks, so we at least need to patch or update rust.  Hopefully we don't need to rebuild Firefox with the updated rust.

(In reply to David Walser from comment #7)
> Thanks, so we at least need to patch or update rust.  Hopefully we don't
> need to rebuild Firefox with the updated rust.

As I understand it it's not something that needs to be patched in rust / the rustc compiler, but it's a bug in the `regex` crate which is vendored in the Firefox sources.

It seems to be patched in FF 91.8 so that should be sufficient. (In Cauldron we also provide the rust-regex package which has been updated to the fixed 1.5.5, and it's not provided in Mageia 8.)

(In reply to Rémi Verschelde from comment #8)
> (In reply to David Walser from comment #7)
> > Thanks, so we at least need to patch or update rust.  Hopefully we don't
> > need to rebuild Firefox with the updated rust.
> 
> As I understand it it's not something that needs to be patched in rust / the
> rustc compiler, but it's a bug in the `regex` crate which is vendored in the
> Firefox sources.

My bad, rust also vendors the regex crate, which has version 1.5.4.
I'll backport the patch.

End of the CVE-2022-24713 parenthesis:

So I've tried and failed to patch rust to update the crate, as the rust vendoring system is pretty sensitive to unexpected source modifications.

But I talked with the Rust maintainer for Fedora who told me that CVE-2022-24713 is likely not a risk for the rustc toolchain itself, and so we don't need to go out of our way to patch it (Fedora didn't patch it either).

22:15 <JoshStone[m]> Akien why are you worried about that CVE for the toolchain? It should only matter when running untrusted regex patterns -- like some kind of cross-privilege input.
22:20 <Akien> JoshStone[m]: I didn't really assess the risk to be fair, it came up in the Firefox ESR release notes and I was notified by our security guy that it might need patching in rustc too. If it's not a high risk one I'm happy to skip it and let it be solved by 1.60.0 (though I'm a few versions behind on Mageia 8, I'll have to catch up).
22:22 <JoshStone[m]> even rust `master` hasn't bothered updating this yet
22:24 <JoshStone[m]> I'm not aware of any part of the toolchain that takes a user-controlled regex, and even if there is, the worst you can do is DoS yourself
22:25 <JoshStone[m]> actually `cargo tree -i regex` shows it is only used by the `bootstrap` crate
22:25 <JoshStone[m]> so yeah, don't worry about it

---

Now for Firefox in Cauldron, Nicolas restored lib(64)llvm13.0 so rust can be installed to compile Firefox.

But it's failing in C++ code on i586 and armv7hl:

15:00 <Akien> Hm, firefox fails building on Mageia 9 armv7hl while it built fine on Mageia 8: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20220406121346.akien.duvel.3315789/log/firefox-91.8.0-1.mga9/build.armv7hl.0.20220406122731.log
Untitled page
D: [iurt_root_command] chroot warning: Found bdb_ro Packages database while attempting sqlite backend: using bdb_ro backend. Installing /home/iurt/rpmbuild/SRPMS/@1845247:firefox-91.8.0-1.mga9.src.rpm Building target platforms: armv7hl Building for target armv7hl Executing(%prep): /bin/sh -e /home/i
15:01 <Akien> GCC 12 issue?
15:01 <Akien>  7:55.05   cargo:warning=src/glsl.h:2315:29: error: call to non-'constexpr' function 'glsl::vec2& glsl::vec2::operator=(glsl::vec2&&)'
15:01 <Akien>  7:55.05   cargo:warning= 2315 |     data[0] = vec2(s.data[0]);
15:01 <Akien>  7:55.05   cargo:warning=      |                             ^
15:01 <Akien>  7:55.05   cargo:warning=src/glsl.h:469:8: note: 'glsl::vec2& glsl::vec2::operator=(glsl::vec2&&)' is not usable as a 'constexpr' function because:
15:01 <Akien>  7:55.05   cargo:warning=  469 | struct vec2 {
15:01 <Akien>  7:55.05   cargo:warning=      |        ^~~~
17:59 <Akien> Seems to fail the same on i586, must be a 32-bit quirk.
23:31 <NyB> /home/iurt/rpmbuild/BUILD/firefox-91.8.0/extensions/permissions/PermissionManager.cpp:2799:23: note: at offset 8 into object 'entries' of size 4
23:32 <NyB> yes, somebody hardcoded an 8-byte something somewhere

I probably won't have time to look further into this myself this week.

Good try anyway.

So we can validate the packages per comment 0 for mga8?

(In reply to Morgan Leijström from comment #11)
> So we can validate the packages per comment 0 for mga8?

We could, but that's a risk. Since Firefox didn't build in Cauldron, validating the update for Mageia 8 would mean that Mageia 8 has a newer version of Firefox than Cauldron, and this breaks the upgrade path.

This bug is set to security critical.

I think keeping a supported Mageia release safe is more important than upgrade path to the experimental Cauldron?

Do we ever guarantee hassle free upgrade to Cauldron except when nearing release?

Assign to QA if good to go.

guarantee -> expect

Can firefox be built with clang?  CentOS 9 beta is currently building with GCC 11 successfully.  I guess the issue is only with GCC 12?  So probably none of their patches help us.  Speaking of their patches though, it looks like Firefox is using a bundled expat, which CentOS is patching for some CVEs:
https://git.centos.org/rpms/firefox/c/9728d7f53514d673cec20bbe7094511bc5c5f4af?branch=c9-beta

Although that was the current 91.7, hopefully those are fixed upstream in Firefox 91.8.

RedHat has issued an advisory for this today (April 8):
https://access.redhat.com/errata/RHSA-2022:1287

Status?

No response to Comment 15.  Right now, tmb is trying to build it, so I guess he's looking into the gcc issues (maybe it's been fixed in gcc since we last tried).

Firefox in cauldron is built.

there were some added patches for mga8 firefox, so that one is now:

firefox-91.8.0-1.1.mga8

Assignee: rverschelde => qa-bugs
Whiteboard: MGA8TOO => (none)
Version: Cauldron => 8

The added patches were the expat CVE fixes that I referenced in Comment 15.

mga8-64, no regressions noted.
Plasma, swedish, latest kernel, microcode, and nvidia-current now in updates testing and kernel backport testing too.

MGA8-64, on Xfce, Toshiba Laptop

AMD A6-3420M APU 
Radeon HD 6520G
RTL8188CE 802.11b/g/n WiFi Adapter
 


The following 8 packages are going to be installed:

- firefox-91.8.0-1.1.mga8.x86_64
- firefox-en_CA-91.8.0-1.mga8.noarch
- firefox-en_GB-91.8.0-1.mga8.noarch
- firefox-en_US-91.8.0-1.mga8.noarch
- lib64nss3-3.77.0-1.mga8.x86_64
- nss-3.77.0-1.mga8.x86_64
- rootcerts-20220324.00-1.mga8.noarch
- rootcerts-java-20220324.00-1.mga8.noarch

973KB of additional disk space will be used.


verified version
working as expected

CC: (none) => brtians1

MGA 64 XFCE fr

Updated with QA repo and rpm:

firefox                        91.8.0       1.1.mga8      x86_64  
firefox-fr                     91.8.0       1.mga8        noarch  
lib64nss3                      3.77.0       1.mga8        x86_64  
nss                            3.77.0       1.mga8        x86_64  
rootcerts                      20220324.00  1.mga8        noarch  

No issues after installation:

Bank sites OK
Netflix OK
Browsing OK 
Webcam with browser OK

CC: (none) => guillaume.royer

MGA8-64 Plasma on a Probook 6550b.

Used the list in Comment 0 with qarepo's "fuzzy version" option to download all packages, then updated the US English version. 

Seemed a little slow to come up the first time, but was OK subsequent to that. Checked out a few websites, no issues noted.

CC: (none) => andrewsfarm

Updated on my production desktop, with no installation issues.

No sign of sluggishness on the start, tried a few different websites from Comment 24, checked tracking of a package shipment from Amazon. All looked OK.

And I get
libnss3-3.77.0-1.mga8 not found in the remote repository
libnss-devel-3.77.0-1.mga8 not found in the remote repository
libnss-static-devel-3.77.0-1.mga8 not found in the remote repository

qarepo finds firefox-91.8.0-1.1.mga8

CC: (none) => tarazed25

Oops - just spotted the missing lib64.

Firefox working OK here.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2022-0156.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED