jug
Ehemalige
Anmeldungsdatum: 19. März 2007
Beiträge: 12335
Wohnort: Berlin
|
ChemicalBrother schrieb: Nur für das genannte Beispiel. Es gibt weiterhin eine kritische Sicherheitslücke in Bash, die nicht behoben ist.
Du hast ja recht, das war ungenau ausgedrückt.
Wie man die ausnutzt, wissen bisher aber (offiziell) nur der Finder der Sicherheitslücke und der Hauptentwickler von Bash.
Natürlich sind in Bash noch Fehler … ich erwarte auch noch weitere Fehler, die aktuell noch komplett unbekannt sind. Wie bei jeder komplexen Software … Aber, wenn man alle Updates eingespielt hat, dann ist man auf dem aktuell sichersten Stand auf dem man sein kann. ~jug
|
trollsportverein
Anmeldungsdatum: 21. Oktober 2010
Beiträge: 3415
|
Wollt ihr mal ein reales Angriffsskript sehen? Wenn ihr schnell genug seid, könntet euch vielleicht noch eins zum studieren holen, damit ihr geeignete Abwehrmaßnahmen ergreifen könnt. Fundstück im heise.de Forum:
h t t p : / / www.heise.de/security/news/foren/S-Willkommen-im-Botnet/forum-286100/msg-25868278/read/
Für gewöhnliche Desktop Nutzer gilt natürlich wie immer: das System aktuell halten. Server Betreiber könnten jedoch aus dem Script möglicherweise für die Abwehr lernen. Die Bash kann übrigens auch so compilert werden, dass sie die Umgebungsvariablen nicht importiert:
CFLAGS+= -DIMPORT_FUNCTIONS_DEF=0
Dann sollten derartige Shellshock Angriffsversuche durch übergeben von Umgebungsvariablen ins leere laufen.
|
Saplaran
Anmeldungsdatum: 22. Februar 2008
Beiträge: 50
Wohnort: Niederbayern
|
Developer92 schrieb: 1&1 hielt es sogar gänzlich für unnötig, überhaupt einen Patch einzuspielen. Zum Glück habe ich diesen Monat den Umzug auf einen anderen Hoster vollzogen, muss nur noch warten bis der Vertrag endlich gekündigt wird 😇
Lol, die haben ja wohl den Popo geöffnet. Natürlich sollte man sich mit Linux auskennen wenn man einen Server betreibt aber es werden trotzdem nicht wenige den Repositories des Providers vertrauen. TheDarkRose schrieb: Was heißt da Patch einspielen. Die betreiben halt einfach nen apt-mirror der wohl nicht oft gesynct wird. Tja ^^ Bei Hetzner war der gleich da
Ja, aber wie arm ist das? Für einen Hoster sollte es doch nun wirklich kein Problem sein, mehrmals täglich das Repository zu aktualisieren. Außer die wollen Botnetze züchten. 😛
|
TheDarkRose
Anmeldungsdatum: 28. Juli 2010
Beiträge: 3459
|
Also das Vertrauen finde ich nicht das Problem, da diese Mirrors ja die Pakete nicht signieren. Aber man sollte oder eher MUSS zu den Provider Mirrors immer noch das Distributor eigene security Repo in der sources.list haben, eben solche Probleme zu vermeiden.
|
trollsportverein
Anmeldungsdatum: 21. Oktober 2010
Beiträge: 3415
|
Hoppla, da fehlte noch was, um das importieren abzuschalten gibt es diesen Patch: http://seclists.org/oss-sec/2014/q3/755
|
Saplaran
Anmeldungsdatum: 22. Februar 2008
Beiträge: 50
Wohnort: Niederbayern
|
trollsportverein schrieb: Hoppla, da fehlte noch was, um das importieren abzuschalten gibt es diesen Patch: http://seclists.org/oss-sec/2014/q3/755
Quelle Heise ( http://www.heise.de/security/meldung/ShellShock-Teil-3-Noch-drei-Sicherheitsprobleme-bei-der-Bash-2404788.html ): "Bei zwei davon handelt es sich um Off-by-One-Fehler im Parser-Code, wie der bei Google arbeitende Sicherheitsexperte Michal Zalewski in einem Blog-Eintrag erklärt. Der auch als "lcamtuf" bekannte Google-Mitarbeiter empfiehlt Distributoren, einen Patch von Red-Hat-Mitarbeiter Florian Weimer einzuspielen, der diese als CVE-2014-7186 und CVE-2014-7187 geführten Probleme beseitigt. Bei Red Hat Enterprise Linux (RHEL) steckt diese Änderung schon in den am Freitag veröffentlichten Bash-Updates. Auch Fedora behebt dieses beiden Fehler, obwohl die Freigabe-Mail es nicht ausweist. Ubuntu beseitigt diese beiden Lücken durch ein am Samstag erschienenes Update – bei einigen Canonical-Distributionen ist es bereits das vierte Bash-Sicherheitsupdate innerhalb von einer Woche." Dein "da" betraf soweit ich sehe das ursprüngliche Problem, zu dem anderen Problem ist der Patch für ubuntu schon am Samstag erschienen.
|
trollsportverein
Anmeldungsdatum: 21. Oktober 2010
Beiträge: 3415
|
Nee, nee, die NetBSDler und auch die FreeBSDler schalten die Importfunktion der BASH einfach jetzt erst mal per default ab. Und das bleibt auch vorerst erst mal so, auch mit der Bash Version 4.3.27. Während der Bash Entwickler Chet Ramey dazu meint, dass diese Bash Funktion, welche NetBSD und FreeBSD aus Sicherheitsgründen abschalten, von zu vielen genutzt würde, um sie per default abzuschalten: http://seclists.org/oss-sec/2014/q3/790 Nur ist es bei den BSDlern nicht allzu unüblich, dass die Nutzer sich mal eben selbst es so compilern, wie sie es haben wollen, es lässt sich nämlich - falls gewünscht - diese Bash Funktion vor dem Bau der Bash wieder einschalten. FreeBSD stand ja auch Pate für das Konzept und die Anpassbarkeit von Gentoo. Bei den Binary Distributionen ist dann etwas schwieriger. Das könnte Ärger geben, wenn die Bash Funktion zugunsten der Sicherheit rigoros beim Bau der Pakete abgeschaltet würde. Spannend könnte es auch überall dort noch werden, wo die Nutzer es noch gar nicht realisiert haben, beispielsweise auf den unzähligen NAS Gerätschaften, die mittlerweile an die Massen verkauft wurden. Da ist ja in der Regel ein Webserver drauf. Bleibt dann die spannende Frage, was ist da die Shell? Gibt es Verletzlichkeiten dadurch? In den Medien wird das sicherlich gerne in weiteren Iterationen noch lustig breitgetrampelt werden. Soll ja durchaus einige geben, die ihre NAS Gerätschaften vom Internet aus zugreifbar gemacht haben.
|
Polix
Anmeldungsdatum: 14. Oktober 2009
Beiträge: 727
|
Nabend, eine Frage: heute kam per Arch upgrade zu mir bash-4.3.027-1. Sind also momentan die meisten Lücken in bash geschlossen?
|
Saplaran
Anmeldungsdatum: 22. Februar 2008
Beiträge: 50
Wohnort: Niederbayern
|
Polix schrieb: Nabend, eine Frage: heute kam per Arch upgrade zu mir bash-4.3.027-1. Sind also momentan die meisten Lücken in bash geschlossen?
Keine Ahnung, probier es doch am besten selber mit dem Testscript aus: https://github.com/hannob/bashcheck
|
trollsportverein
Anmeldungsdatum: 21. Oktober 2010
Beiträge: 3415
|
Haha, passiert so wie ich es mir schon gedacht habe: http://www.computerbase.de/2014-10/qnap-qfix-1.0.1-behebt-shellshock-luecke/ 😬 Gibt bestimmt noch weitere Artikel in den Medien, wenn dieser oder jener Hersteller nun auch noch die Bash aktualisiert. Überhaupt die Router, ja denkt den keiner an die Plastikrouter? Ich sehe Füllmaterial, jede Menge Füllmaterial für die Medien, danke Bash. 😈
|
ChemicalBrother
Ehemaliger
Anmeldungsdatum: 17. Mai 2007
Beiträge: 3136
|
trollsportverein schrieb: Überhaupt die Router, ja denkt den keiner an die Plastikrouter? Ich sehe Füllmaterial, jede Menge Füllmaterial für die Medien, danke Bash. 😈
Sicher? Dachte die nutzen BusyBox, wegen der geringen Systemressourcen.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13933
|
ChemicalBrother schrieb: Dachte die nutzen BusyBox, wegen der geringen Systemressourcen.
Die FritzBox z. B., bentzt busybox. Wer die bash auf der FB haben wollte/will, der kann z. B. freetzen: http://svn.freetz.org/trunk/make/bash/
|
trollsportverein
Anmeldungsdatum: 21. Oktober 2010
Beiträge: 3415
|
Es gibt einen Bash Schnelltest auf: https://shellshocker.net/ Die zur Zeit aktuelle Bash auf Ubuntu Trusty Tahr, bash 4.3-7ubuntu1.4, scheint leider noch nicht kugelsicher zu sein.
curl https://shellshocker.net/shellshock_test.sh | bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2533 100 2533 0 0 4842 0 --:--:-- --:--:-- --:--:-- 4843
CVE-2014-6271 (original shellshock): not vulnerable
bash: Zeile 16: 4568 Speicherzugriffsfehler (Speicherabzug geschrieben) bash -c "f() { x() { _;}; x() { _;} <<a; }" 2> /dev/null
CVE-2014-6277 (segfault): VULNERABLE
CVE-2014-6278 (Florian's patch): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-7186 (redir_stack bug): not vulnerable
CVE-2014-7187 (nested loops off by one): not vulnerable
CVE-2014-//// (exploit 3 on http://shellshocker.net/): not vulnerable
CVE-2014-6277: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6277
`which bash` --version
GNU bash, Version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
Lizenz GPLv3+: GNU GPL Version 3 oder jünger <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
dpkg -l bash
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name Version Architektur Beschreibung
+++-=============================================================-===================================-===================================-================================================================================================================================
ii bash 4.3-7ubuntu1.4 amd64 GNU Bourne Again SHell
|
V_for_Vortex
Anmeldungsdatum: 1. Februar 2007
Beiträge: 12085
Wohnort: Berlin
|
Danke für die Info und das Script. 👍
|
Saplaran
Anmeldungsdatum: 22. Februar 2008
Beiträge: 50
Wohnort: Niederbayern
|
Danke auch von mir. Es gibt hoffentlich einen zeitnahen Fix. GNU Bash through 4.3 bash43-026 does not properly parse function definitions in the values of environment variables,
which allows remote attackers to execute arbitrary code or cause a denial of service (uninitialized memory access,
and untrusted-pointer read and write operations) via a crafted environment, as demonstrated by vectors involving the
ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed
by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary
from Bash execution. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271 and CVE-2014-7169. Quelle: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6277
|