+++ 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.
NO. Mga5 is EOL since 31.12.2017, so stop wasting time on it
Status: NEW => RESOLVEDResolution: (none) => WONTFIXCC: (none) => tmb
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.
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.
Well if QA thinks they dont have enough to do... I wont hold them back... I've re-opened mga5
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 => REOPENEDResolution: WONTFIX => (none)
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
Keywords: (none) => advisory
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
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....
Created attachment 9919 [details] memusage example from man pages $ gcc -o memorex memorex.c
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
I think we can pass this one along and watch for any reported regressions from other users.
Whiteboard: (none) => MGA5-64-OK
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
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
@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.
M5/64 Having lived briefly with this update, it is OK for me. Second the x64 OK.
CC: lewyssmith => (none)
CC: (none) => sysadmin-bugsWhiteboard: MGA5-64-OK => MGA5-64-OK MGA5-32-OKKeywords: (none) => validated_update
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0098.html
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED