glibc: Schwergewichtige Lücke in Linux

[Frogman]

Wie man heute lesen kann, schlummert in der glibc-Bibliothek eine sehr schwergewichtige Lücke. Hoffen wir auf schnelle Behebung...

 

[jahlives]

die grossen Hersteller haben zum Glück gepatchte Versionen draussen. Habe heute Vormittag einen Update-Marathon gehabt

 

[dany]

Ja, die grossen haben schon gestern updates rausgebracht. Bin gerade auch mit allen Servern durch

Wer OpenWRT im Einsatz hat kann sich mit der minimierung der Packetgrösse behelfen.
https://forum.openwrt.org/viewtopic.php?pid=311806#p311806

 

[amarthius]

Ich nehme an das Synology glibc verwendet, richtig?

 

[dil88]

Definitiv

 

[dany]

Einfach aufrufen, dann sieht man die Version:

/lib/libc.so.6

 

[DKeppi]

Bei meiner 415+ kommt das raus:

GNU C Library stable release version 2.13, by Roland McGrath et al.
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.6.4.
Compiled on a Linux 3.2.48 system on 2015-06-06.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC

Hab dann nebenbei noch die 2.20-3 per optware installiert!

 

[Frogman]

Alle Versionen ab 2.9 sind wohl betroffen. Aktuell gibt es keine offiziell bereinigte Version von glibc (da ist 2.22 aus Mitte 2015 aktuell), sondern nur entsprechende Patches der Distributionen mit ihren individuellen Versionsschemata für Patchlevels. Da warten wir mal auf die DSM-5.2-5644-Update 5.

 

[till213]

Alle Versionen ab 2.9 sind wohl betroffen.

Für die, die's (noch) interessiert: Somit dürfte die letzte DSM 4.3 zumindest von dieser Lücke nicht betroffen sein. Dort ist nämlich noch die glibc 2.8 im Einsatz:

DiskStation> /lib/libc.so.6
GNU C Library stable release version 2.8, by Roland McGrath et al.
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.3.2.
Compiled on a Linux >>2.4.18-3<< system on 2009-11-11.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
Support for some architectures added on, not maintained in glibc core.
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

 

[DKeppi]

Dafür hat man mit 4.3 wohl so einige andere Lücken

 

[Puppetmaster]

Aha, und welche?

 

[DKeppi]

Na alle CVE's die seit Oktober 2014 so bereinigt wurden, da es Ende Sept. 2014 das letzte update-pack für DSM 4.3 gab!

Version: 4.3-3827 Update 8 (2014/09/29)

 

[Puppetmaster]

Naja, nicht jeder Bug eines DSM 5.2 muss auch schon in 4.3 beheimatet gewesen sein. Siehe eben auch glibc.

Ist für mich immer eine Milchmädchenrechnung. Nur weil die Version neuer ist, muss die Sicherheit nicht größer sein. Zumindest nicht in einem überschaubaren Zeitrahmen.

 

[DKeppi]

Ja da gebe ich dir natürlich Recht
4.3 wäre mir persönlich aber trotzdem etwas zu veraltet, sofern es keine alte Syno ist die gar kein 5.0 mehr bekommen hat...

 

[dany]

Der Fix zur Lücke CVE-2015-7547 ist nun verfügbar.

Version: 5.2-5644 Update 5

(2016/02/19)
Fixed Issues

Updated Firewall filter policy to fix a security vulnerability caused by stack-based buffer overflow (CVE-2015-7547). This fix may impact read/write performance on the following models by no more than 15%, for which Synology is working on an enhancement in the future release.
16-series: DS216se
15-series: DS115j
14-series: EDS14, DS114, DS214se, RS214, DS414slim
13-series: DS213j, DS213air, DS213, DS413j
12-series: DS112, DS112+, DS112j, DS212, DS212j, DS212+, RS212, RS812
11-series: DS111, DS211, DS211+, DS211j, DS411, DS411slim, DS411j, RS411
10-series: DS110j, DS210j, DS410j

 

[Matthieu]

Der Fix zur Lücke CVE-2015-7547 ist nun verfügbar.

Streng genommen kein Fix, sondern ein Workaround. Ein echter Fix per Patch dürfte aufwändiger sein. Oder vielleicht verursacht er im DSM sogar Probleme weshalb Synology diesen Weg wählt. Egal wie rum, das Leck ist dicht, auf einen "echten" Fix können wir nur warten und warum es so kommt werden wir wohl eh nie erfahren.

MfG Matthieu

 

[Matthieu]

Ist für mich immer eine Milchmädchenrechnung. Nur weil die Version neuer ist, muss die Sicherheit nicht größer sein. Zumindest nicht in einem überschaubaren Zeitrahmen.

Das trifft nur zu, wenn der Hersteller des OS die Patches backported, was u.a. bei Debian gängige Praxis ist. Das heißt die Lücke wird gefixt indem man den Code auch in der alten Version ändert aber nicht alle anderen Änderungen mitnimmt. Mit Worten ist das irgendwie schwer zu beschreiben ...
Bei glibc kann man in das Changelog schauen und muss dann die Nummern der Bugreports querprüfen. http://upstream.rosalinux.ru/changelogs/glibc/2.13/changelog.html (2.13 als Versionsstand wie von DKeppi ermittelt, für andere Versionen die URL ändern)
Beispiel für eine offene, nicht gepatchte Lücken in glibc 2.8 gegenüber 2.13:
https://sourceware.org/bugzilla/show_bug.cgi?id=10418

Mal eine große Suche in der Bug-DB von glibc für die Versionen 2.9-2.13 ist erschreckend:
https://sourceware.org/bugzilla/bug...n=2.10&version=2.11&version=2.12&version=2.13
Wohlgemerkt sind die alle mit Prio 1 oder 2 und dem Flag "security".

MfG Matthieu

 

[dany]

Streng genommen kein Fix, sondern ein Workaround

Stimmt, Workaround ist passender

Hatte gestern Abend auf meinem Router schon was ähnliches gemacht:

iptables -A INPUT -p udp --sport 53 -m connbytes --connbytes 512: --connbytes-dir reply --connbytes-mode bytes -j DROP
iptables -A INPUT -p tcp --sport 53 -m connbytes --connbytes 512: --connbytes-dir reply --connbytes-mode bytes -j DROP

 

[Frogman]

So, nun gibt es im Rahmen des regulären Updates auf 2.23 eine neue glibc, die (neben vielem anderen) den beschriebenen buffer overflow behebt.
Schauen wir mal, ob Synology mit dem nächsten Update den teilweise wenig performanten Workaround ersetzt...

 

[jahlives]

@dany ich hoffe du hast keinen DNS Server hinter dieser iptables Regel, der auf Zonentransfers angewiesen wäre oder dnssec verwendet