Master and gatesgarth are both at 1.32.0.

1) action to send config change

Dunfell is at 1.31.1 an may or may not be able to be updated. 

It will need #1 and a source change patch or otherwise.

Either way we might want to apply this patch from Alpine which prints a big warning when using the insecure codepaths:

https://github.com/alpinelinux/aports/commit/a93da0e814c542ff3a76cba0b557ee51c8124d1e

I'd say that telling the user that their connection isn't being verified is enough to mitigate the CVE, as the issue is that MitM can happen without your knowledge.

As this is a team effort, i will take the next step and send a patch to move us to the next step of resolving this issue.

I have a few options to select from.

I sent the patch a few weeks ago, but got pushback because it required building the "openssl" binary and not just the library (that's just how the busybox team chose to use openssl unfortunately... not through the library but by calling the binary)

This is the patch.

https://lists.yoctoproject.org/g/yocto-security/message/229

sent to the security-list.

In master.

https://git.openembedded.org/openembedded-core/commit/meta/recipes-connectivity/openssl?id=304417a97db89d9ea4a41aa7c92b5a052896d63b

I think this can be marked as fixed.

Are the backports done or going to happen?

(In reply to comment #8)
> Are the backports done or going to happen?

Its not obvious in the commit that its addressing a CVE so a backport request needs to be sent to the list.

I think there's been a bit of a mixup
The patch referenced in this thread before (this one - https://lists.yoctoproject.org/g/yocto-security/message/229) DOESN'T resolve the CVE. It's related to a different issue.

Resolving the CVE requires:
1. Changing the busybox config to use OpenSSL by enabling CONFIG_FEATURE_WGET_OPENSSL

2. Building the openssl executable (today it's being built as a library only, but busybox uses openssl as an executable when CONFIG_FEATURE_WGET_OPENSSL is enabled)

So I wrote the patch for #1 a while back, but then got pushback regarding point #2, and didn't submit it, since I thought we're going with Ross' suggestion of just including a warning, the alpine patch - https://github.com/alpinelinux/aports/commit/a93da0e814c542ff3a76cba0b557ee51c8124d1e

Shakar, Can you send a patch to at least issue a warning?

The discussion  on the email list wasn't conclusive. Do you want to drop the issue or add a PACKAGECONFIG to make busybox wget secure using openssl. I suspect that making it secure by default will not be viable due to pulling in some of openssl but that's just my opinion.

(In reply to comment #12)
> The discussion  on the email list wasn't conclusive. Do you want to drop the
> issue or add a PACKAGECONFIG to make busybox wget secure using openssl. I
> suspect that making it secure by default will not be viable due to pulling
> in some of openssl but that's just my opinion.

I have been wondering if something like defining something at the DISTRO level to enable mitigation of this CVE so folks can OPT in knowing the affects of doing so then we could have Busybox and openssl do the appropriate things based on that OPT in directive?

I know the kernel has done this from time to time. The early Meltdown & Sepectra come to mind.

Hey guys, I looked into it further and it seems the "issue" with openssl and the yocto build is not that it's compiled without the binary part, but rather that in "core-image-base" and "core-image-minimal" openssl is not getting compiled at all, and thus busybox wget will not be able to rely on it

I think that adding openssl to minimal builds will cause a lot of friction in the community, so I'd rather not go that path

I suggest that to cause the least amount of friction, I will submit a patch that enables busybox's CONFIG_FEATURE_WGET_OPENSSL for all builds

This means that in builds WITH openssl (ex. sato) the issue will be completely fixed, and in builds WITHOUT openssl, busybox will fallback to using the internal (insecure) client which will print out a message "note: TLS certificate validation not implemented"

Also note that busybox does not rely in any way on the OpenSSL library (it just executes the standalone binary, if it is found) so we shouldn't have linkage issues is CONFIG_FEATURE_WGET_OPENSSL is enabled but OpenSSL is not getting built

WDYT? Makes sense?

Sent to yocto-security

https://lists.yoctoproject.org/g/yocto-security/topic/patch_busybox_use_openssl/82166345?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,82166345

Makes sense to me. Thanks Shachar.

I don't see the patch yet (21:30 ET). Maybe it's in the mail! ;-)

Oh, just look at the link I sent -
https://lists.yoctoproject.org/g/yocto-security/topic/patch_busybox_use_openssl/82166345?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,82166345

Again, in this case the patch really comes out as minimal (just enabling CONFIG_FEATURE_WGET_OPENSSL for all builds)

Some extra information about the patch I submitted - 

By enabling the busybox feature CONFIG_FEATURE_WGET_OPENSSL, in builds WITH openssl (ex. "sato" build) 
the issue will be completely fixed, and in builds WITHOUT openssl, busybox will fallback 
to using the internal (insecure) client which will print out a message 
"note: TLS certificate validation not implemented" 

Note that busybox does not rely in any way on the OpenSSL library 
(it just executes the standalone binary, if it is found) so 
we shouldn't have linkage issues if CONFIG_FEATURE_WGET_OPENSSL is enabled but OpenSSL is not getting built in this particular build (ex. "minimal" build)

Shachar, it seems like you have agreement with Andre so I'm moving this to 3.4-M1.

the busybox fix to address this is:
https://git.busybox.net/busybox/commit/?id=45fa3f18adf57ef9d743038743d9c90573aeeb91

Thanks Armin.

$ cd .../busybox.git && git pull
$ git branch -a --contains 45fa3f18adf57ef9d743038743d9c90573aeeb91
* 1_33_stable
  master
  remotes/origin/1_32_stable
  remotes/origin/1_33_stable
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
$ git tag --contains 45fa3f18adf57ef9d743038743d9c90573aeeb91
1_32_0
1_32_1
1_33_0
1_33_1

and we have 1.33.1:
http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-core/busybox/busybox_1.33.1.bb?id=544236b12a72ee5be5ef0147249ead112082b871

so the questions I have are:
1. is the code is enabled for YP by default and
2. do we want to backport the fix to previous releases?

(In reply to comment #22)
> Thanks Armin.
> 
> $ cd .../busybox.git && git pull
> $ git branch -a --contains 45fa3f18adf57ef9d743038743d9c90573aeeb91
> * 1_33_stable
>   master
>   remotes/origin/1_32_stable
>   remotes/origin/1_33_stable
>   remotes/origin/HEAD -> origin/master
>   remotes/origin/master
> $ git tag --contains 45fa3f18adf57ef9d743038743d9c90573aeeb91
> 1_32_0
> 1_32_1
> 1_33_0
> 1_33_1
> 
> and we have 1.33.1:
> http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-core/
> busybox/busybox_1.33.1.bb?id=544236b12a72ee5be5ef0147249ead112082b871
> 
> so the questions I have are:
> 1. is the code is enabled for YP by default and
> 2. do we want to backport the fix to previous releases?
Hardknott 1.32.0
Dunfell 1.31.1 so dunfell needs this. I can send a patch for dunfell

Shakjar, Armin,

Do we have consensus about how to handle this bug?
I'm reluctant to keep moving the bug to newer releases...

Armin, do you think it makes sense to replace BusyBox's wget with GNU wget? (I see there's already a recipe for that)
This should solve the issue and retain compatibility

We think this is fixed in newer busybox releases. Armin to look into it.

This may have been fixed. I just have to find the time to confirm.

From a recent poky build:
$ grep WGET_OPENSSL tmp/work/core2-64-poky-linux/busybox/1.36.0-r0/busybox-1.36.0/.config
# CONFIG_FEATURE_WGET_OPENSSL is not set

I'll enable it and send a patch.

Patch sent for master to switch to the openssl option.

Fixed by Richard - Thanks!!!

https://git.openembedded.org/openembedded-core/commit/?id=5d4ad13462f12355ff0f2bc1773ab4b1814b165a