Bug 22433 - glibc new security issues CVE-2017-16997 and CVE-2018-1000001
Summary: glibc new security issues CVE-2017-16997 and CVE-2018-1000001
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA5-64-OK MGA5-32-OK
Keywords: advisory, validated_update
Depends on: 22375
Blocks:
  Show dependency treegraph
 
Reported: 2018-01-21 02:00 CET by David Walser
Modified: 2018-01-25 13:48 CET (History)
5 users (show)

See Also:
Source RPM: glibc-2.20-26.mga5.src.rpm
CVE:
Status comment:


Attachments
memusage example from man pages (584 bytes, text/plain)
2018-01-22 10:11 CET, Len Lawrence
Details

Description David Walser 2018-01-21 02:00:54 CET
+++ This bug was initially created as a clone of Bug #22375 +++

A security issue in glibc has been announced today (January 11):
http://openwall.com/lists/oss-security/2018/01/11/5

There's a suggested (mostly untested) patch, but it sounds like this issue was only reported upstream recently, so probably no patch has been committed there yet.

Mageia 5 and Mageia 6 are also affected.

Patches checked into Mageia 5 SVN.  Sysadmins, please push to updates_testing.
Comment 1 Thomas Backlund 2018-01-21 02:38:19 CET
NO.

Mga5 is EOL since 31.12.2017, so stop wasting time on it

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX
CC: (none) => tmb

Comment 2 David Walser 2018-01-21 02:59:47 CET
It's not a waste of time.  I'm still using it, as are many others.  Our infra is still using it, and this would be one that should probably still be fixed there too.  This is the easiest way to do that, as the work's all being done for you rather than all of it falling on the sysadmin team (which means falling by the wayside if we're being honest).  I'm limiting work on Mageia 5 to core packages that would impact infra or most users.  The QA team even was OK with still doing some work on it (for example, https://bugs.mageia.org/show_bug.cgi?id=22328#c10 ) which was even a surprise to me.  Fixes that require little effort don't hurt anything.  Also the QA team was already expecting a few select updates such as Firefox.  If you want to shut it down after the current batch gets through then fine, but it's not gonna hurt anything to do a few more that are queued up already.
Comment 3 David Walser 2018-01-21 03:03:40 CET
Also note that when we initially agreed to extend the EOL, we also said we'd try to fix two important bugs (besides the important security issues that we could).  One was the KDM issue, which I fixed on December 31st.  The other was the applet upgrade issue, which we have still not fixed, Martin is still working on, and is one of the reasons we never turned the upgrade applet back on and one of the reasons we have still delayed the EOL announcement.
Comment 4 Thomas Backlund 2018-01-21 13:34:08 CET
Well if QA thinks they dont have enough to do... I wont hold them back... I've re-opened mga5
Comment 5 David Walser 2018-01-21 14:55:25 CET
Thanks Thomas.  Remember that one of the reasons I was doing this was to help you with the infrastructure.  :o)  I'll start a new thread on the QA list about how we will wind down Mageia 5.

Status: RESOLVED => REOPENED
Resolution: WONTFIX => (none)

Comment 6 David Walser 2018-01-21 15:05:25 CET
Advisory:
========================

Updated glibc packages fix security vulnerabilities:

An issue in the code handling RPATHs was fixed that could have been
exploited by an attacker to execute code loaded from arbitrary
libraries (CVE-2017-16997).

A privilege escalation bug in the realpath() function when the getcwd()
system call doesn't return a valid absolute pathname (CVE-2018-1000001).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16997
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10000001
https://lists.opensuse.org/opensuse-updates/2018-01/msg00033.html
========================

Updated packages in core/updates_testing:
========================
glibc-2.20-27.mga5
glibc-devel-2.20-27.mga5
glibc-static-devel-2.20-27.mga5
glibc-profile-2.20-27.mga5
nscd-2.20-27.mga5
glibc-utils-2.20-27.mga5
glibc-i18ndata-2.20-27.mga5
glibc-doc-2.20-27.mga5

from glibc-2.20-27.mga5.src.rpm

Assignee: sysadmin-bugs => qa-bugs

Lewis Smith 2018-01-21 20:47:43 CET

Keywords: (none) => advisory

Comment 7 Len Lawrence 2018-01-22 03:35:45 CET
Making a start on this for Mageia 5 :: x86_64.

Checking the CVEs before updating - gllibc seems important enough to warrant this.
Test for CVE-2017-16997
https://sourceware.org/bugzilla/show_bug.cgi?id=22625
The one-line command returned various errors which effectively aborted the test.
It looked like it needed to be run as root.
# ln -snf /dev/null libc.so.6 && rm -rf d && mkdir -m0700 d && cd d && echo 'int main(){}' |gcc -xc - -Wl,-rpath,'$ORIGIN' && chgrp -h apache a.out && chmod 02710 a.out && cd .. && d/a.out

Before update, should return:
d/a.out: error while loading shared libraries: libc.so.6: file too short

In fact the attempt to link libc to /dev/null failed - it was treated as an attempt to remove the library.  Found a way to run it by pasting it to a file and then setting the setuid bit on it.  No doubt there is a better way.
# chmod 02710 glibc_16997
# ll glibc*
-rwx--s--- 1 lcl lcl 186 Jan 22 02:09 glibc_16997*
# ./glibc_16997
d/a.out: error while loading shared libraries: libc.so.6: file too short

That is relatively simple but following the CVE trail turns up some very complex discussions so this is raincheck time.  An example can be found starting at https://www.suse.com/security/cve/CVE-2017-1000366/ leading to some kind of reproducer: https://bugzilla.suse.com/show_bug.cgi?id=1071319

To be continued...

CC: (none) => tarazed25

Comment 8 Len Lawrence 2018-01-22 10:09:12 CET
Ran the glibc updates, rebooted and tried the CVE 16997 test.

# ln -snf /dev/null libc.so.6 && rm -rf d && mkdir -m0700 d && cd d && echo 'int main(){}' |gcc -xc - -Wl,-rpath,'$ORIGIN' && chgrp -h apache a.out && chmod 02710 a.out && cd .. && d/a.out
#
which looks good, I think, since the program does nothing.

This is a clean update but how to test glibc?  Just run the compiler on something complex like a local build?  glibc-utils provides memusage, mtrace and xtrace.
Started a virtualbox session and 
$ memusage --progname=/usr/lib64/virtualbox/VirtualBox
No program name given
Tried the example from the man pages - source attached;
$ memusage --data=memusage.dat ./memorex
malloc: 400
realloc: 440
realloc: 1040
......................
Memory usage summary: heap total: 45200, heap peak: 6440, stack peak: 208
         total calls   total memory   failed calls
 malloc|          1            400              0
realloc|         40          44800              0  (nomove:40, dec:19, free:0)
 calloc|          0              0              0
   free|          1            440
Histogram for block sizes:
  192-207             1   2% ================
  400-415             3   7% ==================================================
................................................
6432-6447             1   2% ================

Soliciting comments on further tests....
Comment 9 Len Lawrence 2018-01-22 10:11:55 CET
Created attachment 9919 [details]
memusage example from man pages

$ gcc -o memorex memorex.c
Comment 10 Lewis Smith 2018-01-22 14:52:57 CET
Following M5/64

AFTER update only:
 glibc-2.20-27.mga5
 glibc-devel-2.20-27.mga5
 glibc-utils-2.20-27.mga5
and these are the utils programs:
- memusage - profile memory usage of a program (has man page)       
- memusagestat - generate graphic from memory profiling data (has man page)
Len has already persued these two OK; also the PoC.

- mtrace - interpret the malloc trace log (has man page)    [Forget].
- pcprofiledump - Dump information generated by PC profiling ?
- xtrace - Usage: xtrace [OPTION]... PROGRAM [PROGRAMOPTION]
All my attempts to use this:
 $ or # <program>
failed: "executable `<program>' not found"
Better was:
 $ xtrace /usr/bin/ls
Function              File                                                  Line
--------------------------------------------------------------------------------
Failed to parse arguments: Opsiwn anhysbys -c
^C
= unknown option -c ; for any program.

I shall use the system & only report back *if* problem noted. Default is OK.

CC: (none) => lewyssmith

Comment 11 Len Lawrence 2018-01-22 18:32:51 CET
I think we can pass this one along and watch for any reported regressions from other users.

Whiteboard: (none) => MGA5-64-OK

Comment 12 James Kerr 2018-01-22 19:59:14 CET
I had this update running for most of today on mga5-64 and, in a VM, on mga5-32.

I didn't use it a lot, but I did test a number of commonly used applications, including firefox and LO. 

I saw no problems on either arch.

CC: (none) => jim

Comment 13 Thomas Andrews 2018-01-23 01:49:55 CET
Installed this into a 32-bit mga5 KDE4 system on real hardware. 

I did not attempt to test the CVE, but I did run several apps after the update, and saw no issues. 

I considered adding the 32-bit OK, but glibc is important enough that it should probably see more tests on other systems.

CC: (none) => andrewsfarm

Comment 14 Len Lawrence 2018-01-23 09:06:51 CET
@Thomas Andrews re comment 13 and James Kerr comment 12.  Thanks for doing those 32-bit tests.  And yes, glibc is pretty fundamental.
$ urpmq --whatrequires-recursive glibc | sort -u | wc -l    
31778

I would guess that variety of hardware is not important but a spread of software may be.  It has been pointed out that Cauldron has given it a fair hammering so if nobody comes up with a problem in the next couple of days I am going to validate it.
Comment 15 Lewis Smith 2018-01-24 21:25:13 CET
M5/64
Having lived briefly with this update, it is OK for me. Second the x64 OK.

CC: lewyssmith => (none)

Len Lawrence 2018-01-25 10:18:42 CET

CC: (none) => sysadmin-bugs
Whiteboard: MGA5-64-OK => MGA5-64-OK MGA5-32-OK
Keywords: (none) => validated_update

Comment 16 Mageia Robot 2018-01-25 13:48:23 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0098.html

Resolution: (none) => FIXED
Status: REOPENED => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.