Security Advisory - yasm - CVE-2021-33461

Security Advisory - yasm - CVE-2021-33461

[Polampalli, Archana]

[-- Attachment #1: Type: text/plain, Size: 112 bytes --]

HI,

Could you please confirm is there any security fix providing for CVE-2021-33461.


Regards,
Archana

[-- Attachment #2: Type: text/html, Size: 1380 bytes --]

Re: [oe] Security Advisory - yasm - CVE-2021-33461

[Khem Raj]

On Wed, Oct 12, 2022 at 10:24 AM Polampalli, Archana
<archana.polampalli@windriver.com> 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

>
>
> Regards,
> Archana
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#99147): https://lists.openembedded.org/g/openembedded-devel/message/99147
> Mute This Topic: https://lists.openembedded.org/mt/94286070/1997914
> Group Owner: openembedded-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [oe] Security Advisory - yasm - CVE-2021-33461

[Polampalli, Archana]

[-- Attachment #1: Type: text/plain, Size: 1272 bytes --]

Hi Khem Raj,

I Have seen the link, issue is in Open.

Could you please confirm open embedded is going to provide the fix.

Regards,
Archana


________________________________
From: Khem Raj <raj.khem@gmail.com>
Sent: Thursday, October 13, 2022 4:00 AM
To: Polampalli, Archana <Archana.Polampalli@windriver.com>
Cc: openembedded-devel@lists.openembedded.org <openembedded-devel@lists.openembedded.org>
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@windriver.com> 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

>
>
> Regards,
> Archana
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#99147): https://lists.openembedded.org/g/openembedded-devel/message/99147
> Mute This Topic: https://lists.openembedded.org/mt/94286070/1997914
> Group Owner: openembedded-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 3682 bytes --]

Re: [oe] Security Advisory - yasm - CVE-2021-33461

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

On Wed, Oct 12, 2022 at 10:59 PM Polampalli, Archana <
Archana.Polampalli@windriver.com> 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


> Regards,
> Archana
>
>
> ------------------------------
> *From:* Khem Raj <raj.khem@gmail.com>
> *Sent:* Thursday, October 13, 2022 4:00 AM
> *To:* Polampalli, Archana <Archana.Polampalli@windriver.com>
> *Cc:* openembedded-devel@lists.openembedded.org <
> openembedded-devel@lists.openembedded.org>
> *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@windriver.com> 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
>
> >
> >
> > Regards,
> > Archana
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#99147):
> https://lists.openembedded.org/g/openembedded-devel/message/99147
> > Mute This Topic: https://lists.openembedded.org/mt/94286070/1997914
> > Group Owner: openembedded-devel+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [
> raj.khem@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >
>

[-- Attachment #2: Type: text/html, Size: 5102 bytes --]

Re: [oe] Security Advisory - yasm - CVE-2021-33461

[Randy MacLeod]

On 2022-10-13 02:33, Khem Raj wrote:
> 
> 
> On Wed, Oct 12, 2022 at 10:59 PM Polampalli, Archana 
> <Archana.Polampalli@windriver.com 
> <mailto:Archana.Polampalli@windriver.com>> 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.

../Randy

> 
> 
>     Regards,
>     Archana
> 
> 
>     ------------------------------------------------------------------------
>     *From:* Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com>>
>     *Sent:* Thursday, October 13, 2022 4:00 AM
>     *To:* Polampalli, Archana <Archana.Polampalli@windriver.com
>     <mailto:Archana.Polampalli@windriver.com>>
>     *Cc:* openembedded-devel@lists.openembedded.org
>     <mailto:openembedded-devel@lists.openembedded.org>
>     <openembedded-devel@lists.openembedded.org
>     <mailto:openembedded-devel@lists.openembedded.org>>
>     *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@windriver.com
>     <mailto:archana.polampalli@windriver.com>> 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
>     >
>     > 
>     >
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#99156): https://lists.openembedded.org/g/openembedded-devel/message/99156
> Mute This Topic: https://lists.openembedded.org/mt/94286070/3616765
> Group Owner: openembedded-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [randy.macleod@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

-- 
# Randy MacLeod
# Wind River Linux

Re: [oe] Security Advisory - yasm - CVE-2021-33461: Propose mv yasm_git.bb yasm-native_git.bb

[Randy MacLeod]

[-- Attachment #1: Type: text/plain, Size: 4388 bytes --]

+ 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@windriver.com 
>> <mailto:Archana.Polampalli@windriver.com>> 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@gmail.com <mailto:raj.khem@gmail.com>>
>>     *Sent:* Thursday, October 13, 2022 4:00 AM
>>     *To:* Polampalli, Archana <Archana.Polampalli@windriver.com
>> <mailto:Archana.Polampalli@windriver.com>>
>>     *Cc:* openembedded-devel@lists.openembedded.org
>> <mailto:openembedded-devel@lists.openembedded.org>
>>     <openembedded-devel@lists.openembedded.org
>> <mailto:openembedded-devel@lists.openembedded.org>>
>>     *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@windriver.com
>> <mailto:archana.polampalli@windriver.com>> 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
>>     >
>>     >     >
>>
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#99156): 
>> https://lists.openembedded.org/g/openembedded-devel/message/99156
>> Mute This Topic: https://lists.openembedded.org/mt/94286070/3616765
>> Group Owner: openembedded-devel+owner@lists.openembedded.org
>> Unsubscribe: 
>> https://lists.openembedded.org/g/openembedded-devel/unsub 
>> [randy.macleod@windriver.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>

-- 
# Randy MacLeod
# Wind River Linux

[-- Attachment #2: Type: text/html, Size: 9368 bytes --]

Re: [oe] Security Advisory - yasm - CVE-2021-33461: Propose mv yasm_git.bb yasm-native_git.bb

[Ross Burton]

On 30 Mar 2023, at 22:56, Randy MacLeod via lists.openembedded.org <randy.macleod=windriver.com@lists.openembedded.org> 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

Re: [oe] Security Advisory - yasm - CVE-2021-33461: Propose mv yasm_git.bb yasm-native_git.bb

[Randy MacLeod]

[-- Attachment #1: Type: text/plain, Size: 3569 bytes --]

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@lists.openembedded.org>  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

[-- Attachment #2: Type: text/html, Size: 5718 bytes --]

Re: [oe] Security Advisory - yasm - CVE-2021-33461: Propose mv yasm_git.bb yasm-native_git.bb

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3558 bytes --]

On Fri, Mar 31, 2023 at 8:43 PM Randy MacLeod <randy.macleod@windriver.com>
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@lists.openembedded.org> <randy.macleod=windriver.com@lists.openembedded.org> 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.

>

[-- Attachment #2: Type: text/html, Size: 5119 bytes --]