A security issue in libapreq2 has been announced on August 25: https://www.openwall.com/lists/oss-security/2022/08/25/3 It is not clear if a fix is available at this time. Mageia 8 is also affected.
Whiteboard: (none) => MGA8TOO
Chasing other links for this CVE, like: https://cve.report/CVE-2022-22728 they are all exremely recent, and no mention of a fix. Leave this with bugsquad for a short time to see what happens in the next few days. But if nothing turns up?
CC: (none) => lewyssmith
Assigning to our Perl Stack maintainers, because version libapreq2-2.17 was released a few days ago and this vulnerabitity is only said to be present in libapreq2 versions 2.16 and before
CC: (none) => marja11Assignee: bugsquad => perl
Status: NEW => ASSIGNEDCC: (none) => bruno
2.17 pushed to cauldron.
(In reply to Bruno Cornec from comment #3) > 2.17 pushed to cauldron. Thanks, Bruno
Whiteboard: MGA8TOO => (none)Source RPM: libapreq2-2.160.0-4.mga9.src.rpm => libapreq2-2.130.0-31.mga8Version: Cauldron => 8
Thank you both.
CC: lewyssmith => (none)
Fedora has issued an advisory for this on September 12: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/2PUUS3JL44UUSLJTSXE46HVKZIW7E7PE/
Status comment: (none) => Fixed upstream in 2.17Severity: normal => critical
Source RPM: libapreq2-2.130.0-31.mga8 => perl-libapreq2-2.130.0-31.mga8
Source RPM: perl-libapreq2-2.130.0-31.mga8 => libapreq2-2.130.0-31.mga8.src.rpm
Sorry for the mistake David :-( Do you want me to push the same version to mga8 ? Potential impact: $ sudo urpmq --requires-recursive lib64apreq2_3 bash bash-completion dash-static filesystem glibc grep lib64apreq2_3 lib64ncurses6 lib64pcre1 lib64pkgconf3 lib64unimrcp-deps|lib64apr1_0 lib64unimrcp-deps|lib64apr-util1_0 lib64xcrypt1 libgcc1 libstdc++6 pkgconf pkgconf-m4 pkgconf-pkg-config run-parts setup Don't want to create issues here if incompatibilities may be expected...
(In reply to Bruno Cornec from comment #7) > Sorry for the mistake David :-( It was easy enough to fix. Please do remember in the future when you assign a bug to QA to clear the Status Comment. That will cut down on the amount of fixing I have to do. > Do you want me to push the same version to mga8 ? Yeah that should be fine.
I have an issue trying to build it on mga8: Compilation failed in require at /usr/lib64/perl5/vendor_perl/ModPerl/Config.pm line 21. that line is: use Apache2::Build (); But no package is providing that file :-( I had no issue rebuilding on mga9 so I don't know what is hapening here :-( Need to understand what is missing.
What puzzles me is here: rpm -ql apache-mod_perl-2.0.10-9.mga8 | grep Apache2::Build /usr/share/man/man3/Apache2::Build.3pm.xz So we have the man page, but not the module :-( BTW it's the same on mga9, but that doesn't wause the compilation issue reported earlier.
(In reply to David Walser from comment #8) >Please do remember in the future when you assign > a bug to QA to clear the Status Comment. That will cut down on the amount > of fixing I have to do. Oh, I'm always leaving the ASSIGNED status on purpose when I move the ticket to QA. Do you mean I should reset it to NEW instead ? (sorry found nothing searching on Wiki :-()
No, the status doesn't matter. I'm talking about the status *comment* over on the right side.
(In reply to David Walser from comment #12) > No, the status doesn't matter. I'm talking about the status *comment* over > on the right side. Ok, I see, hopefully will remember next times.
Please make sure you leave yourself in CC too.
If 2.17 can't be built for Mageia 8, maybe patches can be backported. Commits that would be needed are referenced in the message below: https://www.openwall.com/lists/oss-security/2023/01/02/2
Debian-LTS has issued an advisory for this on January 14: https://www.debian.org/lts/security/2023/dla-3269
Hi, libapreq2-2.130.0-31.1.mga8 contains the fix from Debian but failed to build for armv7hl because of missing perl 2:5.32.1-1.1.mga8 in that arch. Best regards, Nico.
CC: (none) => nicolas.salguero
armv7hl isn't a required architecture, so that shouldn't stop this update.
Suggested advisory: ======================== The updated packages fix a security vulnerability: A flaw in Apache libapreq2 versions 2.16 and earlier could cause a buffer overflow while processing multipart form uploads. A remote attacker could send a request causing a process crash which could lead to a denial of service attack. (CVE-2022-22728) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22728 https://www.openwall.com/lists/oss-security/2022/08/25/3 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/2PUUS3JL44UUSLJTSXE46HVKZIW7E7PE/ https://www.openwall.com/lists/oss-security/2023/01/02/2 https://www.debian.org/lts/security/2023/dla-3269 ======================== Updated packages in core/updates_testing: ======================== apache-mod_apreq-2.130.0-31.1.mga8 lib(64)apreq2_3-2.130.0-31.1.mga8 lib(64)apreq-devel-2.130.0-31.1.mga8 perl-libapreq2-2.130.0-31.1.mga8 from SRPM: libapreq2-2.130.0-31.1.mga8.src.rpm
CVE: (none) => CVE-2022-22728Assignee: perl => qa-bugsStatus comment: Fixed upstream in 2.17 => (none)
mga8, x64 Checked this out before updating but could not quite figure out what it is used for. It has something to do with generating web pages. There is an application called mason which uses it and has something to do with generating web pages. $ apropos mason HTML::Mason (3pm) - High-performance, dynamic web site authoring system HTML::Mason::Admin - Mason Administrator's Manual $ tree /usr/share/doc/mason/ /usr/share/doc/mason/ ├── Changes ├── CREDITS ├── eg │ ├── httpd.conf │ └── MyApp │ ├── Mason.pm │ └── MasonWithSession.pm ├── INSTALL ├── LICENSE ├── META.json ├── META.yml ├── MYMETA.yml ├── samples │ ├── dump-request │ ├── README │ └── show-env └── UPGRADE Again, do not know how to drive this. For what it is worth the packages update cleanly. Leaving this in abeyance because somebody in QA may understand how to launch mason. I would assume that something like show-env (samples) might be the content to test.
CC: (none) => tarazed25
Failed to get a grip on this - totally ignorant about web programming. Tried throwing show-env at firefox and saw a page with "Current Environment" (from the <h3> header line) and then the code which apache fails to interpret. This probably implies that httpd.conf needs to be edited somehow or apache might need an extension module a la php. Beyond my ken.
And there are details under man HTML::Mason::Admin which back up comment 21. Looks like a lot of work.
Giving up on mason. Managed to misconfigure httpd.conf. Too far out of my depth here. Giving this an OK on the basis of a clean install.
Whiteboard: (none) => MGA8-64-OK
I know the feeling, Len. Validating. Advisory in comment 19.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => advisoryCC: (none) => davidwhodgins
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2023-0123.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED