View Full Version : gibt es eigentlich AS400 VIREN oder WÜRMER ?
hallo
letztens hatte ich starke diskussion über Viren etc.
eigentlich habe ich nie von einem AS400 VIRUS oder WURM gehört.
gibt es auch solche ?
gruss
cc
Hallo,
Viren eher kaum, wobei man sich vor dem Fehlschluss hüte, dass das an der Architektur läge, da fehlt es eher am Interesse der Hacker. Würmer schon, da würde ich mal mit CFINT den Herrn Google befragen...
mfg
Dieter Bender
hallo
letztens hatte ich starke diskussion über Viren etc.
eigentlich habe ich nie von einem AS400 VIRUS oder WURM gehört.
gibt es auch solche ?
gruss
cc
Wobei CFINT ein IBM-Wurm, und zwar ein äusserst lästiger ist !
Solange man die Sicherheitsmöglichkeiten der AS verwendet, kann man einen Virus nicht unterbringen.
Schädliche Programme kann man allemal unterbringen, aber ein "infizieren" von Programmen ist rein technisch nicht möglich.
Insbesonders die Systemlib's sind geschützt, was das austauschen von Programmen angeht. Ich habe es sogar mal geschafft (V2R2), ein internes Systemobjekt permanent zu ändern, so dass kein einziges Kommando mehr ausgeführt werden konnte. Der interne Code musste neu installiert werden.
Set V3 gibts allerdings auch einen Schutz dagegen.
Anders siehts dann schon aus, wenn man so Produkte wie Java, Linux o.ä. einsetzt. Sobald das Interesse der Hacker geweckt ist, wird es auch Java-Viren und Würmer geben.
Hallo,
ich wäre mit solchen Einschätzungen vorsichtig, die AS400 kocht erkennbar auch nur mit Wasser. Der Integritätsschutz der Programme hat ein ähnliches Niveau wie der ByteCode Verifier von Java und reicht an signierte Klassen bei weitem nicht heran (da sei alleine schon die Interpretation von IBM der Exportbeschränkungen von Krypto-Software vor).
Das was viele für eine Positiv Argument halten, ist in Wirklichkeit längst zum Scheunentor geworden. Sprüche wie "Hacker verzweifeln", "Die AS400, das sicherste System der Welt", "Viren auf AS400 unmöglich" haben zu einer Sorglosigkeit ohnegleichen im AS400 Umfeld geführt, die zum Resultat hat, dass man bei vielen (ich lasse das mal so vage) Systemen nicht einmal einen Trojaner braucht, damit einem der Hobel aus der Hand fressen würde. Da reicht einem ein blankes Ausnutzen der längst sattsam bekannten Lücken. Übertroffen wird das vielleicht nur noch von einer Schar Ahnungsloser Windows Anwender, die ihre Privatrechner dem Internet zum Fraß vorwerfen; im professionellen Umfeld sind die Windows Nutzer längst um Längen vorsichtiger als der durchschnittliche AS400 Shop.
mfg
Dieter Bender
Wobei CFINT ein IBM-Wurm, und zwar ein äusserst lästiger ist !
Solange man die Sicherheitsmöglichkeiten der AS verwendet, kann man einen Virus nicht unterbringen.
Schädliche Programme kann man allemal unterbringen, aber ein "infizieren" von Programmen ist rein technisch nicht möglich.
Insbesonders die Systemlib's sind geschützt, was das austauschen von Programmen angeht. Ich habe es sogar mal geschafft (V2R2), ein internes Systemobjekt permanent zu ändern, so dass kein einziges Kommando mehr ausgeführt werden konnte. Der interne Code musste neu installiert werden.
Set V3 gibts allerdings auch einen Schutz dagegen.
Anders siehts dann schon aus, wenn man so Produkte wie Java, Linux o.ä. einsetzt. Sobald das Interesse der Hacker geweckt ist, wird es auch Java-Viren und Würmer geben.
Wer kann schon MI-Code programmieren ?
Wo gibt es die Beschreibung der nicht dokumentierten MI-Befehle ?
Seit V2R1 gab es kein neues MI-Programmierhandbuch !
Und die wenigen MI-Befehle, die als C-Funktionen zur Verfügung stehen, reichen bei weitem nicht aus.
Ich würde ja auch zu gerne wissen, wie ich einen MI-ILE-Compiler entwickeln kann. Die heutige offengelegte Schnittstelle für QPRCRTPG liefert nur OPM-Programme.
Mit den verfügbaren HLL-Sprachen habe ich im AS/400-Umfeld definitiv keine Chance, Programmcode zu infizieren. Wie oben gesagt, ein Austausch von Programmen ist natürlich möglich.
Hallo,
das sehe ich ein wenig weniger optimistisch; undokumentiertheit ist bei Sicherheitsfunktionen keine Beruhigung, sondern ein negativ Faktor, was ein Vergleich von Linux versus Windows aufzeigen mag.
Was die Ausage mit den Möglichkeiten von HLL Sprachen angeht, da sehe ich durchaus Ansatzpunkte, aber ein winziger Schnipsel an MI Code, so eine Art Hacker API würde ohnehin ausreichen, um selbst mit CL oder REXX Viren zu programmieren.
mfg
Dieter Bender
Wer kann schon MI-Code programmieren ?
Wo gibt es die Beschreibung der nicht dokumentierten MI-Befehle ?
Seit V2R1 gab es kein neues MI-Programmierhandbuch !
Und die wenigen MI-Befehle, die als C-Funktionen zur Verfügung stehen, reichen bei weitem nicht aus.
Ich würde ja auch zu gerne wissen, wie ich einen MI-ILE-Compiler entwickeln kann. Die heutige offengelegte Schnittstelle für QPRCRTPG liefert nur OPM-Programme.
Mit den verfügbaren HLL-Sprachen habe ich im AS/400-Umfeld definitiv keine Chance, Programmcode zu infizieren. Wie oben gesagt, ein Austausch von Programmen ist natürlich möglich.
Sven Schneider
14-10-04, 21:36
Ausserdem gibt es mit der Pase-Umgebung (AIX-runtime) die Möglichkeit mit einem AIX-C Compiler direkt nativ RISC Power-Code zu erzeugen.
Mittlerweile kann ich den/die AIX-Compiler sogar auf der AS/400 direkt aufrufen.
Das eigentliche Betriebssystem der AS/400 ist ja der LIC-Code und dieser ist weitestgehend unter C bzw. C++ auf einer IBM eigenen Entwicklungsumgebung unter AIX entstanden.
Bei den HLL-Programmiersprachen unter OS/400 bin ich auf den internen im LIC abgelegten Code-Translator angewiesen, der ja nach dem HLL-Compiler aufgerufen wird. Und der erzeugt nur qualifizierten RISC-Code, welcher auf der MI Schnittstelle aufsetzt. Damit kann ich also direkt keine "schädlichen" Power-RISC-Instructions erzeugen.
Aber auch bei MI Programmierung komme ich nicht so ohne weiteres an geschützte Speicherbereiche für Daten und Programmcode heran.
Weil das OS/400 Domänkonzept dies verhindert :
The QPRCRTPG API creates a program object that resides in
the *USER domain and runs in the *USER state.
Um dem Program doch zu ermöglichen auf geschützte Instruktionen/Datenberiche zuzugreifen muss ich es so patchen, dass es im system state läuft. Das geht nur mit dem DST/SST. Hier kann ich die Objekte direkt auf der Platte patchen, wie mit einem Hex-Editor.
Im laufendem Betrieb kommt man damit also nicht ran.
Auch ein Restore eines solcherart gepatchten Programms geht nicht.
(Ein MI-Guru ist hier Leif Svalgaard, hat an FAST400 massgeblich Anteil; eine Software welche den CFINT-Governour austrickst)
Siehe auch : http://www.leif.org/
Sven
Sven
Auf der AS, egal mit welchem Compiler oder in welcher Umgebung, wird NIEMALS Native-Prozessor-Code generiert.
Da das Grundprinzip ja das MI (Maschinen-Interface) ist, würde jede Übertragung auf eine andere Hardware zu einem Recompile (was Quellen voraussetzt) führen müssen. Dies ist seit jeher das Problem von z.B. UNIX/LINUX. Ich habe nur eine sog. Source-Kompatibilität (und auch nicht immer).
Ich habe also keine Chance, die CPU direkt anzusprechen.
Auch das Patchen von Objekten hilft da nur eingeschränkt.
MI ist nahezu vergleichbar mit dem generierten Java-Code. Auch dieser ist (fast) auf jeder JVM ausführbar unabhängig von der Hardware-Plattform.
Nicht umsonst setzt die IBM ja nach AS-Model auch unterschiedliche CPU's ein. Auch auf einer i5 kann ich noch Programme für V5R1 erstellen.
Zur Laufzeit ist auch der sog. ausführbare Code gegen Zugriffe gesperrt.
Hallo,
so langsam gleitet die Diskussion ab ins unpräzise. Bisher scheint es ja unisono für möglich zu erachten, dass es Würmer auf einer AS400 geben kann (und Trojaner sowieso).
Also zu den Viren: was sind überhaupt Viren? Rein technisch sind das erstmal Programme, die andere Programme infizieren und ihre eigene Funktionalität in das nun infizierte Programm einfügen. Das unangenehme an diesen Teilen ist also, dass ich mit fortlaufender Durchseuchung immer größere Probleme habe den Schmutz wieder loszuwerden.
Für die meisten Betriebssysteme sind Programme auf der Ebene der Plattenverwaltung nix anderes als Streamfiles, in die ich beliebiges einkopieren kann (mit dem Risiko, dass das Programm sofort kaputt ist, ein Virenprogrammierer muss also mehr können als kopieren!). Hier hat nun die AS400 zunächst den Vorteil, dass auf der Ebene der Plattenverwaltung (genauer in user domain Objekten) eben doch was anderes als Streamfiles sind. Diese Klippe ist für den Ungeübten sicher hoch genug, aber eben keinerlei Sicherheit dafür, dass sie nicht bereits jetzt von etlichen übersprungen werden könnte und sicherlich wenige Monate, wenn nicht eher Wochen ausreichen sich die Kenntnisse zu erarbeiten.
Eine kleine PowerPC Assembler Routine (eine Art Dreizeiler) reicht aus, diese Hürde zu knacken, Hardwareabhängigkeit von sowas ist kein Argument, das gilt für alle anderen Plattformen erstrecht, man fragt als erstes einfach: "welchen Prozessor hast Du eigentlich?" Die Assembler Routine ist freilich auch Bestandteil des Virensegmentes, kann also nicht separat gefunden und entfernt werden. Dies ist nur einer von mehreren Möglichkeiten...
mfg
Dieter Bender
Auf der AS, egal mit welchem Compiler oder in welcher Umgebung, wird NIEMALS Native-Prozessor-Code generiert.
Da das Grundprinzip ja das MI (Maschinen-Interface) ist, würde jede Übertragung auf eine andere Hardware zu einem Recompile (was Quellen voraussetzt) führen müssen. Dies ist seit jeher das Problem von z.B. UNIX/LINUX. Ich habe nur eine sog. Source-Kompatibilität (und auch nicht immer).
Ich habe also keine Chance, die CPU direkt anzusprechen.
Auch das Patchen von Objekten hilft da nur eingeschränkt.
MI ist nahezu vergleichbar mit dem generierten Java-Code. Auch dieser ist (fast) auf jeder JVM ausführbar unabhängig von der Hardware-Plattform.
Nicht umsonst setzt die IBM ja nach AS-Model auch unterschiedliche CPU's ein. Auch auf einer i5 kann ich noch Programme für V5R1 erstellen.
Zur Laufzeit ist auch der sog. ausführbare Code gegen Zugriffe gesperrt.
Ich glaube nicht, dass du in ein PGM-Objekt (kann man ja per /qsys.lib ggf. bearbeiten) nativen Prozessor-Code einfügen und dann auch ausführen kannst.
Basis der AS für ALLE ausführbaren Objekte ist und bleibt die MI-Ebene.
Dass man PGM-Objekte auch als Datei behandeln kann zeigt ja bereits der SAV-Befehl. Wie sonst kann man denn alle Objekte sichern als als Stream.