Die voreingestellten Sicherheitsoptionen des Solaris-Administrations-Daemons sadmind ermöglichen Angreifern lokal oder über eine Netzwerkverbindung die unautorisierte Ausführung administrativer Kommandos mit root-Privilegien. Neue Angriffsprogramme zur Ausnutzung dieser Schwachstelle kursieren.

Betroffene Systeme

• Sparc-Plattform
  • Solaris 7 und Trusted Solaris 7
  • Solaris 8 und Trusted Solaris 8
  • Solaris 9
• x86-Plattform
  • Solaris 7 und Trusted Solaris 7
  • Solaris 8 und Trusted Solaris 8
  • Solaris 9

Gefahrenpotential
sehr hoch
(Hinweise zur Einstufung des Gefahrenpotentials.)

• Laut Sun ist dieses Problem bekannt und dokumentiert, Patches daher nicht geplant.

Anmerkung
Dieses Problem ist in der Tat schon seit Jahren bekannt und in vielen Dokumenten, die die Absicherung von Solaris-Inatallationen beschreiben, erwähnt. Dort wird empfohlen, sadmind nicht im Default-Security-Level zu starten, sondern im sichereren Level 2 (s. Kontext).
In der man page zu sadmind (1M) wird ebenfalls darauf hingewiesen, daß der voreingestellte Security-Level 1 nur in "relativ sicheren Umgebungen" eingesetzt werden sollte, da es "leicht ist, AUTH_SYS-Credentials zu fälschen". Sun Microsystems hat aber bisher nicht die Konsequenz aus dieser Tatsache gezogen und die Voreinstellung geändert, so daß ein Adminsitrator die Entscheidung, sadmind so zu betreiben, daß Angriffe leicht möglich sind, bewußt treffen muß. Dies ist nicht mehr zeitgemäß und gefährdet in unnötiger Weise Solaris-Installationen, insbesondere solche, die von überlasteten Administratoren verwaltet werden (also praktisch alle), die davon ausgehen, daß Defaults so eingestellt sind, daß Angriffe zumindest nicht trivial möglich sind. Zwar erleichtert die gewählte Voreinstellung vermutlich in vielen Fällen die Einführung zentralisierter Administration mittels der Sun Solstice Admin Suite (tm) fordert jedoch eine nicht unerhebliche Gefährdung der Sicherheit als Preis.

Workaround

• Sofern das System mittels der Sun Solstice Admin Suite (tm) administriert werden soll, ist die Änderung des Security-Levels vorzunehmen, andernfalls sollte sadmind abgeschaltet werden.
  1. Folgende Änderungen sind in der Datei /etc/inetd.conf vorzunehmen:
     • zur Änderung des Security-Levels ist die Zeile

       
                100232/10   tli   rpc/udp wait root /usr/sbin/sadmind  sadmind
       
       

       zu ersetzen durch die Zeile

       
                100232/10   tli   rpc/udp wait root /usr/sbin/sadmind   sadmind -S 2
       
       

     • zur Abschaltung des sadmind ist die Zeile

       
                100232/10   tli   rpc/udp wait root /usr/sbin/sadmind  sadmind
       
       

       mittels eines Doppelkreuzes ("#") auszukommentieren:

       
                #100232/10   tli  rpc/udp wait root /usr/sbin/sadmind     sadmind
       
       

  2. Danach ist in jedem Fall inetd zu veranlassen, seine Konfigurationsdatei neu zu lesen:

                $ su
                Password:
     
                # /usr/bin/pkill -HUP inetd
     
                # exit
     
                $
     
     

• Eine Filterung des Ports 111/tcp (portmapper) verhindert Angriffe nicht effektiv, da sadmind auch direkt angegriffen werden kann (s. Einfallstor). Zusätzlich zu den o. b. Maßnahmen kann eine Filterung jedoch nicht schaden.

Vulnerability ID

• Sun Alert ID 56740

Exploit Code

• Angriffsprogramme kursieren

Weitere Information zu diesem Thema

• sadmind (1M) manual page

Hinweis
Die in diesem Text enthaltene Information wurde für die Mitglieder der Universität Stuttgart recherchiert und zusammengestellt. Die Universität Stuttgart übernimmt keinerlei Haftung für die Inhalte. Dieser Artikel darf ausschließlich in unveränderter Form und nur zusammen mit diesem Hinweis sowie dem folgenden Copyrightverweis veröffentlicht werden. Eine Veröffentlichung unter diesen Bedingungen an anderer Stelle ist ausdrücklich gestattet.

Copyright © 2022 RUS-CERT, Universität Stuttgart, https://cert.uni-stuttgart.de/