[blfs-support] Perl vulnerabilities

[Ken Moffat via blfs-support]

People who *use* their BLFS system(s), as distinct from those who
only build them to see how things fit together, are hopefully
subscribed here, so although perl is an LFS package I'm posting
here.

New point releases for perl (5.28.1 and 5.26.3) were released at the
end of November, containing security fixes as well as bugfixes.

For 5.28.1 the security fixes are:

[CVE-2018-18311] Integer overflow leading to buffer overflow and
segmentation fault

[CVE-2018-18312] Heap-buffer-overflow write in S_regatom (regcomp.c)

For the latter: A remote user user can create a specially crafted
regular expression to cause a heap overflow in S_regatom in
'regcomp.c' during compilation and potentially execute arbitrary
code.

The unfortunate thing about upgrading perl to a newer version is
that extra modules (in site_perl) will no-longer be in the right
place. On my current systems (LFS-8.3 and later) I've got many
extra modules. So for 5.28.1 I'm going to do what I did when
5.22.1 came out - patch 5.28.0 with the fixes but not with the newer
version number, then rebuild.

Fortunately, the changes include extra tests so when my patch is
incomplete I find out (got the T-shirt from 5.28, looks like I'm
maybe going to get another for 5.26).

Attached is a patch for 5.28. Note that the affected files are
read-only, but patch manages to apply the changes.

I plan to do an LFS build later, for this and maybe for something
else, and I'll then pick up the LFS ticket unless someone beats me
to it. But before that I'll be trying to do a similar (larger)
patch for perl-5.26.1 which has had two sets of security fixes - I
only care about that because I've got some old LFS-8.2 systems which
I claim to keep maintained.

Äžen

[Ken Moffat via blfs-support]

Post by Ken Moffat via blfs-support
I plan to do an LFS build later, for this and maybe for something
else, and I'll then pick up the LFS ticket unless someone beats me
to it. But before that I'll be trying to do a similar (larger)
patch for perl-5.26.1 which has had two sets of security fixes - I
only care about that because I've got some old LFS-8.2 systems which
I claim to keep maintained.

The perl-6.26.1 patch is deferred - 3 extra test failures in
'porting' on my first attempt. One is because I did not update the
copyright date (I ignored that, along with added documentation for
past releases etc, and along with the many places where the version
is hardcoded). Not sure about the other two, so deferring.

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.

Maintenance is fun, isn't it.

ĸen

[Ken Moffat via blfs-support]

Post by Ken Moffat via blfs-support
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.

Dropped the "assert on invocation" patch - its test fails when
applied to 2.28 (specifically, all 5 parts of the test expect a
value of -6 but get a value of 6). Passes in glibc-master, so it
must depend on something else there. But master is where the
pythonization of glibc is taking place, so I'm not looking at
previous changes there, I suspect the early stages of using python
might break things in LFS.

Is grumpiness contagious ?

ĸen

[Bruce Dubbs via blfs-support]

Post by Ken Moffat via blfs-support

Post by Ken Moffat via blfs-support
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?

Post by Ken Moffat via blfs-support
Dropped the "assert on invocation" patch - its test fails when
applied to 2.28 (specifically, all 5 parts of the test expect a
value of -6 but get a value of 6). Passes in glibc-master, so it
must depend on something else there. But master is where the
pythonization of glibc is taking place, so I'm not looking at
previous changes there, I suspect the early stages of using python
might break things in LFS.

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.

If anyone is running a production system based on our -dev books, then I
question that decision.

Post by Ken Moffat via blfs-support
Is grumpiness contagious ?

Sometimes, but not this time.

-- Bruce

[Ken Moffat via blfs-support]

Post by Ken Moffat via blfs-support
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.

[Bruce Dubbs via blfs-support]

Post by Ken Moffat via blfs-support

Post by Bruce Dubbs via blfs-support
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
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).

Thank you. It is helpful but it is also a bit hard to follow without
the /misc/packages and ${KM_SCRIPTS}/functions; but I see they are not
essential for understanding what you are doing.

What's happened to me in the past is when I do the 'make install' the
system no longer works. but I suppose if it is only a patch to the
current version then it would probably work.

Post by Ken Moffat via blfs-support

Post by Bruce Dubbs via blfs-support
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.

That's true on both counts. My general position is that if upstream
does not think it is important enough to do a release, why should we?

Not all bugs, even CVEs, are equal.

What I really don't want to do is the extra work of creating a patch and
updating the book when a new release then creates more work to remove
that patch from the book.

Post by Ken Moffat via blfs-support

Post by Bruce Dubbs via blfs-support
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.

For our 8,3 release, then the comments should go in the errata. It's
not very likely that a user of a 8.3 release will look in the -dev book.

I do note that the patch you included only really changes 3 significant
lines:
+ }

...

+ switch (model)
+ {

Comments, NEWS, and ChangeLog don't affect the build,


-- Bruce

[Ken Moffat via blfs-support]

Thank you. It is helpful but it is also a bit hard to follow without the
/misc/packages and ${KM_SCRIPTS}/functions; but I see they are not
essential for understanding what you are doing.

/misc/packages is a file specifying the hostname (to check that the
hostfile I use is for the right machine), the log name (i.e. the LFS
version), the details for /etc/lfs, and the
packages/versions/patches in LFS.

There are higher-level scripts which run the package scripts, they
define KM_SCRIPTS in relation to themselves - all are in my git
tree. The functions started by doing things like measuring space
and calculating SBUs, then added things like untarring (back in the
day when tar -xf needed to be told if it was a gzip or bz2 tarball),
expansions for compressed patches and patches not using -p1,
handling zipped files. You really don't need to see them to
understand the basics of what I'm doing.

What's happened to me in the past is when I do the 'make install' the system
no longer works. but I suppose if it is only a patch to the current version
then it would probably work.

It should work - I had the same misgivings, but I first needed it to
patch glibc for an audio fix, back when building took a long time.

But between increasingly-distant glibc versions too much changes and
a fresh build is often the best approach..

The great thing about glibc and perl is that major changes get
additional tests - that is how I got the perl-5.28 stuff working,
but also why I know that my perl-5.26 attempt is not correct.

Post by Ken Moffat via blfs-support

Post by Bruce Dubbs via blfs-support
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.

For our 8,3 release, then the comments should go in the errata. It's not
very likely that a user of a 8.3 release will look in the -dev book.

Some of us try to encourage that.

I do note that the patch you included only really changes 3 significant
+ }
...
+ switch (model)
+ {
Comments, NEWS, and ChangeLog don't affect the build,

That part is only the haswell additions. Take a look at the
if_index.c part which is the important part. For the ChangeLog and
NEWS, it was easy-enough to fix up the rejections on this occasion.

ĸen

[Baho Utot via blfs-support]

Post by Ken Moffat via blfs-support
Is grumpiness contagious ?
ĸen

No, just a sign of old age