Project

General

Profile

Bug #2595

[iceweasel]: upgrade to v72.0.1

eliotime3000 - 16 days ago - . Updated 6 days ago.

Status:
in progress
Priority:
bug
Assignee:
% Done:

0%


Description

Zero-day report (CVE-2019-17026) for Firefox 72 and below

On Thursday, January 9th, Mozilla reported a bug that has been classified as CVE-2019-17026, which has been applied into the release and ESR branches of Firefox. The versions of Firefox that has been applied this zero-day patches are:

#Release branch:
##72.0.1

#ESR branch:
##62.4.1

The bug details a failure of SpiderMonkey that makes it vulnerable to attacks.

Anyway, please update Iceweasel ASAP (if could be possible, also in 32-bit and ARMv7 builds, too).

Thanks.

History

#1

Updated by bill-auger 7 days ago

  • Assignee set to bill-auger
  • Status changed from unconfirmed to in progress
  • Description updated (diff)
  • Subject changed from [iceweasel] Zero-day report (CVE-2019-17026) for Firefox 72 and below to [iceweasel]: upgrade to v72.0.1
#2

Updated by bill-auger 6 days ago

  • the symlink /usr/lib/iceweasel/iceweasel-bin exists as it should
  • the symlink points to the script /usr/bin/iceweasel as it should
  • the script /usr/bin/iceweasel executes /usr/lib/iceweasel/iceweasel as it should
  • but the binary /usr/lib/iceweasel/iceweasel is missing
  • instead, the real binary got put under /usr/local/
  • the name of the binary dir is /usr/local/lib/firefox
  • the name of the binary is /usr/local/lib/firefox/firefox
  • /usr/local/bin/firefox is a symlink pointing to /usr/local/lib/firefox/firefox
  • there are identical binaries at /usr/local/lib/firefox/{firefox,firefox-bin}

one of the identical binaries would have been replaced by a symlink in this LOC:

ln -srfv "$pkgdir/usr/bin/$pkgname" "$pkgdir/usr/lib/$pkgname/$pkgname-bin"

that did happen; but $pkgname was 'icewaesel' and there was no binary to replace

the only place i can see the prefix being set is the line that writes the mozconfig file:

ac_add_options --prefix=/usr

i checked the mozconfig file in the build chroot; and it looks just how it should

the good news is that the browser does work

#3

Updated by bill-auger 6 days ago

i may see the problem - i had checked the mozconfig file in the srcdir - but that one needs to be copied into the mozilla source root as .mozconfig - there are two places where this LOC happens:

cat >.mozconfig ../mozconfig - <<END

i moved them both into the x86_64 guarded section - maybe i686 got built with all defaults; due to the mozconfig being missing or incomplete - if so, them the second one (below msg2 "Building optimized browser...") needs to be split; so that it can copy the mozconfig file; but not add in the x86_64-specific params

Also available in: Atom PDF