Viren, Spyware, Datenschutz 11.241 Themen, 94.650 Beiträge

Software-Firewalls_Windows-Linux-Sicherheit

Tilo Nachdenklich / 15 Antworten / Flachansicht Nickles


Es gibt ja immer wieder diese göttlichen flamewars, ob Norton Internet Security Mist ist und ob man nicht lieber ein sicheres Betriebssystem einsetzen sollte. Über Nortons Programmqualität und Preise muss man ja nicht unbedingt begeistert sein, nur nun lese ich sinngemäß:

Firewalls, in der für Windows bekannten Form, gibt es nicht für Linux, insbesondere keine Firewalls, die Anwendungen das Telefonieren untersagen (ct 11/2003, Mai, S.192, Praxis, Hotline). Was es gibt, sind Paketfilter (IP-Adressen, Ports oder TCP-Flags). Welches Programm Pakete auf den Weg bringt, kann man nicht herausfinden!! – Es soll dann noch einen - unsicheren - workaround über sogenannte iptables geben.

Auf off topic stehen gerade ein paar Horrorgeschichten über diverse Internetsitzungen, bestimmt ohne Norton und aktuellen Virenscanner.

Was ist denn, wenn alle Welt nach Linux wechselt und sich die Trojaner auf Linux einschießen?
bei Antwort benachrichtigen
Grossadministrator Tilo Nachdenklich „Software-Firewalls_Windows-Linux-Sicherheit“
Optionen

Nur eine kleine Auswahl. Nix gegen Linux, aber die Armen, die glauben, nur weil sie Linux einsetzen, kann nix passieren:

Eine Schwachstelle im Printing Spooler ermöglicht eine Denial-of-Service-Attacke. Betroffen sind Red Hat 7.3, 8.0 und 9.0. CUPS verwendet das Internet Printing Protocol (IPP), um Druckaufträge zu empfangen, hiervon aber jeweils nur einzigen: parallele Verarbeitung ist nicht möglich. Sendet ein Angreifer nun einen unvollständigen fehlerhaften Druckauftrag, so wird dies nicht erkannt. CUPS bleibt hängen und kann keine Aufträge mehr entgegennehmen.

Voraussetzung für diesen Angriff ist die Erreichbarkeit von Port 631, CUPS lauscht hier auf eingehende Verbindungen. Red Hat empfiehlt, unten stehende Patches zu installieren.

http://www.heise.de/newsticker/data/dab-27.05.03-001/


Erneut Sicherheitslücke in sendmail

Erneut ist eine kritische Sicherheitslücke in sendmail bekannt geworden. Alle Versionen der Open-Source-Variante des Message Transfer Agent (MTA) vor Version 8.12.9 sowie alle kommerziellen sendmail-Ausgaben für Unix und Windows weisen eine Schwachstelle auf, die von Michael Zalewski entdeckt wurde. Durch sie kann ein Angreifer über einen speziellen E-Mail-Header einen Buffer Overflow provozieren; dadurch lässt sich beliebiger Code mit den Rechten des sendmail-Daemons ausführen oder ein Denial-of-Service-Angriff auslösen. Die Ursache für das Leck liegt im Parser für die E-Mail-Adressen. Laut CERT wurde in Tests die Lücke bereits erfolgreich für Denial-of-Service-Angriffe ausgenutzt.

Als Gegenmaßnahme empfiehlt das CERT in einem Advisory ein Upgrade auf sendmail 8.12.9. Für ältere Versionen gibt es zudem Patches. Sendmail Inc. stellt für die kommerziellen Varianten Updates bereit. Außerdem arbeiten die Linux-Distributoren bereits an aktualisierten sendmail-Paketen für ihre Distributionen; dasselbe dürfte bei Apple für sendmail in Mac OS X gelten.

Das CERT betont ausdrücklich, es handele sich bei dem nun entdeckten Fehler -- auch wenn es ein ähnliches Problem ist -- nicht um den gleichen Bug wie bei dem Leck, das Anfang März bekannt wurde; es sind also auf jeden Fall neue Software-Updates oder das Einspielen von Patches bei den betroffenen Servern angesagt. Wie bei dem damaligen Fehler gilt aber, dass auch sendmail-Server innerhalb eines geschlossenen Netzwerks betroffen sein können, die über andere MTAs als sendmail den Kontakt zur Außenwelt herstellen: Denn präparierte Mails werden von nicht betroffenen MTAs unverändert weitergeleitet.

sendmail ist seit langem der meist verwendete MTA im Internet. Angeblich nutzen 50 bis 75 Prozent der Mail-Server im Internet das Programm, um Mails auszutauschen. MTAs dienen dazu, E-Mails zwischen den einzelnen Mail-Servern beziehungsweise von MTA zu MTA weiterzuleiten oder an lokale Adressen auszuliefern. (anw/c't)

http://www.heise.de/newsticker/data/anw-30.03.03-003/



Fast alle Linux-Installationen unsicher

http://www.tecchannel.de/news/20020312/thema20020312-6952.html


12.03.2002 18:51:52

Eine Sicherheitslücke in der Linux-Library "Zlib" betrifft fast alle existierenden Linux-Installationen, meinen amerikanische Sicherheitsexperten. Zlib ist für das Entpacken von Dateien zuständig.


Wie die Computerwoche berichtet, greifen verschiedene Compiler und Entwicklungstools auf die Bibliotheksdatei zu, aber auch der Webbrowser von Mozilla oder "X11", das Basissystem zur Darstellung grafischer Benutzerführungen. Der Fehler verursacht einen Speicherüberlauf, den Angreifer dazu ausnutzen können, um unberechtigten Zugriff auf betroffene Rechner zu erlangen, erklärt Mark Cox, Leiter der Forschungsabteilung von Red Hat. Der Linux-Distributor hat bereits einen Patch bereitgestellt, ebenso wie Suse.


Bislang sei die Lücke noch nicht von Hackern entdeckt worden, so Dave Wreski, Chef der Opensource-Sicherheitsfirma Guardian Digital. Er empfiehlt Linux-Anwendern jedoch, verfügbare Patches möglichst schnell einzuspielen, da mit Angriffen auf die verwundbaren Systeme schon bald zu rechnen sei. (Computerwoche/ala)



Rootkits: Angriff auf Linux
Wenn Cracker sich unbefugt Zugang zu Systemen verschaffen, geht man im allgemeinen davon aus, dass sie auf dem System auch Spuren hinterlassen. Doch mit installiertem Rootkit fehlen genau diese Anzeichen. Im Worst-Case-Szenario missbraucht ein Hacker ein Produktionssystem wochenlang für kriminelle Zwecke. Rootkits zählen mittlerweile zur Standardausstattung eines jeden Crackers: Diese Programme haben den Zweck, dem Eindringling den Zugriff auf das kompromittierte System so lange wie möglich zu erhalten, ohne das es dem Systemadministrator auffällt. Einige Rootkits sind mittlerweile sowohl weit verbreitet als auch leicht zu bedienen, wie zum Beispiel t0rnkit.
Es gibt grundsätzlich 2 unterschiedliche Ansätze für Rootkits, die Systemintegrität zu untergraben: Ältere und harmlosere Rootkits ersetzen beziehungsweise verändern Systembefehle und Sicherheitsprogramme, während die modernen Varianten direkt den Kernel manipulieren, indem sie Systemcalls wie open() oder read() einsetzen.
Ein Beispiel für die erste Variante ist t0rnkit, ein weit verbreitetes Rootkit für Unix und Linux. Es ersetzt unter anderem die Programme du, find, ifconfig, login, netstat, ps, sz und top. Ruft der Systemadministrator diese Befehle auf, zeigen sie die normalen Informationen an – außer denen, die über eine versteckte Konfigurationsdatei (z. B. /dev/.hidden/psconf) ausgeklammert sind. Andere Befehle wie login ersetzt t0rnkit durch Varianten des Befehls, die bei Verbindungen von bestimmten IP-Adressen kein Passwort mehr verlangen, und dem Eindringling Root-Rechte gewähren, aber nichts in Log-Dateien schreiben.
Interessanterweise haben alle Programme bei t0rnkit eine Größe von 31336 Byte. Ein t0rnkit-versuchtes System findet ein fähiger Systemadministrator natürlich schnell; die geänderten Dateigrößen springen beinahe ins Auge.
Das ebenfalls weit verbreitete adore läst sich schon nicht mehr so einfach entdecken. Es tarnt sich als ladbares Kernel-Modul (LKM) und ersetzt dabei Systemaufrufe wie open() und ändert damit das Verhalten von Programmen, ohne diese selbst auszutauschen.
Adore und andere LKM-Rootkits funktionieren natürlich nur dann, wenn der Kernel für dynamische Moduleinbindung kompiliert ist und lässt sich so durch Entfernen der Module auch relativ einfach wieder loswerden.
Aber auch mit einem statischen Kernel ist man gegen Rootkits nicht gefeit: Das Kernel Intrusion System (KIS) von optyx dürfte momentan eines der gefährlichsten und modernsten Programme zur Untergrabung der Systemintegrität sein: Anstatt eigene, manipulierte Kernel-Funktionen bereitzustellen, schreibt es schlicht direkt in den RAM-Speicher des Systems und modifiziert so die Ausgabe von Programmen. Hiergegen kann sich der Administrator mit Boardmitteln von Linux nicht mehr verteidigen, da der Schreibzugriff auf /dev/kmem fester Bestandteil des Kernels ist. Es gibt zwar auch dafür Abhilfen( www.grsecurity.net) , allerdings sollte man die Dokumentation vorher sorgfältig lesen, da es vorkommen kann, das nach dem Patch das System nicht mehr einwandfrei funktioniert.
Wer ist betroffen?
Prinzipiell besteht für alle Betriebssysteme die Gefahr, durch ein Rootkit verseucht zu werden. Die meisten Rootkits gibt es heutzutage de facto für Linux, das allgemein wenig Schutz gegen Manipulationen vom Root-Account bietet. Aber auch für Solaris oder BSD gibt es mittlerweile funktionierende Rootkits. Auch Windows NT/XP bleiben nicht verschont. Allerdings spielen Windows-Rootkits bislang eine eher untergeordnete Rolle.
Maßnahmen
Ein einfache Strategie, um unbefugte Änderungen ausfindig zu machen, ist die Aufzeichnung von kryptografischen Checksummen auf einem Nur-Lese-Datenträger wie CD-ROM. Leider verlassen sich die Prüfprogramme auf die (vom Rootkit manipulierten) Betriebssystemaufrufe. Eine minimalistische Maßnahem wäre es, keine reiber oder featurs des Kernels als Module zu übersetzen und den Modul-Support im Kernle völlig zu deaktivieren. Diese Maßnahme macht das Einfügen JEGLICHER Kernel-Module unmöglich, mit allen anderen damit verbundenen Nachteilen.



SCO fixt Squid in OpenServer -- nach über einem Jahr

Der vom Softwareanbieter SCO im OpenServer 5.0.5 und 5.0.6 mitgelieferte Squid-Proxy kann durch Buffer Overflows in zahlreichen Funktionen zum Absturz gebracht werden. Die fehlerhafte Behandlung von Anfragen ermöglicht es, den Proxy auszutricksen: Betroffen ist insbesondere der FTP-Proxy, der offenbar nicht verifiziert, ob IP-Adressen im Daten- und Kontrollkanal gleich sind. Ein Angreifer könnte damit Firewall-Regeln umgehen. Eine fehlerhafte Implementierung der Authentifizierung gegenüber dem Proxy verrät Angreifern zudem Namen und Passwörter anderer Benutzer. Ein Buffer Overflow im Gopher-Client könnte sogar das Ausführen von Code ermöglichen. SCO empfiehlt die neuesten Packages zu installieren, die allerdings nur als Binaries verfügbar sind. Der Bug im Squid ist seit Juli 2002 bekannt und wurde von anderen Unix-Herstellern und Linux-Distributoren bereits gefixt.

SCO ist in den vergangenen Wochen aufgrund seiner Klage gegen IBM ins Rampenlicht gerückt. SCO besitzt nach eigenen Angaben die Rechte an Unix und streitet sich mit IBM über Verletzungen der Lizenz. Andere Linux-Distributoren wurden ebenfalls indirekt mit der Behauptung angegriffen, in den Linux-Quellen seien Teile des Unix-Codes eingeflossen. SCOs OpenServer ist im Wesentlichen eine Weiterentwicklung von Unixware, das auf Unix System V basiert. (dab/c't)

http://www.heise.de/newsticker/data/dab-28.05.03-002/


Sicherheitsloch im Linux-Multiuser-Betrieb

Der Kern des Betriebssystems Linux enthält einen Fehler, der es lokalen Benutzern erlaubt, auf dem System Root-Rechte zu erlangen. Betroffen sind die Kernel-Versionen 2.2 und 2.4 und damit nahezu alle Linux-Systeme, die seit 1999 installiert wurden, und bei denen der Administrator die Möglichkeit, Kernel-Module nachträglich zu laden, nicht explizit abgeschaltet hat. Es existiert auch bereits ein fertiger Demo-Exploit, der einem Angreifer direkt eine Shell mit Root-Rechten beschert.

Allerdings lässt sich der Fehler nicht ohne direkten Zugang -- also remote von einem beliebigen anderen System aus -- ausnutzen; der Angreifer muss also bereits einen Zugang auf dem attackierten Computer haben. Wo Linux also im Multiuser-Betrieb genutzt wird, sollten Administratoren schleunigst ein Kernel-Update einspielen. Auf Servern, auf denen regulär nur Adminstratoren Zugang haben, ist die Lücke nicht ganz so ernst; man sollte jedoch auch dort den Patch einspielen und sich gegen den Fall absichern, dass ein anderes Sicherheitsloch Angreifern einen Zugang mit eingeschränkten Rechten ermöglicht, der dann über den Kernel-Bug sofort zur Root-Shell ausgebaut werden könnte.

Auf dem zentralen Kernel-Archiv steht ein Patch für die Version 2.2 bereit; Red Hat bietet bereits Kernel-Updates für 2.4er-Kernel (Red Hat 7.x, 8.0).

Der Bug beruht darauf, dass der Kernel das Nachladen von Modulen nicht ausreichend gegen externe Modifikationen absichert. So kann man über die Debug-Funktion ptrace() die Kontrolle über einen Prozess erlangen, der ein Modul nachladen soll und dort beliebigen eigenen Code einschleusen. Dieser wird dann mit Root-Rechten ausgeführt.

Heise Online 2003-03-21


Sicherheitslücke im PDF/PS-Handling von KDE

Die KDE-Entwickler haben ein Advisory veröffentlicht, das eine Sicherheitslücke im PDF- und Postscript-Handling des Unix/Linux-Desktops beschreibt. Für den Umgang mit PDF- beziehungsweise Postscript-Dateien setzt KDE auf Ghostscript-Software. Durch Ausnutzen eines Lecks können Angreifer Befehle, die in den PDF-Dateien enthalten sein können, mit den Rechten und unter dem Account des lokalen Anwenders ausführen lassen. Dazu muss ein Angreifer dem Nutzer ein PDF- oder Postscript-File unterschieben, das die entsprechenden Befehle enthält. Öffnet der Anwender diese Datei (auch in der automatischen Datei-Vorschau), ist es nach Angaben der KDE-Entwickler für den Angreifer möglich, zum einen private Daten des Nutzers auszulesen und Shell-Kommandos mit den Rechten des lokalen Anwenders auszuführen.
Das KDE-Team hat Updates für die Desktop-Software herausgegeben, die das Problem korrigieren. Die Entwickler empfehlen dringend, auf die Versionen 3.1.1a beziehungsweise 3.0.5b zu aktualisieren. Für die Version 2.2.2 hat das KDE-Team Patches herausgegeben; auf dem ftp-Server finden sich auch Patch-Files für Version 3.05 und 3.1.1. Für Binär-Dateien der neuen KDE-Versionen verweisen die Entwickler auf die einzelnen Linux-Distributoren; für Debian, SuSE und TurboLinux liegen entsprechende Pakete bereits auf den Mirror-Servern des KDE-Projekts bereit. (jk/c't)

http://www.heise.de/newsticker/data/jk-11.04.03-001/


Sicherheitslücke in Linux-DHCP-Routinen


DHCP, die dynamische Verwaltung von IP-Nummern in Netzwerken, ist unter anderem in den Linux-Distributionen von BSD, SuSE, Red Hat und Debian unsicher.

20.01.2003 - Das Internet Software Consortium (ISC) hat bei einem Test seiner Software mehrere Sicherheitslücken im DHCP-Daemon entdeckt. Weil dieser in verschiedenen Linux-Distributionen verwendet wird, sind all diese Linux-Varianten angreifbar.

Durch Ausnutzung der Lücken ist es Angreifern möglich, jeden beliebigen Code unter der Benutzerkennung auszuführen, unter welcher dhcpd läuft – dies ist in der Regel „root“, der alles darf..

Systeme mit ISC DHCPD ab Version 3.0 bis Version 3.0.1RC10 sind davon betroffen. Die Fehlerbehandlungsroutine der minires-Bibliothek, die vom Unix-Tool NSUPDATE genutzt wird, um dynamische Aktualisierungen des DNS-Systems durchzuführen, ist der eigentliche Knackpunkt.

Die Installation eines Patches, der bei der Sicherheitsorganisation CERT verfügbar ist, schafft ebenso Abhilfe wie ein Update auf ISC DHCPD 3.0pl2 oder 3.0.1RC11. (mk)

http://www.vnunet.de/pc-pro/news_facts/detail.asp?ArticleID=6621

2003-01-20




bei Antwort benachrichtigen