Bashbleed unter Lenny patchen

Dreamer90

Cadet 4th Year
Registriert
Okt. 2013
Beiträge
87
Hallo,

ich wollte den Bashbleed bug unter Debian Lenny mit
Code:
apt-get install --only-upgrade bash
patchen jedoch kommt:
Code:
E: Sense only is not understood, try true or false.
.

Wie kann ich Bash patchen?

~Dreamer90
 
Indem du bash kompilierst. Aber wieso solltest du das tun? Lenny ist seit über 2 Jahren EOL und bekommt keinerlei Updates mehr. Da ist der bash Bug nur einer unter sehr sehr vielen Sicherheitslücken.

Installiere wheezy
 
Geht leider nicht, das sind Produktivsysteme. Gibt es keine einfachere Möglichkeit?
 
Probier es mal mit "apt-get install bash", also ohne "--only-upgrade". Wenn das Paket bereits installiert ist führt der Befehl nämlich statt der Installation ein Update durch.
 
Auch Produktivsysteme muss man aktualisieren. Debian war da wohl schlichtweg die falsche Wahl. Kein LTS -> falsche Distribution für Produktivsysteme. CentOS wäre die richtige Wahl gewesen.
 
Jippie, ein Besserwisser im Thread. :rolleyes:

Arbeitest du schon oder studierst du noch?
Wir haben u.a. SunOS 2.5.1 und noch aelteres im Produktivbetrieb. Hast du jetzt einen Herzinfarkt?
Es gibt nunmal durchaus Einsatzberechtigungen fuer alte Systeme.
z.b. wenn die daran haengende Hardware 1 Millionen Euro kostet und du 30 solcher Systeme ersetzen musst, damit du nur noch Betriebssysteme verwendest, die noch aktiv supported werden. :rolleyes:
Da bekommst vom Chef hoechstens ein bisl Kohle, um die Systeme vom Rest abzutrennen, aber niemals 30 Mille. :freak:
 
Zuletzt bearbeitet von einem Moderator:
Ulukay schrieb:
Arbeitest du schon oder studierst du noch?
Ich arbeite, und mich wurmt es sogar schon, dass eine unserer Kisten ein Debian 7 ist und ich dort wohl nächstes Jahr ein Update fahren muss, wenn Deb7 nicht gerade doch noch LTS bekommt.

z.b. wenn die daran haengende Hardware 1 Millionen Euro kostet und du 30 solcher Systeme ersetzen musst, damit du nur noch Betriebssysteme verwendest, die noch aktiv supported werden. :rolleyes:
Anständiges Rollout planen und zeitnah migrieren.
Ob du 3 oder 30 quasi identische Maschinen migrierst, das macht keinen so großen Unterschied. Du schnappst dir eine zum Testen, suchst an ihr einen stabilen Weg und ballerst diesen dann auf den restlichen 29 zackig durch.

Außerdem: Wer 1Mio Euro in Hardware pumpt, der kann auch noch ein paar Kröten für einen Service-Vertrag mit einem der großen Distributoren machen. RHEL (und somit auch CentOS) haben 10 Jahre Support, und RHEL werden für das nötige Kleingeld auch noch länger an deinen Maschinen herumpatchen.

Was passiert, wenn du uralte und verwundbare Maschinen ans Netz hängst, das hat man z.B. bei Stuxnet gesehen.
Shellshock wird eventuell kräftige Auswirkungen auf verwundbare Industriesysteme haben, bei denen irgendwelche technologiefremden Buchhalter hinsichtlich der Updates permanent geknausert haben.
 
Ich garantiere dir, dass saemtliche Halbleiterhersteller solch alte Betriebssysteme noch produktiv einsetzen. ;)
Es wurde 1 Million pro Rechner in Hardware gepumpt, das ist richtig. Vor 15-25 Jahren. Und wenn 30 von 100 Maschinen nun ausserhalb der Wartung sind, intressierts trotzdem niemanden (vom Manager aufwaerts). Die muessen laufen.
 
Wie so oft gilt: Wo steht die Maschine? Was für ein Konzept steht rund herum?
Das Problem sind solche alten Krücken, die dann auch noch öffentlichen Netzen exponiert sind.... und das ist eben gar nicht so selten und ein gefundenes Fressen für jeden Hacker. Wenn die Maschinen hingegen komplett isoliert sind, ist es vollkommen egal, was da läuft.

Aber nochmal: Die Risiken solchen alten Mist einzusetzen sind exorbitant. Eine von außen erreichbare Rostlaube mit uralten und gut dokumentierten Verwundbarkeiten (inkl. Shellshock) lässt Stuxnet komplett verblassen. Während bei Stuxnet eine ganze Batterie teurer 0-Days gefeuert wurde, wäre für einen Shellshock-Angriff nur ein kleines auf Git zugängliches Script nötig.
 
Bei Kisten, die nur bis Slowlaris bis 2.5.1 können, kostet heute ein Jahr Betriebsstrom mehr als eine Ersatzbeschaffung höherer Leistungsfähigkeit. Die Hardwareersatzkosten sind eher selten der tatsächliche Grund für so einen Weiterbbetrieb. Problem ist in der Regel die antike Software. Solche Software mutiert mit der Zeit zu einer Art "Firmware". Niemand supportet den Kram. Niemand darf den Kram anzufassen. Selbst hinschauen ist unerwünscht. Aktuellere Hardware dafür gibts nicht. Die Software ist üblicherweise das Problem, nicht die Hardware.

Im Verlagsgewerbe rennt auch noch uralter Sparc-Müll. ... Nein, nicht am Internet. Bei den Chipherstellern sicher genausowenig.
 
Zuletzt bearbeitet:
mensch183 schrieb:
Bei Kisten, die nur bis Slowlaris bis 2.5.1 können, kostet heute ein Jahr Betriebsstrom mehr als eine Ersatzbeschaffung höherer Leistungsfähigkeit.

Zu blöd, wenn da noch Maschinen dranhängen, die auf die Systeme abgestimmt sind.

Ähnlich hatte dereinst ein Frischling in einer unserer NEAs den Steuerrechner ersetzt und prompt liefen im nächsten Inselbetrieb die Diesel aus dem Takt und machten einen vollständigen Lastabwurf.

Leistungsersparnis des neuen Systemes pro Jahr: ~600kWh.
Geschätzte Kosten für die Umrüstung der Diesel und des Totalausfalles sowie Folgeschäden und Personalkosten: über £50Mrd.
Kannst gerne mal rechnen, wann sich der neue Rechner amortisiert hätte.

Das verrückte daran: Wir hatten selber Pläne, die gesamte Anlage in Teilstücken über einen Zeitraum von vier Jahren umzurüsten, und eben diese Thematik war auch in den Plänen erfasst und entsprechende Maßnahmen bereits geplant gewesen, bevor engineering einen selbstläufer machen wollte und sich gehörig in die Nesseln setzte.

Nicht immer macht eine Aufrüstung Sinn. Und wenn, muß man mehr betrachten, als nur den Rechner.
 
Andererseits kannst du aber auch nicht als gegeben annehmen, dass die alten Krücken noch ewig weiter laufen. Irgendwann gibt jeder Halbleiter den Geist auf. Was machst du dann? Uraltes Solaris auf moderne Hardware? Ähnlich uralte Hardware vom Schrotthändler besorgen?

Genau deshalb sollte man auch STETIG migrieren und aktualisieren.
 
Das ist aber nicht grenzenlos möglich. Irgendwann MUSS man migrieren. Je kürzer man die Zyklen hält, desto weniger Probleme hat man mit Ersatzteilen...
Oder kannst du heute noch Ersatzteile für einen ENIAC besorgen? Gut, wahrscheinlich sogar leichter als für einen 286er...
 
Herrlich, ich liebe solche akademischen Labertaschen (oder gesponsert?), die völlig abweichend von der Frage einen Umstieg auf eine andere Distro o.ä. empfehlen..
Es gibt viele & gute Gründe, warum man nunmal ein Lenny am laufen hat - und man kann das auch lösen! Selbst wenn die meisten nicht betroffen sein dürften..

Also, hier gibts ne vernünftige Anleitung "the Debian way" ohne mit selberkompilierten gefrickel auf der Produktiv-Maschine das System zu schrotten:
http://www.philkang.com/?p=24

(Das nimmt man jedoch nicht,ist auch nicht komplett "dummy-sicher", ausser man vertraut mir blind - sondern den source, liegt auch da..)

Kein Grund, bei einer grossen installierten Basis alles andere über Bord zu werfen.
Im Kern muss sich der CTO/CIO + sein Team eh in solch krassen Fällen um alles selber kümmern (können), da hilft kein Support-Vertrag, kein LTS, kein garnix! Und schon garkein Susie, Redhat oder Apple, wo ich teils ewig auf den Hersteller warten muss..

Makki

P.S.: bei Interesse gibts morgen fertige, gepatchte . deb Packerl; teste noch..
Ergänzung ()

Wers für Debian Lenny (5.0) braucht - die o.g. Anleitung ist nur 90% richtig - und mir vertraut (was man nicht sollte :evillol: )
Direkte Links gehen nicht, daher :
repo.wiregate.de /wiregate/pool/main/b/
mit Source inkl. Patches 052&053 zum selberbauen (bash* runterladen, dpkg-source -x ..)

Makki
 
Zurück
Oben