Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Adam D. Barratt]

On Mon, 2020-02-10 at 08:56 +0100, Christoph Biedl wrote:
> Salvatore Bonaccorso wrote...
> 
> > Is this still something we should try to get into stretch (now to
> > late
> > for 9.12 but might be possible for 9.13)?
> 
> For me, I would like to, so I'll re-visit the scenary and will try to
> eventually get this done.

For the record, we're now planning for 9.13, which will be the final
point release for stretch before it moves to LTS.

Regards,

Adam

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

Salvatore Bonaccorso wrote...

> Is this still something we should try to get into stretch (now to late
> for 9.12 but might be possible for 9.13)?

For me, I would like to, so I'll re-visit the scenary and will try to
eventually get this done.

Christoph


signature.asc
Description: PGP signature

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Salvatore Bonaccorso]

Hi,

On Sun, Aug 11, 2019 at 02:19:47PM +0100, Jonathan Wiltshire wrote:
> Hi,
> 
> On Wed, Mar 20, 2019 at 08:43:08PM +0100, Christoph Biedl wrote:
> > Cyril Brulebois wrote...
> > 
> > > p-u NEW usually gets frozen a week before the point release. Having the
> > > package to review/test a week before that (so 2 weeks before the point
> > > release date) would be awesome. Depending on external things, I could
> > > still make time if that's only a few days before the freeze, but a full
> > > week should help ensure reviewing/testing happens in time.
> > 
> > Okay, I'll try to get this finally done within the next week.
> 
> How's that going?

Is this still something we should try to get into stretch (now to late
for 9.12 but might be possible for 9.13)?

Regards,
Salvatore

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Jonathan Wiltshire]

Hi,

On Wed, Mar 20, 2019 at 08:43:08PM +0100, Christoph Biedl wrote:
> Cyril Brulebois wrote...
> 
> > p-u NEW usually gets frozen a week before the point release. Having the
> > package to review/test a week before that (so 2 weeks before the point
> > release date) would be awesome. Depending on external things, I could
> > still make time if that's only a few days before the freeze, but a full
> > week should help ensure reviewing/testing happens in time.
> 
> Okay, I'll try to get this finally done within the next week.

How's that going?

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

Cyril Brulebois wrote...

> p-u NEW usually gets frozen a week before the point release. Having the
> package to review/test a week before that (so 2 weeks before the point
> release date) would be awesome. Depending on external things, I could
> still make time if that's only a few days before the freeze, but a full
> week should help ensure reviewing/testing happens in time.

Okay, I'll try to get this finally done within the next week.

Christoph


signature.asc
Description: PGP signature

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Cyril Brulebois]

Heya,

Christoph Biedl  (2019-03-17):
> Adam D. Barratt wrote...
> 
> > Folks, what's the current status here?
> 
> It's not forgotten, but now quite outdated. There are several more fixes
> that should go into the stretch version of busybox. I will take care of
> this in the next days.
> 
> Cyril, you previously mentioned the submission was too close to the
> deadline to check before granting approval from the installer team
> side. Can you give me an idea how much time you need for review before
> a future point release, so I can plan accordingly?

p-u NEW usually gets frozen a week before the point release. Having the
package to review/test a week before that (so 2 weeks before the point
release date) would be awesome. Depending on external things, I could
still make time if that's only a few days before the freeze, but a full
week should help ensure reviewing/testing happens in time.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

Adam D. Barratt wrote...

> Folks, what's the current status here?

It's not forgotten, but now quite outdated. There are several more fixes
that should go into the stretch version of busybox. I will take care of
this in the next days.

Cyril, you previously mentioned the submission was too close to the
deadline to check before granting approval from the installer team
side. Can you give me an idea how much time you need for review before
a future point release, so I can plan accordingly?

Christoph


signature.asc
Description: PGP signature

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Adam D. Barratt]

On Thu, 2017-11-30 at 20:17 +0100, Christoph Biedl wrote:
> Second attempt, updated debdiff attached.
> 
> Changes:
> 
> also address:
> 
> +  * Fix integer overflow in bzip2 decompresson.
> +Closes: #879732 [CVE-2017-15873]
> +  * Filter out terminal escape sequence filtering in autocompletion.
> +Closes: #882258 [CVE-2017-16544]
> 
> A call for tests was sent to debian-boot three days ago¹, no
> reaction though.
> 
> Assuming your
> 
> > I'd be happy with this in general, but the udeb means we need an
> > explicit d-i RM ack; CCing appropriately.
> 
> still applies, Cc: is set accordingly.
> 

Folks, what's the current status here?

Regards,

Adam

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

Second attempt, updated debdiff attached.

Changes:

also address:

+  * Fix integer overflow in bzip2 decompresson.
+Closes: #879732 [CVE-2017-15873]
+  * Filter out terminal escape sequence filtering in autocompletion.
+Closes: #882258 [CVE-2017-16544]

A call for tests was sent to debian-boot three days ago¹, no
reaction though.

Assuming your

> I'd be happy with this in general, but the udeb means we need an
> explicit d-i RM ack; CCing appropriately.

still applies, Cc: is set accordingly.

Regards,

Christoph

¹ https://lists.debian.org/debian-boot/2017/11/msg00379.html
diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2016-04-17 17:37:25.0 +0200
+++ busybox-1.22.0/debian/changelog 2017-09-25 22:42:41.0 +0200
@@ -1,3 +1,19 @@
+busybox (1:1.22.0-19+deb9u1) stretch; urgency=medium
+
+  * Fix pointer misuse unziping files. Closes: #803097
+  * Fix Heap-based buffer overflow in the DHCP client.
+Closes: #818497 [CVE-2016-2148]
+  * Fix integer overflow in the DHCP client (udhcpc).
+Closes: #818499 [CVE-2016-2147]
+  * Fix directory traversal vulnerability in tar implementation.
+Closes: #802702 [CVE-2011-5325]
+  * Fix integer overflow in bzip2 decompresson.
+Closes: #879732 [CVE-2017-15873]
+  * Filter out terminal escape sequence filtering in autocompletion.
+Closes: #882258 [CVE-2017-16544]
+
+ -- Christoph Biedl   Mon, 25 Sep 2017 
22:42:41 +0200
+
 busybox (1:1.22.0-19) unstable; urgency=medium
 
   * busybox-udeb, udhcpc: Remove /udhcpc/usr/share/udhcpc/default.script,
diff -Nru 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
--- 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
1970-01-01 01:00:00.0 +0100
+++ 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
2017-09-25 22:42:41.0 +0200
@@ -0,0 +1,58 @@
+Subject: Udhcpc: fix OPTION_6RD parsing (could overflow its malloced buffer)
+ID: CVE-2016-2148
+Origin: 1_24_0-139-g352f79a
+Upstream-Author: Denys Vlasenko 
+Date: Fri Feb 26 15:54:56 2016 +0100
+Bug-Debian: https://bugs.debian.org/818497 
+
+--- a/networking/udhcp/common.c
 b/networking/udhcp/common.c
+@@ -140,7 +140,7 @@
+  * udhcp_str2optset: to determine how many bytes to allocate.
+  * xmalloc_optname_optval: to estimate string length
+  * from binary option length: (option[LEN] / dhcp_option_lengths[opt_type])
+- * is the number of elements, multiply in by one element's string width
++ * is the number of elements, multiply it by one element's string width
+  * (len_of_option_as_string[opt_type]) and you know how wide string you need.
+  */
+ const uint8_t dhcp_option_lengths[] ALIGN1 = {
+@@ -160,7 +160,18 @@
+   [OPTION_S32] = 4,
+   /* Just like OPTION_STRING, we use minimum length here */
+   [OPTION_STATIC_ROUTES] = 5,
+-  [OPTION_6RD] =22,  /* ignored by udhcp_str2optset */
++  [OPTION_6RD] =12,  /* ignored by udhcp_str2optset */
++  /* The above value was chosen as follows:
++   * len_of_option_as_string[] for this option is >60: it's a string of 
the form
++   * "32 128 ::::::: 255.255.255.255 ".
++   * Each additional ipv4 address takes 4 bytes in binary option and 
appends
++   * another "255.255.255.255 " 16-byte string. We can set [OPTION_6RD] = 
4
++   * but this severely overestimates string length: instead of 16 bytes,
++   * it adds >60 for every 4 bytes in binary option.
++   * We cheat and declare here that option is in units of 12 bytes.
++   * This adds more than 60 bytes for every three ipv4 addresses - more 
than enough.
++   * (Even 16 instead of 12 should work, but let's be paranoid).
++   */
+ };
+ 
+ 
+--- a/networking/udhcp/dhcpc.c
 b/networking/udhcp/dhcpc.c
+@@ -99,7 +99,7 @@
+   [OPTION_IP  ] = sizeof("255.255.255.255 "),
+   [OPTION_IP_PAIR ] = sizeof("255.255.255.255 ") * 2,
+   [OPTION_STATIC_ROUTES   ] = sizeof("255.255.255.255/32 255.255.255.255 
"),
+-  [OPTION_6RD ] = sizeof("32 128 
::::::: 255.255.255.255 "),
++  [OPTION_6RD ] = sizeof("132 128 
::::::: 255.255.255.255 "),
+   [OPTION_STRING  ] = 1,
+   [OPTION_STRING_HOST ] = 1,
+ #if ENABLE_FEATURE_UDHCP_RFC3397
+@@ -206,7 +206,7 @@
+   type = optflag->flags & OPTION_TYPE_MASK;
+   optlen = dhcp_option_lengths[type];
+   upper_length = 

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

Adam D. Barratt wrote...

> I'd be happy with this in general, but the udeb means we need an
> explicit d-i RM ack; CCing appropriately.

Okay, lesson learned: For such packages, don't proscrastinate the
request until close to the deadline that has passed now. There'll be
another point relase, I'll take the delay as an opportunity to handle
some of the "important" bugs after some more checking as well,
especially.

#801850: readlink gets shadowed by busybox causing debconf to possibly fail
#854923: busybox: "sed -i nonexistent" creates bogus files

Same for jessie-pu.

So just stay tuned, Ai'll be bach.

Christoph


signature.asc
Description: Digital signature

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Fri, 2017-09-29 at 22:39 +0200, Christoph Biedl wrote:
> there are several non-dsa issues open for busybox. Now wearing the
> maintainer's hat (together with Chris Boot, cc'd), I'd like to fix
> them in an upcoming point release, for both jessie and stretch. I'll
> file two separate request for these distributions, assuming this
> eases handling on your side.

If you'd filed a single request then we'd just have cloned it and
treated them separately, so yeah. :-)

> So for *stretch*, https://security-tracker.debian.org/busybox lists
> the following issues.
> 

I'd be happy with this in general, but the udeb means we need an
explicit d-i RM ack; CCing appropriately.

Regards,

Adam

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hello release team,

there are several non-dsa issues open for busybox. Now wearing the
maintainer's hat (together with Chris Boot, cc'd), I'd like to fix
them in an upcoming point release, for both jessie and stretch. I'll
file two separate request for these distributions, assuming this eases
handling on your side.

So for *stretch*, https://security-tracker.debian.org/busybox lists
the following issues.

* TEMP-0803097-A74121, #803097
  busybox: pointer misuse unziping files

  Fix: 
https://git.busybox.net/busybox/commit/?id=1de25a6e87e0e627aa34298105a3d17c60a1f44e
  Patch: cherry-pick.1_24_0-68-g1de25a6.unzip-test-for-bad-archive-segving.patch

* CVE-2016-2148, #818497
  Heap-based buffer overflow in the DHCP client (udhcpc) in BusyBox
  before 1.25.0 allows remote attackers to have unspecified impact via
  vectors involving OPTION_6RD parsing.

  Fix: 
https://git.busybox.net/busybox/commit/?id=352f79acbd759c14399e39baef21fc4ffe180ac2
  Patch: 
cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch

* CVE-2016-2147, #818499
  Integer overflow in the DHCP client (udhcpc) in BusyBox before 1.25.0
  allows remote attackers to cause a denial of service (crash) via a
  malformed RFC1035-encoded domain name, which triggers an
  out-of-bounds heap write.

  Fix: 
https://git.busybox.net/busybox/commit/?id=d474ffc68290e0a83651c4432eeabfa62cd51e87
  Patch: 
cherry-pick.1_24_0-152-gd474ffc.udhcp-fix-a-segv-on-malformed-rfc1035-encoded-domain-name.patch

* CVE-2011-5325, #802702
  Directory traversal vulnerability in the BusyBox implementation of
  tar before 1.22.0 v5 allows remote attackers to point to files
  outside the current working directory via a symlink.

  Fix: 
https://git.busybox.net/busybox/commit/?id=b920a38dc0a87f588d4731a8b887b5e16018
  Patch: 
cherry-pick.1_27_0-148-gb920a38dc.tar-postpone-creation-of-symlinks-with-suspicious-targets.patch
  Also the following was needed as a prerequisite for the tests:
  
cherry-pick.1_24_0-44-ga960748.tar-add-a-test-that-we-dont-write-into-symlinks.patch

Find the debdiff attached.

Cheers,
Christoph

-- System Information:
Debian Release: 9.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2016-04-17 17:37:25.0 +0200
+++ busybox-1.22.0/debian/changelog 2017-09-25 22:04:05.0 +0200
@@ -1,3 +1,15 @@
+busybox (1:1.22.0-19+deb9u1) stretch; urgency=medium
+
+  * Fix pointer misuse unziping files. Closes: #803097
+  * Fix Heap-based buffer overflow in the DHCP client.
+Closes: #818497 [CVE-2016-2148]
+  * Fix integer overflow in the DHCP client (udhcpc).
+Closes: #818499 [CVE-2016-2147]
+  * Fix directory traversal vulnerability in tar implementation.
+Closes: #802702 [CVE-2011-5325]
+
+ -- Christoph Biedl   Mon, 25 Sep 2017 
22:04:05 +0200
+
 busybox (1:1.22.0-19) unstable; urgency=medium
 
   * busybox-udeb, udhcpc: Remove /udhcpc/usr/share/udhcpc/default.script,
diff -Nru 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
--- 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
1970-01-01 01:00:00.0 +0100
+++ 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
2017-09-25 22:04:05.0 +0200
@@ -0,0 +1,58 @@
+Subject: Udhcpc: fix OPTION_6RD parsing (could overflow its malloced buffer)
+ID: CVE-2016-2148
+Origin: 1_24_0-139-g352f79a
+Upstream-Author: Denys Vlasenko 
+Date: Fri Feb 26 15:54:56 2016 +0100
+Bug-Debian: https://bugs.debian.org/818497 
+
+--- a/networking/udhcp/common.c
 b/networking/udhcp/common.c
+@@ -140,7 +140,7 @@
+  * udhcp_str2optset: to determine how many bytes to allocate.
+  * xmalloc_optname_optval: to estimate string length
+  * from binary option length: (option[LEN] / dhcp_option_lengths[opt_type])
+- * is the number of elements, multiply in by one element's string width
++ * is the number of elements, multiply it by one element's string width
+  * (len_of_option_as_string[opt_type]) and you know how wide string you need.
+  */
+ const uint8_t dhcp_option_lengths[] ALIGN1 = {
+@@ -160,7 +160,18 @@
+   [OPTION_S32] = 4,
+   /* Just like OPTION_STRING, we use minimum length here */
+   [OPTION_STATIC_ROUTES] = 5,
+-  [OPTION_6RD] =22,  /* ignored