On Sat, Dec 01, 2018 at 06:28:28PM -0600, Bruce Dubbs via blfs-support wrote:
> On 12/01/2018 05:50 PM, Ken Moffat via blfs-support wrote:
> > On Sat, Dec 01, 2018 at 10:23:11PM +0000, Ken Moffat via blfs-support wrote:
> > > On Sat, Dec 01, 2018 at 08:00:20PM +0000, Ken Moffat via blfs-support
> > > wrote:
> > >
> > > Concentrating now on trying to update glibc (one CVE, one "assert
> > > on invocation rather than segfault on exit", one "regression -
> > > slowness in string operations - in certain haswells" which might
> > > affect mine : the change implies new firmware might make the fix
> > > irrelevant, but the problem was seen even in fedora.
> > >
> > > Still testing (only having 4GB for /tmp, and filling that up with
> > > past builds and DESTDIRs, blew out my first attempt), but I've
> > > dusted off my "upgrade glibc" script in the hope this will work.
>
> I am interested in that script. I'm always quite reluctant to update glibc.
> To me it is the heart of the system. I am comfortable with live updates
> with any other package.
>
> I build a new system if I think a new glibc is needed.
>
> Can you post your script?
>
I've updated glibc in the past, but usually to the same version with
one or more patches.
My scripts are specific to how I do things, but I think it should be
reasonable comprehensible. Five notes:
0. My scripts may differ from the book about the minimum kernel
version. I also like them to tell me what is going on, so I
separate the logging and let scripts write to the screen. Also, of
course, I mostly build as the big guy. And I have functions to do a
lot of things, albeit perhaps they are not ideal (e.g. logging what
got installed/updated is sloow on a fully-built system and uses a lot
of space while still needing manual review before saying "oh yes,
just delete all those files").
1. Fiddling about with GCCINCDIR or -isystem will cause configure to
fail. Adding a libv_cv value to get past that (what Matt
recommended to Andy in 2010) will start to build, but eventually ld
will fail because /usr/include is a directory. So just omit that
line.
2. The nscd and locale parts are not normally needed. I've kept the
comments because I once needed to reinstall locales. I suspect that
might have been when I tried to update glibc on some previous
LFS releases after the last big lot of vulnerabilities and had to
move to a newer version to get the fixes.
3. If I had put this in, I would have modified the explanation about
suppressing test-installation : on a *completed* LFS system it
failed after ld failed to load a couple of libnis* libraries.
4. After completing, Either fix it up (if unexpected test failures),
perhaps recover from a backup if tests failed (the script just runs
through after finding a build which ought to work, and allowing for
tests to fail), Or reboot ASAP. BUT when rebooting on sysv the LFS
umount script will fail, a message something like
umount: /: is busy.
That did give a clean filesystem after continuing, doing it on
systemd might be interesting (enabling MagicSysRQ on a machine is
always a good idea, unless untrusted people can access the
keyboard).
#!/bin/bash
# CVE-2018-19591 : potential DOS
#------------------------------------------------------------------------
set +h
set -e
. /misc/packages
KM_CURRENT=glibc-2.28
KM_PATCHES="glibc-2.28-fhs-1.patch glibc-2.28-upstream_fixes-1.patch"
. ${KM_SCRIPTS}/functions
km_checkargs1 $#
test -n "$KM_WHERE"
echo "executing $0 for ${1%%-stamp}"
cd $KM_WHERE
km_begin
rm -rf ${KM_DIRECTORY}
tar -x -f ${KM_PACKAGES}/${KM_CURRENT}
cd ${KM_DIRECTORY}
km_patchit &&
km_start_SBU
case $KM_HOSTARCH in
i?86)
# the book uses i486, which seems pretty silly to me
echo "building for i686"
echo "CFLAGS += -march=i686 -mtune=native" > configparms
;;
x86_64)
echo "building for x86_64"
;;
*)
echo "unexpected KM_HOSTARCH of $KM_HOSTARCH"
exit 1
;;
esac
KM_KERNELMINIMUM=3.9.0
echo "build"
mkdir build
cd build
echo "configure"
# Do NOT set GCCINCDIR or add -isystem /usr/include
../configure --prefix=/usr \
--disable-werror \
--enable-kernel=$KM_KERNELMINIMUM \
--enable-stack-protector=strong \
libc_cv_slibdir=/lib >>$KM_LOG 2>&1
echo "make"
make $MAKEFLAGS >>$KM_LOG 2>&1
set +e
echo "check"
make -k check > $KM_LOG.check 2>&1
set -e
# ensure the results of make check can be seen, in case it goes
# badly
grep FAIL $KM_LOG.check
# if test-installation is run, it fails - missing nis libs.
sed '/test-installation/s@$(PERL)@echo not running@' -i ../Makefile
echo "install"
make install >>$KM_LOG 2>&1
## Following retained, but commented
#echo "config for nscd"
#cp -v ../nscd/nscd.conf /etc/nscd.conf >>$KM_LOG 2>&1
#mkdir -pv /var/cache/nscd >>$KM_LOG 2>&1
# locales are already installed, do not repeat them
# in fact, I once got errors when I did not reinstall them!
#echo "locales"
#make localedata/install-locales >>$KM_LOG 2>&1
cd $KM_WHERE
# tidy up all other static libs and remove the source
km_finish $KM_DIRECTORY
#------------------------------------------------------------------------------
>
> I do not want to patch glibc in the lfs-dev book. It will automatically be
> incorporated in the next glibc release which is scheduled before we release
> the next version of LFS.
>
I have noted that you appear not to care greatly about
vulnerabilities unless they are accompanied by a new release. But
in BLFS we can often find a patch to solve the problem.
> If anyone is running a production system based on our -dev books, then I
> question that decision.
>
This also applies to our 8.3 *release*. And if anybody is running a
production system based on LFS/BLFS (and I have heard of people
doing that) they need to make their own decisions about
vulnerabilities - for many packages, running with what was in our
last release will expose you to known problems. Mostly, a single
problem on its own will not pwn you - but as in this case a DOS is
possible. For a home user just amusing themself on their own LFS
system, a DOS is not usually a big problem.
I'll attach the patch for anybody who cares.
--
I'm saving up 22 shillings and 10 pence (almost a pound!) per week to
buy an ARM-13.
http://www.antipope.org/charlie/blog-static/2018/11/brexit-means-brexit.html
Not now submitted By: Ken Moffat <ken at linuxfromscratch dot org>
Date: 2018-12-01
Initial Package Version: 2.28
Upstream Status: Applied
Origin: Upstream
Description: Selected upstream commits -
d527c860f5a3
CVE-2018-19591: if_nametoindex: Fix descriptor for overlong name [BZ #23927]
In short, untrusted hostname resolutions (via getaddrinfo()) lead to
descriptor exhaustion.
c3d8dc45c9df
x86: Fix Haswell strong flags (BZ#23709)
NB for this one, the change implies that latest microcode will override
the problem, but the issue has been reported on ubuntu and recent fedora
so I'm not sure how correct that is. And after Meltdown, intel CPUs need
all the help they can get.
diff -Naur a/ChangeLog b/ChangeLog
--- a/ChangeLog 2018-08-01 06:10:47.000000000 +0100
+++ b/ChangeLog 2018-12-01 20:30:04.231946237 +0000
@@ -1,3 +1,16 @@
+2018-11-27 Florian Weimer <[email protected]>
+
+ [BZ #23927]
+ CVE-2018-19591
+ * sysdeps/unix/sysv/linux/if_index.c (__if_nametoindex): Avoid
+ descriptor leak in case of ENODEV error.
+
+2018-10-23 Adhemerval Zanella <[email protected]>
+
+ [BZ #23709]
+ * sysdeps/x86/cpu-features.c (init_cpu_features): Set TSX bits
+ independently of other flags.
+
2018-08-01 Carlos O'Donel <[email protected]>
* version.h (RELEASE): Set to "stable".
diff -Naur a/NEWS b/NEWS
--- a/NEWS 2018-08-01 06:10:47.000000000 +0100
+++ b/NEWS 2018-12-01 20:31:32.880071932 +0000
@@ -240,6 +240,10 @@
architecture could write beyond the target buffer, resulting in a buffer
overflow. Reported by Andreas Schwab.
+ CVE-2018-19591: A file descriptor leak in if_nametoindex can lead to a
+ denial of service due to resource exhaustion when processing getaddrinfo
+ calls with crafted host names. Reported by Guido Vranken.
+
The following bugs are resolved with this release:
[1190] stdio: fgetc()/fread() behaviour is not POSIX compliant
diff -Naur a/sysdeps/unix/sysv/linux/if_index.c
b/sysdeps/unix/sysv/linux/if_index.c
--- a/sysdeps/unix/sysv/linux/if_index.c 2018-08-01 06:10:47.000000000
+0100
+++ b/sysdeps/unix/sysv/linux/if_index.c 2018-12-01 20:29:08.815492790
+0000
@@ -38,11 +38,6 @@
return 0;
#else
struct ifreq ifr;
- int fd = __opensock ();
-
- if (fd < 0)
- return 0;
-
if (strlen (ifname) >= IFNAMSIZ)
{
__set_errno (ENODEV);
@@ -50,6 +45,12 @@
}
strncpy (ifr.ifr_name, ifname, sizeof (ifr.ifr_name));
+
+ int fd = __opensock ();
+
+ if (fd < 0)
+ return 0;
+
if (__ioctl (fd, SIOCGIFINDEX, &ifr) < 0)
{
int saved_errno = errno;
diff -Naur a/sysdeps/x86/cpu-features.c b/sysdeps/x86/cpu-features.c
--- a/sysdeps/x86/cpu-features.c 2018-08-01 06:10:47.000000000 +0100
+++ b/sysdeps/x86/cpu-features.c 2018-12-01 20:25:28.851662214 +0000
@@ -316,7 +316,13 @@
| bit_arch_Fast_Unaligned_Copy
| bit_arch_Prefer_PMINUB_for_stringop);
break;
+ }
+ /* Disable TSX on some Haswell processors to avoid TSX on kernels that
+ weren't updated with the latest microcode package (which disables
+ broken feature by default). */
+ switch (model)
+ {
case 0x3f:
/* Xeon E7 v3 with stepping >= 4 has working TSX. */
if (stepping >= 4)
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
