YPBZ 14125: busybox wget: where to add openssl-bin dependency?

YPBZ 14125: busybox wget: where to add openssl-bin dependency?

[Randy MacLeod]

Hi Shachar,

On 2020-11-18 1:49 p.m., Shachar Menashe wrote:
> About the busybox patch, I realized that Dunfell doesn't come with the "openssl" binary built-in (only the library) but this fix will actually requires having the openssl binary (busybox invokes the openssl binary directly)
> Do you think it's reasonable to add it? The library is already getting built, so I don't think it's a huge deal to add the binary as well

For dunfell, you need to ask Steve and the oe-core list.
I've CCed both Steve and the list here.

Typically we would not add components to an image after release
but since you have a bug that adding openssl-bin fixes, that's
a different story. You would need to add a dependency
on openssl-bin from busybox. That seems wrong since it'll
increase the size of core-image-minimal.

>
> I'm thinking we would need to add "openssl-bin" to the openssl recipe somewhere, right?

The openssl recipe on master already produces:

$ ls tmp-glibc/work/core2-64-wrs-linux/openssl/1.1.1h-r0/packages-split/
libcrypto            libssl.shlibdeps  openssl-bin.shlibdeps 
openssl-dev      openssl-engines.shlibdeps  openssl-src
libcrypto.shlibdeps  openssl           openssl-conf openssl-doc      
openssl-locale             openssl-staticdev
libssl               openssl-bin       openssl-dbg openssl-engines  
openssl-misc


An example of a dependency on openssl-bin is:

$ cd .../oe-core.git
$ rg openssl-bin
...
meta/recipes-support/ca-certificates/ca-certificates_20200601.bb
87:RDEPENDS_${PN}_class-target = "openssl-bin"
89:RDEPENDS_${PN}_class-nativesdk = "nativesdk-openssl-bin"

so without looking carefully at the busybox recipe, I do wonder
if you just need an *optional* dependency on ca-certificates.

Looking at the busybox recipe, it would be better to have busybox-wget
depend on openssl-bin like:

# busybox's unzip test case needs zip command, which busybox itself does 
not provide
RDEPENDS_${PN}-ptest = "zip"

of course a busybox-wget only component/alternative doesn't seem to 
exist yet:

$ ls tmp-glibc/work/core2-64-oe-linux/busybox/1.32.0-r0/packages-splt
busybox      busybox-dev  busybox-httpd    busybox-locale 
busybox.shlibdeps  busybox-staticdev  busybox-udhcpc
busybox-dbg  busybox-doc  busybox-hwclock  busybox-mdev 
busybox-src        busybox-syslog     busybox-udhcpd

so you'd have to separate that out like we have for -syslog and -httpd, etc.

It's more work than you signed up for but I'm pretty sure that people
are not going to want to have our default core-image-minimal include
openssl-FOO and increase in size.

$ grep busybox 
tmp-glibc/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20201117232559.rootfs.manifest
busybox core2-64 1.32.0-r0
busybox-hwclock core2-64 1.32.0-r0
busybox-syslog core2-64 1.32.0-r0
busybox-udhcpc core2-64 1.32.0-r0

$ grep openssl 
tmp-glibc/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20201117232559.rootfs.manifest
NULL
$

Hopefully someone opinionated about busybox will make a suggestion
on how to resolve this bug.

../Randy


# Randy MacLeod
# Wind River Linux

Re: [OE-core] YPBZ 14125: busybox wget: where to add openssl-bin dependency?

[Andre McCurdy]

On Wed, Nov 18, 2020 at 2:30 PM Randy MacLeod
<randy.macleod@windriver.com> wrote:
>
> Hi Shachar,
>
> On 2020-11-18 1:49 p.m., Shachar Menashe wrote:
> > About the busybox patch, I realized that Dunfell doesn't come with the "openssl" binary built-in (only the library) but this fix will actually requires having the openssl binary (busybox invokes the openssl binary directly)
> > Do you think it's reasonable to add it? The library is already getting built, so I don't think it's a huge deal to add the binary as well
>
> Hopefully someone opinionated about busybox will make a suggestion
> on how to resolve this bug.

The meaning of the busybox FEATURE_WGET_HTTPS configure option is made
quite clear in the associated help message. Claiming it's a "severe
CVE" is not correct - it's working as designed.

  https://git.busybox.net/busybox/tree/networking/wget.c#n49

The behaviour may not be suitable for everyone, but it's the default
config we've used for a long time. Users who need a wget which checks
certificates should think about installing the full featured version
(or try curl if wget's GPLv3 license isn't acceptable).

Re: [OE-core] YPBZ 14125: busybox wget: where to add openssl-bin dependency?

[Andre McCurdy]

On Wed, Nov 18, 2020 at 10:46 PM Shachar Menashe <shachar@vdoo.com> wrote:
>
> Hi Andre,
> The way I see it - even if something is declared, it does not mean it is reasonable or even expected
> I mean - do you earnestly believe that every Yocto user (or busybox wget user for that matter) read the help text associated with the config option that their tool is built with?

No, but I expect them to notice the "TLS certificate validation not
implemented" warning which Busybox wget outputs.

> From my perspective, they could not care less, they have the prebuilt binary and they just use it and expect it to work, they have no idea what config flags were used when building the tool...
> In the year 2020 it is expected that tools that come pre-shipped with your OS aren't exposed to naïve attacks such as SSL MitM, that can be executed by automated tooling

Trying to be secure by default is a good argument. The solution is
probably just to disable FEATURE_WGET_HTTPS though. Users who
understand the limitations can enable it manually. Users who want to
validate certificates should be guided towards using curl. Having
Busybox wget call out to the openssl command line tool is certainly a
creative solution, but feels too much like a hack to want to enable by
default.

> I think I can back this up with the fact that busybox maintainers chose to integrate our patch that fixes the CVE, and not dismiss it
>
> Note that the GNU version of wget is not exposed to this attack, so this furthers the confusion
>
> If there are severe technical issues with shipping the openssl executable with Yocto, then we should definitely think about it, but I think this endeavor is worthwhile
>
> -----Original Message-----
> From: Andre McCurdy <armccurdy@gmail.com>
> Sent: Thursday, November 19, 2020 3:45 AM
> To: Randy MacLeod <randy.macleod@windriver.com>
> Cc: Shachar Menashe <shachar@vdoo.com>; steve@sakoman.com; Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org>
> Subject: Re: [OE-core] YPBZ 14125: busybox wget: where to add openssl-bin dependency?
>
> [External email: Use caution with links and attachments]
>
> On Wed, Nov 18, 2020 at 2:30 PM Randy MacLeod <randy.macleod@windriver.com> wrote:
> >
> > Hi Shachar,
> >
> > On 2020-11-18 1:49 p.m., Shachar Menashe wrote:
> > > About the busybox patch, I realized that Dunfell doesn't come with
> > > the "openssl" binary built-in (only the library) but this fix will
> > > actually requires having the openssl binary (busybox invokes the
> > > openssl binary directly) Do you think it's reasonable to add it? The
> > > library is already getting built, so I don't think it's a huge deal
> > > to add the binary as well
> >
> > Hopefully someone opinionated about busybox will make a suggestion on
> > how to resolve this bug.
>
> The meaning of the busybox FEATURE_WGET_HTTPS configure option is made quite clear in the associated help message. Claiming it's a "severe CVE" is not correct - it's working as designed.
>
>   https://git.busybox.net/busybox/tree/networking/wget.c#n49
>
> The behaviour may not be suitable for everyone, but it's the default config we've used for a long time. Users who need a wget which checks certificates should think about installing the full featured version (or try curl if wget's GPLv3 license isn't acceptable).

Re: [OE-core] YPBZ 14125: busybox wget: where to add openssl-bin dependency?

[Andre McCurdy]

On Thu, Nov 19, 2020 at 11:11 PM Shachar Menashe <shachar@vdoo.com> wrote:
>
> I agree that replacing busybox wget with another tool to handle HTTPS is a cleaner solution, I am just a bit worried about backward compatibility...

Breaking backwards compatibility is not generally a big concern for OE
so long as any use cases within oe-core and its test suite are updated
and continue to work.

> If someone used Yocto and relied on HTTPS download functionality (and seeing there are no other suitable tools such as curl that are already supplied with Yocto) then we are breaking that use case

oe-core provides both curl and wget, so alternatives to Busybox wget
are certainly available.

> So the question is whether we break compatibility by removing FEATURE_WGET_HTTPS, or retaining compatibility by including the openssl binary (or doing nothing and retaining the security issue, which personally I think is problematic)
>
> -----Original Message-----
> From: Andre McCurdy <armccurdy@gmail.com>
> Sent: Thursday, November 19, 2020 9:45 PM
> To: Shachar Menashe <shachar@vdoo.com>
> Cc: Randy MacLeod <randy.macleod@windriver.com>; steve@sakoman.com; Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org>
> Subject: Re: [OE-core] YPBZ 14125: busybox wget: where to add openssl-bin dependency?
>
> [External email: Use caution with links and attachments]
>
> On Wed, Nov 18, 2020 at 10:46 PM Shachar Menashe <shachar@vdoo.com> wrote:
> >
> > Hi Andre,
> > The way I see it - even if something is declared, it does not mean it
> > is reasonable or even expected I mean - do you earnestly believe that every Yocto user (or busybox wget user for that matter) read the help text associated with the config option that their tool is built with?
>
> No, but I expect them to notice the "TLS certificate validation not implemented" warning which Busybox wget outputs.
>
> > From my perspective, they could not care less, they have the prebuilt binary and they just use it and expect it to work, they have no idea what config flags were used when building the tool...
> > In the year 2020 it is expected that tools that come pre-shipped with
> > your OS aren't exposed to naïve attacks such as SSL MitM, that can be
> > executed by automated tooling
>
> Trying to be secure by default is a good argument. The solution is probably just to disable FEATURE_WGET_HTTPS though. Users who understand the limitations can enable it manually. Users who want to validate certificates should be guided towards using curl. Having Busybox wget call out to the openssl command line tool is certainly a creative solution, but feels too much like a hack to want to enable by default.
>
> > I think I can back this up with the fact that busybox maintainers
> > chose to integrate our patch that fixes the CVE, and not dismiss it
> >
> > Note that the GNU version of wget is not exposed to this attack, so
> > this furthers the confusion
> >
> > If there are severe technical issues with shipping the openssl
> > executable with Yocto, then we should definitely think about it, but I
> > think this endeavor is worthwhile
> >
> > -----Original Message-----
> > From: Andre McCurdy <armccurdy@gmail.com>
> > Sent: Thursday, November 19, 2020 3:45 AM
> > To: Randy MacLeod <randy.macleod@windriver.com>
> > Cc: Shachar Menashe <shachar@vdoo.com>; steve@sakoman.com; Patches and
> > discussions about the oe-core layer
> > <openembedded-core@lists.openembedded.org>
> > Subject: Re: [OE-core] YPBZ 14125: busybox wget: where to add openssl-bin dependency?
> >
> > [External email: Use caution with links and attachments]
> >
> > On Wed, Nov 18, 2020 at 2:30 PM Randy MacLeod <randy.macleod@windriver.com> wrote:
> > >
> > > Hi Shachar,
> > >
> > > On 2020-11-18 1:49 p.m., Shachar Menashe wrote:
> > > > About the busybox patch, I realized that Dunfell doesn't come with
> > > > the "openssl" binary built-in (only the library) but this fix will
> > > > actually requires having the openssl binary (busybox invokes the
> > > > openssl binary directly) Do you think it's reasonable to add it?
> > > > The library is already getting built, so I don't think it's a huge
> > > > deal to add the binary as well
> > >
> > > Hopefully someone opinionated about busybox will make a suggestion
> > > on how to resolve this bug.
> >
> > The meaning of the busybox FEATURE_WGET_HTTPS configure option is made quite clear in the associated help message. Claiming it's a "severe CVE" is not correct - it's working as designed.
> >
> >   https://git.busybox.net/busybox/tree/networking/wget.c#n49
> >
> > The behaviour may not be suitable for everyone, but it's the default config we've used for a long time. Users who need a wget which checks certificates should think about installing the full featured version (or try curl if wget's GPLv3 license isn't acceptable).