Security Advisory - yasm - CVE-2021-33461: Propose mv yasm_git.bb yasm-native_git.bb


Randy MacLeod
 

+ Anuj for meta-intel-qat use of yasm-native.

On 2022-10-13 10:05, Randy MacLeod wrote:
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


Ross Burton
 

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.

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.

../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…

Ross


Randy MacLeod
 

On 2023-03-31 05:51, Ross Burton wrote:
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.
Few assembler recipes: good idea!
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.


../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


Martin Jansa
 

On Fri, Mar 31, 2023 at 8:43 PM Randy MacLeod <randy.macleod@...> wrote:
On 2023-03-31 05:51, Ross Burton wrote:
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.
Few assembler recipes: good idea!
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.

I'm in the "I wish I didn't include it in my OE build-time benchmark" camp :).

I've never used OE built firefox and don't plan to use it in future. And I don't plan to update it, in worst case I'll have to spent bare-minimal time to make it build-able again just to measure how much slower it builds with newer rust.