PDA

Bekijk Volledige Versie : linux kernel Vulnerability 2.6.X



sander
17/07/06, 17:32
Er zijn paar ernstige kernel bugs gevonden,

http://www.securityfocus.com/bid/18992/info

en http://www.securityfocus.com/bid/18874

beste oplossing is om je kernel te upgraden naar
de laatste versie die beschikbaar is.

tijdelijke workaround zijn de volgende stappen:

echo > /proc/sys/kernel/core_pattern

en
mount -o remount,nosuid /proc

ik raad iedereen aan om zo spoeding mogelijk te upgraden,
exploit kan uitgevoerd worden via lekke php scripts.

bakkerl
17/07/06, 18:38
Ook het gebruikt van SELINUX onder Redhat4 (en CentOS4) helpt tegen deze exploit.

wv-
17/07/06, 19:15
Ook het gebruik van freebsd helpt tegen deze exploit :)

IMHO moeten ze toch iets doen aan hun kernel 2.6-policy, want 2.6 is allesbehalve een bugfree en stabiele kernel aan het worden. Altijd maar zoveel mogelijk features er in gooien, elke week een paar nieuwe kernel met security en bug fixes. En iedereen moet maar volgen. Deze 2 security bugs zijn misschien de ergste van 2006, maar er zijn er nog 20tal security bugs gevonden/gefixt voordien.

MikeN
17/07/06, 19:38
Ook het gebruikt van SELINUX onder Redhat4 (en CentOS4) helpt tegen deze exploit.
Met de PRCTL bug en een custom exploit valt daar volgens mij wel doorheen te komen, kwestie van de juiste plek om de data te vernaggelen vinden.

Ik begin het hele Linux een beetje zat te worden, gebruik het nou al jaren en al die jaren is het eigenlijk niets dan gezeik en vage bugs geweest, vaak geïntroduceerd tijdens een stabiele kernel serie.

Weet iemand overigens of je veel kapot maakt door je /proc nosuid te mounten? Zo nee, kan dat ding dan niet standaard nosuid gemount worden? :)

joriz
17/07/06, 20:17
exploit kan uitgevoerd worden via lekke php scripts.
PHP zo configureren die oa. uitvoeren van bestanden niet toelaat moet dan toch al voldoende zijn?

sander
17/07/06, 20:22
PHP zo configureren die oa. uitvoeren van bestanden niet toelaat moet dan toch al voldoende zijn?

sommige scripts/klanten zouden dit soms wel graag willen.

dit is inderdaad volgens mij 1 van de grootste fouten in de 2.6.x serie.

ik heb op vele servers vandaag proc met nosuid gemount en heeft tot nu geen problemen veroorzaakt

handy
17/07/06, 20:23
redhat heeft al een dikke week een update op rhn staan. Die kan je ook altijd even installeren (weg uptime :D)

bakkerl
17/07/06, 20:44
redhat heeft al een dikke week een update op rhn staan. Die kan je ook altijd even installeren (weg uptime :D)
Sinds wanneer is uptime heilig?

SebastiaanStok
17/07/06, 21:47
Dan te bedenken dat ik sinds de installtie van Redhat 9 de kernel niet meer heb bij gewerkt :)

Niet vanstandig ik weet het maar in die tijd wist ik nog niet hoe het moest,en een eigen kernel maken heb ik nog geen tijd voor ghad om te kijken en testen op de test bak :o

wv-
17/07/06, 21:55
gewoon de redhat9 kernel die updated is gebruiken, helemaal geen eigen kernel voor nodig.

SebastiaanStok
18/07/06, 11:09
Dat heb ik ook gedaan bij de test server alleen de productie server nog niet, daar komt bij die kernel is volgens mij ook ardig veroudert is :(

En hoe ik weet alleen hoe het moet met Lilo en heb dus weer het geluk dat er Grub op staat en niet zo 123 weet hoe dat werkt.

Maar ik heb nu even die workarounds to gepast.

bvankuik
18/07/06, 11:54
Ik begrijp nooit waarom je in vredesnaam een zelfgecompileerde kernel zou willen installeren, behalve op een testbak of je eigen machine thuis.

wv-
18/07/06, 12:26
extra patches, extra modules, extra zaken er uit, noem maar op. Er zullen heel veel mensen zijn die een custom kernel gebruiken.

bvankuik
18/07/06, 12:30
Ik hoop dat diezelfde mensen dan dagelijks Bugtraq doorsnorren. Want met een custom kernel wordt het lastig om de security updates van een vendor te gebruiken.

wv-
18/07/06, 12:34
Je kijkt gewoon wanneer een vendor nieuwe patches/kernel uit brengt. Er zijn zelfs vendors die pas om de 6 maanden een nieuwe kernel uit brengen, dan wil je al sneller een eigen kernel.

Het is natuurlijk ook mogelijk dat je een andere branche van patchsets volgt, bvb elke keer er een nieuwe grsecurity/WOLK versie uit komt, dat je dan pas upgrade. Een niet-default kernel is dus niet zo speciaal.

bvankuik
18/07/06, 12:54
Je kijkt gewoon wanneer een vendor nieuwe patches/kernel uit brengt.

Maar dat betekent toch dat je elke ochtend even moet kijken of er nieuwe security-gerelateerde kernel patches zijn? Vervolgens moet je je eigen kernel patchen en upgraden. Het kan dan nog zijn dat je een probleem hebt, omdat er voor jouw eigen custom kerneltje geen kant-en-klare patch is en je dus zelf moet gaan hobbyen.


Er zijn zelfs vendors die pas om de 6 maanden een nieuwe kernel uit brengen, dan wil je al sneller een eigen kernel.

Ik had het strikt over security-gerelateerde patches. En een nieuwe kernel om de 6 maanden van een vendor vind ik eigenlijk best snel. Ik draai hier een project (intern, niet aan een netwerk aangesloten) dat met een 2.4 kernel werkt. Waarom? Zo is het project een jaar of 3 geleden begonnen en die 2.4 werkt prima.

wv-
18/07/06, 13:17
Jij moet toch ook elke morgend kijken of er geen security updates zijn voor jouw Vendor-kernel. Dat is toch juist het zelfde :).

Zolang de hardware werkt op 2.4, zonder veel geknoei ben ik zeker een voorstander van 2.4. Het spijtige is dat je vaak 2.6 nodig hebt en als je elke security bug fixed wilt zien je bijna elke week een kernel upgrade kan doen.

sander
18/07/06, 13:19
Maar dat betekent toch dat je elke ochtend even moet kijken of er nieuwe security-gerelateerde kernel patches zijn? Vervolgens moet je je eigen kernel patchen en upgraden. Het kan dan nog zijn dat je een probleem hebt, omdat er voor jouw eigen custom kerneltje geen kant-en-klare patch is en je dus zelf moet gaan hobbyen.



Ik had het strikt over security-gerelateerde patches. En een nieuwe kernel om de 6 maanden van een vendor vind ik eigenlijk best snel. Ik draai hier een project (intern, niet aan een netwerk aangesloten) dat met een 2.4 kernel werkt. Waarom? Zo is het project een jaar of 3 geleden begonnen en die 2.4 werkt prima.


patches staan gewoon op www.kernel.org

jou kant en klare kernel kan nog weken wachten op een update,

een eigen gemaakte kernel kan je optimaliseren voor jou systeem , ik gebruik altijd eigen gecompilde kernels.

bvankuik
18/07/06, 13:36
Jij moet toch ook elke morgend kijken of er geen security updates zijn voor jouw Vendor-kernel. Dat is toch juist het zelfde :).

Dan kom je eigenlijk op mijn punt: Bugtraq kun je redelijk filteren, maar ik vind het toch veel tijd kosten om dagelijks +20 mailtjes door te snorren en te bepalen of het van toepassing is. Dat doet een vendor volgens mij beter.


jou (sp) kant en klare kernel kan nog weken wachten op een update

Ik had het over security updates. Als je daar weken op moet wachten, dan moet je een andere distro nemen....


een eigen gemaakte kernel kan je optimaliseren voor jou systeem , ik gebruik altijd eigen gecompilde kernels.

Ik vind vanilla 2.6 kernels van kernel.org de laatste tijd niet bijster robuust. Het voordeel van een stock kernel is dat de vendor een stabiele kernel versie selecteert, issues backport, zorgt dat de initscripts hier goed op aansluiten etc.

wv-
18/07/06, 13:44
Als je dat niet wilt kan je evengoed de mails volgen van jouw vendor. Gebruik je een linux distributie, dan gebruik je allemaal dezelfde linux kernel :)




Ik vind vanilla 2.6 kernels van kernel.org de laatste tijd niet bijster robuust. Het voordeel van een stock kernel is dat de vendor een stabiele kernel versie selecteert, issues backport, zorgt dat de initscripts hier goed op aansluiten etc.

Met 2.6 zit je inderdaad wel met dat probleem. Daarom dat er ook wel meer mensen overstappen naar bijvoorbeeld FreeBSD. Bij linux heb je altijd zo van die wazige kernel vulns waar geen degelijke advisories voor geschreven worden.

Het argument dat je aanhaalt kan je natuurlijk omdraaien: omdat ze zelf een kernel moeten onderhouden waarvan de fixes gebackport zijn, is er juist meer kans op onstabiliteit of op fixes waar je weken op moet wachten.

bvankuik
18/07/06, 14:07
Als je dat niet wilt kan je evengoed de mails volgen van jouw vendor. Gebruik je een linux distributie, dan gebruik je allemaal dezelfde linux kernel :)

Precies mijn punt. Lekker makkelijk; het mailvolume is veel en veel lager. Liever dat dan custom kernel plus elke ochtend minimaal 15 minuten bugtraq.


Het argument dat je aanhaalt kan je natuurlijk omdraaien: omdat ze zelf een kernel moeten onderhouden waarvan de fixes gebackport zijn, is er juist meer kans op onstabiliteit of op fixes waar je weken op moet wachten.

Hangt van de distro af... RedHat sponsort zoveel kernel developers, die vertrouw ik wel. Debian ook, lekker conservatief.

Het lijkt mij niks om een kernel op een productiebak handmatig te moeten patchen. En upgraden naar de laatste vanilla kernel lijkt me ook niks. Natuurlijk kan je het wel, maar je mist dan de testfase die de vendors doen.

crazycoder
18/07/06, 14:09
Je moet:
a. kijken of er een patch is
b. nagaan of de patch voor jou van belang is
c. testen of de patch niets verziekt

Dat moet je met een eigen kernel, dat moet je met de kernel van een vendor.

En dat moet je op ieder platform.. En zeer zeker ook op windows (mocht je dat draaien). Zelfs na een test blijkt de praktijk soms iets weerbarstiger.. zou niet de eerste keer zijn dat van 20 identieke winddozen er 1 plat gaat na een update.

Geef mij maar een custom made kernel.. geen onnodige ballast..

handy
18/07/06, 14:34
custom made kernels zijn erg moeilijk te beheren vooral je heel veel servers hebt. Wij gebruiken gewoon de stock RHEL kernels, weten we zeker dat het goed is. En al die balast dat is ook maar een broodje aap verhaal. Alles is zo'n beetje tegenwoordig in modules te krijgen... next!

MikeN
18/07/06, 15:01
Waarbij modules op zichzelf weer een security risk zijn ;-)

Custom made kernels hoeven niet moeilijk te beheren te zijn wanneer je veel dezelfde hardware hebt, en soms moet je wel.

WH-Tim
18/07/06, 15:12
Hij werkt niet op mijn redhat machine.. ben ik zo goed dan? :rolleyes:

WebXtrA-Rámon
18/07/06, 15:28
De meest resente Redhat/Centos 4.3 Kernel die gereleased is: 2.6.9-34.0.2 (09-07-2006)

Wij draaien zelf 2.6.9-175 en 2.6.9-150

MikeN
18/07/06, 15:31
Hij werkt niet op mijn redhat machine.. ben ik zo goed dan? :rolleyes:
Nee, dat is SELinux ;-)