Nieuwe beveiligingsupdate voor Bash-bug beschikbaar
Er is een nieuwe update voor de ernstige Bash-bug verschenen, nadat de eerste update het lek niet volledig bleek te verhelpen. Via de kwetsbaarheid in Bash is het mogelijk om willekeurige code op systemen uit te voeren en die in het ergste geval over te nemen.
Bash is een Unix-shell waarmee er opdrachten aan het systeem kunnen worden gegeven. Het wordt voor allerlei toepassingen gebruikt en veel programma's draaien het in de achtergrond. Na ontdekking van het lek werd er een update uitgerold. Die bleek het probleem niet geheel op te lossen. De nieuwe update zou nu uitkomst moeten bieden.
Impact
Het Nationaal Cyber Security Center van de overheid heeft inmiddels het beveiligingsadvies over het lek opgewaardeerd naar "hoog" voor zowel de kans op misbruik als de schade die kan worden veroorzaakt. Dit naar aanleiding van de publicatie van verschillende exploits, waaronder één gericht op de dhclient networkconfiguratiescripts die als root-user worden uitgevoerd om de door de dhcp-server opgegeven netwerkinstellingen toe te passen.
Een kwaadwillende die een kwaadaardige DHCP-server op een netwerk aanbiedt kan hierdoor commando's injecteren en middels de Bash-kwetsbaarheid laten uitvoeren op het systeem. Tevens wordt er actief door botnets gezocht naar kwetsbare systemen op het internet, onder andere om nieuwe systemen te infecteren met malware waarmee DDoS-aanvallen zijn uit te voeren.
Reacties (25)
Het genoemde NCSC advies [1] suggereert dat de nieuwe update voor kwetsbaarheid CVE-2014-7169 [2] voor o.a. OS X, BSD, Ubuntu, CentOS, Debian, SUSE en RedHat is uitgebracht.
Nb. deze patch volgt de patch voor CVE-2014-6271 [3] van afgelopen woensdag op.
O.a. hoe je kunt testen of een systeem nog/niet meer kwetsbaar is voor CVE-2014-7169 lees je in [4].
Hoewel [4] aanvankelijk meldde (voor Red Het systemen) dat een reboot wel noodzakelijk zou zijn om de patch te activeren, staat daar er nu dat dit niet nodig is (d.w.z. na het patchen van bash, als je ook andere software patcht kan het toch nodig zijn).
Hoewel ik ze niet ken is denkbaar dat er systemen bestaan die, na opstarten, een ramdisk aanmaken, bash daarnaartoe kopiëren en httpd bewegen om dat exemplaar te gebruiken. Met het patchen van /bin/bash ben je er dan natuurlijk niet. Ook andere performance optimalisaties zijn denkbaar waardoor een oudere versie van bash gebruikt zou kunnen blijven worden. Vanuit securityoogpunt is daarom mijn advies om bij twijfel altijd te rebooten.
Ook kan ik niet uitsluiten dat er packages bestaan die een eigen exemplaar van bash (in een separate directory) installeren, bij twijfel kun je het hele filesysteem scannen op andere exemplaren van bash (eventuele exemplaren in ramdisk vind je dan waarschijnlijk ook). Aanvulling: als je httpd in een chroot omgeving draait zal die mogelijk een lokale kopie van bash gebruiken; check dat ook die gepatcht wordt! Er zijn veel tutorials te vinden die aanraden om een kopie van bash te maken (Google: "cp /bin/bash" chroot ).
[1]: https://www.ncsc.nl/dienstverlening/response-op-dreigingen-en-incidenten/beveiligingsadviezen/NCSC-2014-0595+1.01+Ernstige+kwetsbaarheid+in+Bash+verholpen.html
[2]: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169
[3]: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
[4]: https://access.redhat.com/articles/1200223
Update 2014-09-26 15:38: aanvulling over chroot toegevoegd.
Nb. deze patch volgt de patch voor CVE-2014-6271 [3] van afgelopen woensdag op.
O.a. hoe je kunt testen of een systeem nog/niet meer kwetsbaar is voor CVE-2014-7169 lees je in [4].
Hoewel [4] aanvankelijk meldde (voor Red Het systemen) dat een reboot wel noodzakelijk zou zijn om de patch te activeren, staat daar er nu dat dit niet nodig is (d.w.z. na het patchen van bash, als je ook andere software patcht kan het toch nodig zijn).
Hoewel ik ze niet ken is denkbaar dat er systemen bestaan die, na opstarten, een ramdisk aanmaken, bash daarnaartoe kopiëren en httpd bewegen om dat exemplaar te gebruiken. Met het patchen van /bin/bash ben je er dan natuurlijk niet. Ook andere performance optimalisaties zijn denkbaar waardoor een oudere versie van bash gebruikt zou kunnen blijven worden. Vanuit securityoogpunt is daarom mijn advies om bij twijfel altijd te rebooten.
Ook kan ik niet uitsluiten dat er packages bestaan die een eigen exemplaar van bash (in een separate directory) installeren, bij twijfel kun je het hele filesysteem scannen op andere exemplaren van bash (eventuele exemplaren in ramdisk vind je dan waarschijnlijk ook). Aanvulling: als je httpd in een chroot omgeving draait zal die mogelijk een lokale kopie van bash gebruiken; check dat ook die gepatcht wordt! Er zijn veel tutorials te vinden die aanraden om een kopie van bash te maken (Google: "cp /bin/bash" chroot ).
[1]: https://www.ncsc.nl/dienstverlening/response-op-dreigingen-en-incidenten/beveiligingsadviezen/NCSC-2014-0595+1.01+Ernstige+kwetsbaarheid+in+Bash+verholpen.html
[2]: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169
[3]: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
[4]: https://access.redhat.com/articles/1200223
Update 2014-09-26 15:38: aanvulling over chroot toegevoegd.
26-09-2014, 14:02 door
[Account Verwijderd]
-
Bijgewerkt: 26-09-2014, 14:34
[Verwijderd]
Voor Mac OS X door Apple zelf is er nog geen normale 'consumenten'-update beschikbaar. #1
Apple heeft er inmiddels wel wat over gezegd.
http://www.macrumors.com/2014/09/26/apple-os-x-users-safe-bash-flaw-update-soon/
http://www.imore.com/apple-working-quickly-protect-os-x-against-shellshock-exploit
Even afwachten dus.
Denk dat men daar nog even heel druk ook met andere patches bezig is die ook 'best wel' prioriteit hebben.
#1 Wordt met de beschikbare update deze bedoeld hier?
https://ftp.gnu.org/pub/gnu/bash/?C=M;O=A
Apple heeft er inmiddels wel wat over gezegd.
http://www.macrumors.com/2014/09/26/apple-os-x-users-safe-bash-flaw-update-soon/
http://www.imore.com/apple-working-quickly-protect-os-x-against-shellshock-exploit
Even afwachten dus.
Denk dat men daar nog even heel druk ook met andere patches bezig is die ook 'best wel' prioriteit hebben.
#1 Wordt met de beschikbare update deze bedoeld hier?
https://ftp.gnu.org/pub/gnu/bash/?C=M;O=A
26-09-2014, 15:28 door
Erik van Straten
Door Picasa3: Update: Op twitter wordt gemeld dat de patch voor Bash inderdaad het lek in Linux heeft gedicht. Je kunt dit controleren door de Terminal te starten en vervolgens: env x='() { :;}; echo vulnerable' bash -c 'echo hello' en RETURN in te geven. Als het goed is moet de volgende tekst (ook Engels is mogelijk) afgebeeld worden:
Als je dus deze tekst krijgt, is het lek gedicht.
Dat is de test voor het lek dat door de patch van woensdag (CVE-2014-6271) werd gedicht.bash: waarschuwing: x: ignoring function definition attempt
bash: fout tijdens importeren van functiedefinitie voor 'x'
hello
bash: fout tijdens importeren van functiedefinitie voor 'x'
hello
Als je dus deze tekst krijgt, is het lek gedicht.
Uit https://access.redhat.com/articles/1200223:
To test if your version of Bash is vulnerable to CVE-2014-7169, run the following command:
$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
Op een kwetsbaar systeem zal een bestand /tmp/echo worden aangemaakt, en de output zal zijn (let op de datum/tijd op het einde):
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014
Op een niet kwetsbaar wordt geen bestand aangemaakt, en de output zal lijken op de volgende:
date
cat: /tmp/echo: No such file or directory
cat: /tmp/echo: No such file or directory
Of dit voor andere dan Red Hat systemen hetzelfde resultaat oplevert weet ik niet, als je daar meer over weet post dat dan hieronder!
26-09-2014, 15:36 door
WhizzMan
Het artikel suggereert dat alle systemen die via DHCP een IPadres opvragen kwetsbaar zijn. Dit is alleen het geval voor systemen die in hun DHCP aanvraag gebruik maken van een bash-script. Windowsmachines zijn bijvoorbeeld niet kwetsbaar.
@Erik van Straten
De Red Hat test geeft dat mijn Debian Wheezy systeem met de nieuwste GNU bash, versie 4.2.37(1) niet kwetsbaar is.
De nieuwste Tails versie 1.1.2 is volgens de Red Hat test nog steeds kwetsbaar.
De Red Hat test geeft dat mijn Debian Wheezy systeem met de nieuwste GNU bash, versie 4.2.37(1) niet kwetsbaar is.
De nieuwste Tails versie 1.1.2 is volgens de Red Hat test nog steeds kwetsbaar.
26-09-2014, 22:49 door
[Account Verwijderd]
[Verwijderd]
Door Erik van Straten:
Uit https://access.redhat.com/articles/1200223:
Op een kwetsbaar systeem zal een bestand /tmp/echo worden aangemaakt, en de output zal zijn (let op de datum/tijd op het einde):
Op een niet kwetsbaar wordt geen bestand aangemaakt, en de output zal lijken op de volgende:
Of dit voor andere dan Red Hat systemen hetzelfde resultaat oplevert weet ik niet, als je daar meer over weet post dat dan hieronder!
Door Picasa3: Update: Op twitter wordt gemeld dat de patch voor Bash inderdaad het lek in Linux heeft gedicht. Je kunt dit controleren door de Terminal te starten en vervolgens: env x='() { :;}; echo vulnerable' bash -c 'echo hello' en RETURN in te geven. Als het goed is moet de volgende tekst (ook Engels is mogelijk) afgebeeld worden:
Als je dus deze tekst krijgt, is het lek gedicht.
Dat is de test voor het lek dat door de patch van woensdag (CVE-2014-6271) werd gedicht.bash: waarschuwing: x: ignoring function definition attempt
bash: fout tijdens importeren van functiedefinitie voor 'x'
hello
bash: fout tijdens importeren van functiedefinitie voor 'x'
hello
Als je dus deze tekst krijgt, is het lek gedicht.
Uit https://access.redhat.com/articles/1200223:
To test if your version of Bash is vulnerable to CVE-2014-7169, run the following command:
$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
Op een kwetsbaar systeem zal een bestand /tmp/echo worden aangemaakt, en de output zal zijn (let op de datum/tijd op het einde):
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014
Op een niet kwetsbaar wordt geen bestand aangemaakt, en de output zal lijken op de volgende:
date
cat: /tmp/echo: No such file or directory
cat: /tmp/echo: No such file or directory
Of dit voor andere dan Red Hat systemen hetzelfde resultaat oplevert weet ik niet, als je daar meer over weet post dat dan hieronder!
ik heb dit uitgetest op arch linux, en kreeg exact de zelfde resultaat.
ik heb dus eergister een update voor bash gekregen en gisteren weer een.
Dank voor de reacties!
In https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/ wordt beschreven hoe je een DHCP server zo configureert dat je kwetsbare clients kunt vinden (voor CVE-2014-6271, de 1e kwetsbaarheid dus). In https://news.ycombinator.com/item?id=8372040 vind je een discussie hierover. Aanvulling 02:35, uit https://isc.sans.edu/diary/Update+on+CVE-2014-6271+Vulnerability+in+bash+shellshock/18707:
https://www.gentoo.org/security/en/glsa/glsa-201409-09.xml beschrijft de patch van woensdag, CVE-2014-6271
https://www.gentoo.org/security/en/glsa/glsa-201409-10.xml beschrijft de patch van vrijdag, CVE-2014-7169
In https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/ wordt beschreven hoe je een DHCP server zo configureert dat je kwetsbare clients kunt vinden (voor CVE-2014-6271, de 1e kwetsbaarheid dus). In https://news.ycombinator.com/item?id=8372040 vind je een discussie hierover. Aanvulling 02:35, uit https://isc.sans.edu/diary/Update+on+CVE-2014-6271+Vulnerability+in+bash+shellshock/18707:
Last Updated: 2014-09-26 19:05:04 UTC by Johannes Ullrich: NOTE!: option-114 is used by VoIP (provisioning URL) so thread carefully on telecomms networks!
Door Krakatau: Onder Gentoo is de kwetsbaarheid afwezig na de eerste patch. Problemen met een patch die het probleem slechts gedeeltelijk oploste zijn waarschijnlijk beperkt tot systemen die RedHat linux draaien.
Heb je alleen de eerste patch gedraaid, of beide?https://www.gentoo.org/security/en/glsa/glsa-201409-09.xml beschrijft de patch van woensdag, CVE-2014-6271
https://www.gentoo.org/security/en/glsa/glsa-201409-10.xml beschrijft de patch van vrijdag, CVE-2014-7169
Gentoo says:
$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
date
cat: /tmp/echo: No such file or directory
$
Het lijkt erop dat Gentoo anders op de test reageert dan Red Hat/Debian/Ubuntu systemen: in https://forums.gentoo.org/viewtopic-p-7622768.html wordt hetzelfde gemeld als jij schrijft. Is jouw output van na de 1e, of van na de 2e Gentoo patch?$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
date
cat: /tmp/echo: No such file or directory
$
27-09-2014, 04:58 door
mrunix
gewoon ksh over bash heen kopieren. dan is het klaar.
de suse patch was trouwens meteen goed, de voorbeelden (wget / cmd line) werkten niet meer.
de suse patch was trouwens meteen goed, de voorbeelden (wget / cmd line) werkten niet meer.
Door mrunix: gewoon ksh over bash heen kopieren. dan is het klaar.
ksh != bash , bij Redhat gaan de meeste van je init scripts kapot en is je doos onbruikbaar hierdoor.
[root@bash bin]# cp ksh93 bash
cp: overwrite `bash'? y
cp: cannot create regular file `bash': Text file busy
[root@bash bin]# exec ksh
# cp ksh93 bash
# reboot
Broadcast message from root@bash
(/dev/lxc/console) at 8:25 ...
The system is going down for reboot NOW!
/bin/sh: /bin/sh: cannot execute [Exec format error]
/etc/rc6.d/K60crond[37]: [: argument expected
/etc/rc6.d/K60crond[54]: [: argument expected
Stopping crond: /etc/rc6.d/K60crond[380]: local: not found [No such file or directory]
/etc/rc6.d/K60crond[149]: local: not found [No such file or directory]
/etc/rc6.d/K60crond[150]: local: not found [No such file or directory]
.... etc
Goeie tip man.
27-09-2014, 09:47 door
[Account Verwijderd]
-
Bijgewerkt: 27-09-2014, 09:51
[Verwijderd]
Door mrunix: gewoon ksh over bash heen kopieren. dan is het klaar.
de suse patch was trouwens meteen goed, de voorbeelden (wget / cmd line) werkten niet meer.
de suse patch was trouwens meteen goed, de voorbeelden (wget / cmd line) werkten niet meer.
Nee SuSE heeft de fix ook re-released. Je was kennelijk laat met patchen en hebt de eerste gemist.
27-09-2014, 12:35 door
[Account Verwijderd]
-
Bijgewerkt: 27-09-2014, 14:00
[Verwijderd]
Ook leuk (via http://glandium.org/blog/?p=3304):
env echo='() { xterm;}' bash -c "echo this is a test"
Waarschuwing: niet klakkeloos kopiëren-plakken, het vernacheld je systeem.
28-09-2014, 01:12 door
mrunix
Tja
RedHat is de windows van linux :-)
RedHat 5 is gebaseerd op n oud lijk van 5 jaar oud inmiddels.... (kernel 2.6.32)
zal niet lekker werken.
Wel knap om iets te maken dat wel op bash werkt maar niet op ksh......
Door mrunix:[/i] gewoon ksh over bash heen kopieren. dan is het klaar.
[/quote]
ksh != bash , bij Redhat gaan de meeste van je init scripts kapot en is je doos onbruikbaar hierdoor.
[root@bash bin]# cp ksh93 bash
cp: overwrite `bash'? y
cp: cannot create regular file `bash': Text file busy
[root@bash bin]# exec ksh
# cp ksh93 bash
# reboot
Broadcast message from root@bash
(/dev/lxc/console) at 8:25 ...
The system is going down for reboot NOW!
/bin/sh: /bin/sh: cannot execute [Exec format error]
/etc/rc6.d/K60crond[37]: [: argument expected
/etc/rc6.d/K60crond[54]: [: argument expected
Stopping crond: /etc/rc6.d/K60crond[380]: local: not found [No such file or directory]
/etc/rc6.d/K60crond[149]: local: not found [No such file or directory]
/etc/rc6.d/K60crond[150]: local: not found [No such file or directory]
.... etc
Goeie tip man.[/quote]
RedHat is de windows van linux :-)
RedHat 5 is gebaseerd op n oud lijk van 5 jaar oud inmiddels.... (kernel 2.6.32)
zal niet lekker werken.
Wel knap om iets te maken dat wel op bash werkt maar niet op ksh......
Door mrunix:[/i] gewoon ksh over bash heen kopieren. dan is het klaar.
[/quote]
ksh != bash , bij Redhat gaan de meeste van je init scripts kapot en is je doos onbruikbaar hierdoor.
[root@bash bin]# cp ksh93 bash
cp: overwrite `bash'? y
cp: cannot create regular file `bash': Text file busy
[root@bash bin]# exec ksh
# cp ksh93 bash
# reboot
Broadcast message from root@bash
(/dev/lxc/console) at 8:25 ...
The system is going down for reboot NOW!
/bin/sh: /bin/sh: cannot execute [Exec format error]
/etc/rc6.d/K60crond[37]: [: argument expected
/etc/rc6.d/K60crond[54]: [: argument expected
Stopping crond: /etc/rc6.d/K60crond[380]: local: not found [No such file or directory]
/etc/rc6.d/K60crond[149]: local: not found [No such file or directory]
/etc/rc6.d/K60crond[150]: local: not found [No such file or directory]
.... etc
Goeie tip man.[/quote]
Door mrunix: Tja
RedHat is de windows van linux :-)
RedHat 5 is gebaseerd op n oud lijk van 5 jaar oud inmiddels.... (kernel 2.6.32)
zal niet lekker werken.
Wel knap om iets te maken dat wel op bash werkt maar niet op ksh......
RedHat is de windows van linux :-)
RedHat 5 is gebaseerd op n oud lijk van 5 jaar oud inmiddels.... (kernel 2.6.32)
zal niet lekker werken.
Wel knap om iets te maken dat wel op bash werkt maar niet op ksh......
Uit je nek kletsen is ook een gave. De kernel heeft met deze bug niks van doen, ik heb niet over RHEL 5 gesproken, jouw tip is uit je duim gezogen en niet getest wat precies je kennis aangeeft.
Door mrunix: Tja
RedHat is de windows van linux :-)
RedHat 5 is gebaseerd op n oud lijk van 5 jaar oud inmiddels.... (kernel 2.6.32)
zal niet lekker werken.
Wel knap om iets te maken dat wel op bash werkt maar niet op ksh......
RedHat is de windows van linux :-)
RedHat 5 is gebaseerd op n oud lijk van 5 jaar oud inmiddels.... (kernel 2.6.32)
zal niet lekker werken.
Wel knap om iets te maken dat wel op bash werkt maar niet op ksh......
Zojuist even een opensuse 13.1 onder handen genomen, die kan er ook niet tegen dat je ksh over bash heen gooit.
Hij reboot nog wel maar verder gaat hij toch goed kapot.
Als je 'tips' geeft geef dan in elk geval tips die werken/getest zijn en als er een reactie komt doe dan niet zo uit de hoogte alsof "jouw" distro er wel mee om kan gaan zonder dat getest te hebben ... Mr U ...
Iemand een idee welke default system shell Cisco gebruikt voor hun routertjes en firewalls voor consumenten en mkb ? Die draaien allemaal Linux en halen bijna altijd hun IP via DHCP op. Zelfde gaat op voor de Fritzboxen van AVM. Als beide fabrikanten hier bash scripts gebruiken is er een zeer, zeer ernstig probleem verschenen op het bord van internet providers.
28-09-2014, 16:06 door
mrunix
je hebt gelijk.
kopieren werkt niet......
sorry.
In suse kan ik wel de login shell van root naar ksh zetten, dat werkt gewoon. (kan ook op redhat )
de /bin/sh kan ook naar ksh linken, ipv bash. ( op redhat kan dat niet, blijkt).
daarom had ik iets te snel geconcludeerd dat je ksh net zo goed over sh heen kan copieren.
dat is dus niet zo.
dat suse nog kan booten komt omdat ze de hash bang consequent toepassen; dwz dat scripts zelf hun shell kiezen. (bash, meestal) redhat doet dat niet (altijd), dus gaat t stuk.
mrunix.
( t blijft n oud lijk, dat redhat.....)
----------------------------------------------
Zojuist even een opensuse 13.1 onder handen genomen, die kan er ook niet tegen dat je ksh over bash heen gooit.
Hij reboot nog wel maar verder gaat hij toch goed kapot.
Als je 'tips' geeft geef dan in elk geval tips die werken/getest zijn en als er een reactie komt doe dan niet zo uit de hoogte alsof "jouw" distro er wel mee om kan gaan zonder dat getest te hebben ... Mr U ...
kopieren werkt niet......
sorry.
In suse kan ik wel de login shell van root naar ksh zetten, dat werkt gewoon. (kan ook op redhat )
de /bin/sh kan ook naar ksh linken, ipv bash. ( op redhat kan dat niet, blijkt).
daarom had ik iets te snel geconcludeerd dat je ksh net zo goed over sh heen kan copieren.
dat is dus niet zo.
dat suse nog kan booten komt omdat ze de hash bang consequent toepassen; dwz dat scripts zelf hun shell kiezen. (bash, meestal) redhat doet dat niet (altijd), dus gaat t stuk.
mrunix.
( t blijft n oud lijk, dat redhat.....)
----------------------------------------------
Zojuist even een opensuse 13.1 onder handen genomen, die kan er ook niet tegen dat je ksh over bash heen gooit.
Hij reboot nog wel maar verder gaat hij toch goed kapot.
Als je 'tips' geeft geef dan in elk geval tips die werken/getest zijn en als er een reactie komt doe dan niet zo uit de hoogte alsof "jouw" distro er wel mee om kan gaan zonder dat getest te hebben ... Mr U ...
v.w.b. fritz remote access uitzetten helpt altijd.
in mijn fritz (7340) gebruiken ze Lua.
vlgs deze site is fritzbox niet kwetsbaar. maar bij avm.de is niets te vinden..........
http://www.chip.de/news/Bash-Bug-Entwarnung-FritzBox-ist-nicht-betroffen_72959548.html
in mijn fritz (7340) gebruiken ze Lua.
vlgs deze site is fritzbox niet kwetsbaar. maar bij avm.de is niets te vinden..........
http://www.chip.de/news/Bash-Bug-Entwarnung-FritzBox-ist-nicht-betroffen_72959548.html
Door Anoniem: Iemand een idee welke default system shell Cisco gebruikt voor hun routertjes en firewalls voor consumenten en mkb ? Die draaien allemaal Linux en halen bijna altijd hun IP via DHCP op. Zelfde gaat op voor de Fritzboxen van AVM. Als beide fabrikanten hier bash scripts gebruiken is er een zeer, zeer ernstig probleem verschenen op het bord van internet providers.
Door mrunix: je hebt gelijk.
kopieren werkt niet......
sorry.
kopieren werkt niet......
sorry.
Accepted.
( t blijft n oud lijk, dat redhat.....)
[root@c7 ~]# uname -a
Linux c7 3.10.0-123.8.1.el7.x86_64 #1 SMP Mon Sep 22 19:06:58 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[root@c7 ~]# cat /etc/redhat-release
CentOS Linux release 7.0.1406 (Core)
Sure.
29-09-2014, 00:15 door
mrunix
RHEL 7 is 3 maanden oud.
en over 5 jaar zit je nog steeds op 3.10.0-xxx
RHEL 5 is relevanter voor de meeste gebruikers.
en over 5 jaar zit je nog steeds op 3.10.0-xxx
RHEL 5 is relevanter voor de meeste gebruikers.
Door mrunix: RHEL 7 is 3 maanden oud.
en over 5 jaar zit je nog steeds op 3.10.0-xxx
RHEL 5 is relevanter voor de meeste gebruikers.
en over 5 jaar zit je nog steeds op 3.10.0-xxx
RHEL 5 is relevanter voor de meeste gebruikers.
Op een of andere manier wil je je blunder met ksh over bash heen compenseren merk ik.
Ik zal er maar niet meer op ingaan.
30-09-2014, 12:25 door
[Account Verwijderd]
[Verwijderd]
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
