Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
glibc vulnerability: best way to recompile the whole system?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
el muchacho
Tux's lil' helper
Tux's lil' helper


Joined: 26 Mar 2015
Posts: 77

PostPosted: Wed Feb 17, 2016 10:39 am    Post subject: glibc vulnerability: best way to recompile the whole system? Reply with quote

Hi,

you may have been informed of a serious BOF vulnerability in glibc for anything that uses getaddrinfo (which is pretty much anything converting a URL to an IP).

It's also easily exploitable, all you need is to be lured into making a DNS request for a carefully crafted URL that will result in code execution.

On a Gentoo system, on a patched glibc, what's the best approach to re-emerge everything correctly ? I've never done this sort of wide-sweeping recompile of a whole system... :?
Back to top
View user's profile Send private message
charles17
Advocate
Advocate


Joined: 02 Mar 2008
Posts: 2613

PostPosted: Wed Feb 17, 2016 11:21 am    Post subject: Re: glibc vulnerability: best way to recompile the whole sys Reply with quote

el muchacho wrote:
Hi,

you may have been informed of a serious BOF vulnerability in glibc for anything that uses getaddrinfo (which is pretty much anything converting a URL to an IP).

Aka bug 574880#c11

el muchacho wrote:
On a Gentoo system, on a patched glibc, what's the best approach to re-emerge everything correctly ?
Try emerge --keep-going -e @world
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Wed Feb 17, 2016 11:48 am    Post subject: Re: glibc vulnerability: best way to recompile the whole sys Reply with quote

el muchacho wrote:
you may have been informed of a serious BOF vulnerability in glibc for anything that uses getaddrinfo (which is pretty much anything converting a URL to an IP).

el muchacho ... yes, but I'd take that as a cautious warning, rather than "the sky is falling".

el muchacho wrote:
It's also easily exploitable, all you need is to be lured into making a DNS request for a carefully crafted URL that will result in code execution.

No, "Google said it is very hard to exploit the flaw although their engineers have worked out how."

el muchacho wrote:
On a Gentoo system, on a patched glibc, what's the best approach to re-emerge everything correctly ? I've never done this sort of wide-sweeping recompile of a whole system... :?

You won't need to "re-emerge everything", once glibc is patched anything using getaddrinfo will call the patched glibc ... that's the beauty of a library.

best ... khay
Back to top
View user's profile Send private message
xaviermiller
Administrator
Administrator


Joined: 23 Jul 2004
Posts: 7972
Location: ~Brussels - Belgique

PostPosted: Wed Feb 17, 2016 12:17 pm    Post subject: Reply with quote

The only thing to do is reboot after updating glibc, in order to be sure that every executable is using the new library.
_________________
Kind regards,
Xavier Miller
Back to top
View user's profile Send private message
c00l.wave
Apprentice
Apprentice


Joined: 24 Aug 2003
Posts: 245

PostPosted: Wed Feb 17, 2016 7:13 pm    Post subject: Reply with quote

... except for the Linux kernel and other statically linked binaries such as those listed by:

Code:
eix --compact --installed-with-use static; eix --compact --installed-with-use static-libs


However, only busybox was affected for me and I'm not sure it even uses glibc; wasn't it some smaller library such as ulibc?

As far as I can see, potential threats inside the Linux kernel are the usbip module in earlier kernel versions (3.12) as well as some tools. (see: grep -Ri getaddrinfo /usr/src/linux/)
_________________
nohup nice -n -20 cp /dev/urandom /dev/null &
Back to top
View user's profile Send private message
toralf
Developer
Developer


Joined: 01 Feb 2004
Posts: 3684
Location: Hamburg

PostPosted: Wed Feb 17, 2016 8:14 pm    Post subject: Reply with quote

c00l.wave wrote:
... except for the Linux kernel and other statically linked binaries such as those listed by:

Code:
eix --compact --installed-with-use static; eix --compact --installed-with-use static-libs

Hhm, shouldn't this then made into a portage tool -or- at least an elog should be printed if glibc was updated ?
Back to top
View user's profile Send private message
schorsch_76
Guru
Guru


Joined: 19 Jun 2012
Posts: 450

PostPosted: Wed Feb 17, 2016 8:45 pm    Post subject: Reply with quote

It seems glsa-check is not working:

https://security.gentoo.org/glsa/201602-02
Shows what version is affected.

My system:
Code:
equery l sys-libs/glibc
 * Searching for glibc in sys-libs ...
[IP-] [  ] sys-libs/glibc-2.21-r1:2.2


The above site tells me:
Quote:
Affected Packages
Package sys-libs/glibc on all architectures
Affected versions < 2.21-r2
Unaffected versions >= 2.21-r2


But glsa-check
Code:
glsa-check --test all
This system is not affected by any of the listed GLSAs


My emerge
Code:
1455402834: Started emerge on: Feb 13, 2016 23:33:54
1455402834:  *** emerge  --sync
1455402834:  === sync
1455402834: >>> Syncing repository 'gentoo' into '/usr/portage'...
1455402899: === Sync completed for gentoo
1455402900:  *** terminating.
1455403208: Started emerge on: Feb 13, 2016 23:40:08
1455403208:  *** emerge --update --deep --ask --newuse @world @system
1455403263:  *** terminating.
1455741127: Started emerge on: Feb 17, 2016 21:32:06
1455741127:  *** emerge  --sync
1455741127:  === sync
1455741127: >>> Syncing repository 'gentoo' into '/usr/portage'...
1455741150: === Sync completed for gentoo
1455741151:  *** terminating.
1455741353: Started emerge on: Feb 17, 2016 21:35:53
1455741353:  *** emerge --ask --deep --update --newuse @world @system
1455741429:  *** terminating.

_________________
// valid again: I forgot about the git access. Now 1.2GB big. Start: 2015-06-25
git daily portage tree
Web: https://portage.schorsch-tech.de
git clone https://portage.schorsch-tech.de/portage.git
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Thu Feb 18, 2016 12:52 am    Post subject: Reply with quote

schorsch_76 wrote:
Quote:
Affected Packages
Package sys-libs/glibc on all architectures
Affected versions < 2.21-r2
Unaffected versions >= 2.21-r2

schorsch_76 ... I don't see the glsa-201602-02.xml in the tree (sync'ed this morning), it may simply be that the mirrors take time to catch up, and the above would have been posted as it entered the tree.

best ... khay
Back to top
View user's profile Send private message
hydrapolic
Tux's lil' helper
Tux's lil' helper


Joined: 07 Feb 2008
Posts: 124

PostPosted: Fri Feb 19, 2016 6:05 am    Post subject: Reply with quote

When you compile glibc on x86_64 with CFLAGS="-mtune=native" and create a binary package of it, can you safely transfer it to any other x86_64 machine with different CPU?
Back to top
View user's profile Send private message
Syl20
Guru
Guru


Joined: 04 Aug 2005
Posts: 564
Location: France

PostPosted: Fri Feb 19, 2016 10:00 am    Post subject: Reply with quote

No, you can't. The "native" arch and tune flags imply gcc looks for the local CPU capabilities to complile the sources. So, if the CPU on the distant machine doesn't have the same capabilities, the binary won't run as expected (even it won't run at all, if the distant CPU is older or really different than the local one).
Back to top
View user's profile Send private message
hydrapolic
Tux's lil' helper
Tux's lil' helper


Joined: 07 Feb 2008
Posts: 124

PostPosted: Fri Feb 19, 2016 10:27 am    Post subject: Reply with quote

CneGroumF wrote:
No, you can't. The "native" arch and tune flags imply gcc looks for the local CPU capabilities to complile the sources. So, if the CPU on the distant machine doesn't have the same capabilities, the binary won't run as expected (even it won't run at all, if the distant CPU is older or really different than the local one).


So only mtune=generic (without march) will do the job I suppose.
Back to top
View user's profile Send private message
c00l.wave
Apprentice
Apprentice


Joined: 24 Aug 2003
Posts: 245

PostPosted: Fri Feb 19, 2016 11:02 am    Post subject: Reply with quote

Or just compile with a common subset of CPU features. If you plan to only deploy it on "recent" Intel machines (2007 or later) a "Safe CFLAGS" setting (as per the wiki page) for the oldest CPU to be supported should be sufficient. Same for AMD I suppose, as instruction sets are usually expanded and only rarely reduced.

BTW, I had some unpleasant surprise when updating a rather old system which took me a whole day to figure out: since version 2.19 glibc checks the instruction set on program start, then continues to use it directly (not controllable on compile-time) for some routines. If the instruction set suddenly reduces later on (such as when using an "old" Haswell CPU and removing transactional memory/TSX support by performing a microcode update "late" in boot process) programs will crash due to illegal opcodes. In particular, the Linux kernel will continue to use TSX for threading - which is no longer available and crashes multiple programs (due to libpthread-2.21.so). To solve that issue, if it's new for you, make sure you run the microcode update as early as possible - at latest at the beginning of the Linux boot process (any runlevel will be too late!), preferably even earlier (i.e. update your BIOS if you have physical access to the hardware).

It's an old problem, first appeared in mid/late 2014. However, I happened to install that server's VM host system half a month prior to the TSX-removal and I never got to perform a complete world update until now.
_________________
nohup nice -n -20 cp /dev/urandom /dev/null &
Back to top
View user's profile Send private message
schorsch_76
Guru
Guru


Joined: 19 Jun 2012
Posts: 450

PostPosted: Fri Feb 19, 2016 1:23 pm    Post subject: Reply with quote

Now glsa-check -l shows the CVE.

I know that glsas are only issued for a CVE if there is a patch for a CVE, and not if it is known but not yet a fix available. I would like to know, if there is a CVE on my system even when there is not yet a fix available. Is there a tool available which is able to show this?
_________________
// valid again: I forgot about the git access. Now 1.2GB big. Start: 2015-06-25
git daily portage tree
Web: https://portage.schorsch-tech.de
git clone https://portage.schorsch-tech.de/portage.git
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum