Security Advisory - yasm - CVE-2021-33461: Propose mv yasm_git.bb yasm-native_git.bb
On 2022-10-13 02:33, Khem Raj wrote:
On Wed, Oct 12, 2022 at 10:59 PM Polampalli, Archana <Archana.Polampalli@... <mailto:Archana.Polampalli@...>> wrote:
Hi Khem Raj,
I Have seen the link, issue is in Open.
Could you please confirm open embedded is going to provide the fix.
If someone in community signs up for it then yes
and in this case, the community is us (Wind River and other folks using yasm in OE)
so that may be you providing the fix Archana.
I'll explain more offline.
The yasm CVEs have come up again. Sigh.
Upstream seems not to be interested in fixing CVEs:
https://github.com/yasm/yasm/commits/master
We only need yasm-native (1) so does anyone object to
moving this recipe to yasm-native_git.bb ? This small change
would make it clear that images/tagets/machines are not _directly_
vulnerable
due to the fuzzing errors people are generating which result in
CVEs.
../Randy
meta-oe.git on master [$?]
❯ rg yasm
meta-multimedia/recipes-multimedia/aom/aom_3.4.0.bb
18:DEPENDS = " yasm-native"
meta-oe/recipes-devtools/yasm/yasm_git.bb
3:HOMEPAGE = "http://www.tortall.net/projects/yasm/"
13:SRC_URI =
"git://github.com/yasm/yasm.git;branch=master;protocol=https \
meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb
310: yasm \
meta-oe.git on master [$?]
❯ rg yasm ../meta-browser.git/
../meta-browser.git/meta-firefox/recipes-browser/firefox/firefox_68.9.0esr.bb
8: yasm-native nasm-native unzip-native \
../meta-browser.git/meta-firefox/recipes-browser/firefox/firefox/fixes/pre-generated-old-configure.patch
8213:+ { echo "configure: error: Building ICU
requires either yasm or a GNU assembler. If you do not have either
of those available for this platform you must use
--without-intl-api" 1>&2; echo "configure: error: Building
ICU requires either yasm or a GNU assembler. If you do not have
either of those available for this platform you must use
--without-intl-api" 1>&5; exit 1; }
meta-oe.git on master [$?]
❯ rg yasm ../meta-intel-qat.git/
../meta-intel-qat.git/recipes-extended/qat/qat17_4.20.0-00001.bb
10:DEPENDS += "boost udev zlib openssl yasm-native"
182:# yasm encodes path to the input file and doesn't provide any
option to workaround it.
../Randy
Regards,
Archana
------------------------------------------------------------------------
*From:* Khem Raj <raj.khem@... <mailto:raj.khem@...>>
*Sent:* Thursday, October 13, 2022 4:00 AM
*To:* Polampalli, Archana <Archana.Polampalli@...
<mailto:Archana.Polampalli@...>>
*Cc:* openembedded-devel@...
<mailto:openembedded-devel@...>
<openembedded-devel@...
<mailto:openembedded-devel@...>>
*Subject:* Re: [oe] Security Advisory - yasm - CVE-2021-33461
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Wed, Oct 12, 2022 at 10:24 AM Polampalli, Archana
<archana.polampalli@...
<mailto:archana.polampalli@...>> wrote:
>
> HI,
>
> Could you please confirm is there any security fix providing for CVE-2021-33461.
seems to be open https://github.com/yasm/yasm/issues/161
<https://github.com/yasm/yasm/issues/161>
>
>
> Regards,
> Archana
>
> >
-- # Randy MacLeod # Wind River Linux
The yasm CVEs have come up again. Sigh.It seems like a better alternative would be to reduce the number of assemblers that are effectively unmaintained from two (nasm and yasm) to one (just nasm, as that’s in oe-core). Also marking all yasm/nasm dependencies as being x86-specific for obvious reasons.
Upstream seems not to be interested in fixing CVEs:
https://github.com/yasm/yasm/commits/master
We only need yasm-native (1) so does anyone object to
moving this recipe to yasm-native_git.bb ? This small change
would make it clear that images/tagets/machines are not _directly_ vulnerable
due to the fuzzing errors people are generating which result in CVEs.
I’m a firm believer that we should be able to rebuild all packages on target, so native-specific tools should be a special case. The moment you make it native only is the moment you discover that someone was using nativesdk-yasm or on-target yasm to develop.
Looking at your search, I think we might be able to just remove yasm entirely:
meta-multimedia/recipes-multimedia/aom/aom_3.4.0.bbAccording to the AOM readme:
18:DEPENDS = " yasm-native"
"For x86 targets, yasm, which is preferred, or a recent version of nasm.”
So that dependency should be specific to x86 targets, and could be nasm.
meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bbThis is just the meta packagegroup that pulls in all of the recipes, for testing.
310: yasm \
../meta-browser.git/meta-firefox/recipes-browser/firefox/firefox_68.9.0esr.bbOf course firefox wants yasm *and* nasm. Those should most likely be x86-specific to start with, and I’m guessing that’s related to:
8: yasm-native nasm-native unzip-native \
../meta-browser.git/meta-firefox/recipes-browser/firefox/firefox/fixes/pre-generated-old-configure.patchSo that patch adds a huge configure script with no explanation and is at least five years old.
8213:+ { echo "configure: error: Building ICU requires either yasm or a GNU assembler. If you do not have either of those available for this platform you must use --without-intl-api" 1>&2; echo "configure: error: Building ICU requires either yasm or a GNU assembler. If you do not have either of those available for this platform you must use --without-intl-api" 1>&5; exit 1;
We happily build ICU in core without yaml as we have GNU as. I expect that can be removed.
../meta-intel-qat.git/recipes-extended/qat/qat17_4.20.0-00001.bbI’d be surprised if a quick s/nasm/yasm/ didn’t fix this. The nasm compiler is more actively maintained _and_ maintained by and Intel employee after all…
10:DEPENDS += "boost udev zlib openssl yasm-native"
Ross
Few assembler recipes: good idea!On 30 Mar 2023, at 22:56, Randy MacLeod via lists.openembedded.org <randy.macleod=windriver.com@...> wrote:The yasm CVEs have come up again. Sigh. Upstream seems not to be interested in fixing CVEs: https://github.com/yasm/yasm/commits/master We only need yasm-native (1) so does anyone object to moving this recipe to yasm-native_git.bb ? This small change would make it clear that images/tagets/machines are not _directly_ vulnerable due to the fuzzing errors people are generating which result in CVEs.It seems like a better alternative would be to reduce the number of assemblers that are effectively unmaintained from two (nasm and yasm) to one (just nasm, as that’s in oe-core). Also marking all yasm/nasm dependencies as being x86-specific for obvious reasons. I’m a firm believer that we should be able to rebuild all packages on target, so native-specific tools should be a special case. The moment you make it native only is the moment you discover that someone was using nativesdk-yasm or on-target yasm to develop.
Yes, it's best to keep the recipe working for both -native and target.
Looking at your search, I think we might be able to just remove yasm entirely:meta-multimedia/recipes-multimedia/aom/aom_3.4.0.bb 18:DEPENDS = " yasm-native"According to the AOM readme: "For x86 targets, yasm, which is preferred, or a recent version of nasm.” So that dependency should be specific to x86 targets, and could be nasm.meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb 310: yasm \This is just the meta packagegroup that pulls in all of the recipes, for testing.../meta-browser.git/meta-firefox/recipes-browser/firefox/firefox_68.9.0esr.bb 8: yasm-native nasm-native unzip-native \Of course firefox wants yasm *and* nasm. Those should most likely be x86-specific to start with, and I’m guessing that’s related to:../meta-browser.git/meta-firefox/recipes-browser/firefox/firefox/fixes/pre-generated-old-configure.patch 8213:+ { echo "configure: error: Building ICU requires either yasm or a GNU assembler. If you do not have either of those available for this platform you must use --without-intl-api" 1>&2; echo "configure: error: Building ICU requires either yasm or a GNU assembler. If you do not have either of those available for this platform you must use --without-intl-api" 1>&5; exit 1;So that patch adds a huge configure script with no explanation and is at least five years old. We happily build ICU in core without yaml as we have GNU as. I expect that can be removed.
Let's hope so and Archana and I can take a look.
'everybody expects the blink rendering engine' camp.
If Martin doesn't have any plans to update firefox, it might become a weekend project.
../meta-intel-qat.git/recipes-extended/qat/qat17_4.20.0-00001.bb 10:DEPENDS += "boost udev zlib openssl yasm-native"I’d be surprised if a quick s/nasm/yasm/ didn’t fix this. The nasm compiler is more actively maintained _and_ maintained by and Intel employee after all…
Ah, I didn't know that the nasm maintainer is an INTC geek, but
it's exactly the sort of info I was hoping to hear by posting!
Thanks Ross.
../Randy
Ross
-- # Randy MacLeod # Wind River Linux
On 2023-03-31 05:51, Ross Burton wrote:
Few assembler recipes: good idea!On 30 Mar 2023, at 22:56, Randy MacLeod via lists.openembedded.org <randy.macleod=windriver.com@...> wrote:The yasm CVEs have come up again. Sigh. Upstream seems not to be interested in fixing CVEs: https://github.com/yasm/yasm/commits/master We only need yasm-native (1) so does anyone object to moving this recipe to yasm-native_git.bb ? This small change would make it clear that images/tagets/machines are not _directly_ vulnerable due to the fuzzing errors people are generating which result in CVEs.It seems like a better alternative would be to reduce the number of assemblers that are effectively unmaintained from two (nasm and yasm) to one (just nasm, as that’s in oe-core). Also marking all yasm/nasm dependencies as being x86-specific for obvious reasons. I’m a firm believer that we should be able to rebuild all packages on target, so native-specific tools should be a special case. The moment you make it native only is the moment you discover that someone was using nativesdk-yasm or on-target yasm to develop.
Yes, it's best to keep the recipe working for both -native and target.
Looking at your search, I think we might be able to just remove yasm entirely:meta-multimedia/recipes-multimedia/aom/aom_3.4.0.bb 18:DEPENDS = " yasm-native"According to the AOM readme: "For x86 targets, yasm, which is preferred, or a recent version of nasm.” So that dependency should be specific to x86 targets, and could be nasm.meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb 310: yasm \This is just the meta packagegroup that pulls in all of the recipes, for testing.../meta-browser.git/meta-firefox/recipes-browser/firefox/firefox_68.9.0esr.bb 8: yasm-native nasm-native unzip-native \Of course firefox wants yasm *and* nasm. Those should most likely be x86-specific to start with, and I’m guessing that’s related to:../meta-browser.git/meta-firefox/recipes-browser/firefox/firefox/fixes/pre-generated-old-configure.patch 8213:+ { echo "configure: error: Building ICU requires either yasm or a GNU assembler. If you do not have either of those available for this platform you must use --without-intl-api" 1>&2; echo "configure: error: Building ICU requires either yasm or a GNU assembler. If you do not have either of those available for this platform you must use --without-intl-api" 1>&5; exit 1;So that patch adds a huge configure script with no explanation and is at least five years old. We happily build ICU in core without yaml as we have GNU as. I expect that can be removed.Let's hope so and Archana and I can take a look.
It would be nice to update firefox ( 68->110 !!) but we're (WR) in the:
'everybody expects the blink rendering engine' camp.
If Martin doesn't have any plans to update firefox, it might become a weekend project.