FLASH - Sicherheitslücke in IBM i DB2 - schnell mal PTF laden

[Fuerchau]

Interessant finde ich ja folgenden Hinweis:

Important note: IBM recommends that all users running unsupported versions of affected products upgrade to supported and fixed version of affected products.

Wie erstelle ich nun eine fixed version, wenn nicht beschrieben ist was ich tun oder vermeiden sollte?

[Pikachu]

Es geht wohl um einen unqualifizierten Aufruf eines CL-Programms von IBM durch IBM i mit erhöhter Berechtigung. Dieses Programm wird normalerweise in QSYS gefunden. Wenn man aber ein eigenes Programm mit diesem Namen in eine Bibliothek vor QSYS stellt (z.B. in eine Sprachbibliothek) wird durch IBM i dieses eigene Programm gefunden und aufgerufen und leider auch mit erhöhter Berechtigung.

[BenderD]

Interessant finde ich ja folgenden Hinweis:

Important note: IBM recommends that all users running unsupported versions of affected products upgrade to supported and fixed version of affected products.

Wie erstelle ich nun eine fixed version, wenn nicht beschrieben ist was ich tun oder vermeiden sollte?

... du erstellst keine "fixed version", die sollst Du von IBM kaufen. Sprich: V7R2 aufwärts und die PTFs installieren. Ob dieser alert eine Marketing Aktion von IBM ist, mag ich nicht beurteilen.
Für Programme mit adopted Authority gilt ganz unabhängig davon, dass solche Programme keine calls über libl machen dürfen. Dieses offene Scheunentor findet man auf fast allen Installationen, insbesondere in Shops, die auf den sogenannten Menüschutz bauen.

D*B

[Fuerchau]

State of the art war halt schon immer, dass per LIBL schnell Test- und/oder Mandanten- oder Versionssystem aufgebaut werden konnten.
Was anderes ist ja auch nicht die "PATH"-Variable in Linux/Windows oder CLASSPATH für Java.
Warum soll das nun für SQL auf einmal schlecht sein?
Wenn es danach ginge dürfte man aus Sicherheitsgründen schon keine PATH-Variable haben sondern jede Anwendung zwingen, Calls außerhalb des eigenen Anwendungspfades explizit qualiizieren zu müssen.
Danach funktioniert dann erst mal überhaupt nichts.

Die Eingangsfrage: "was muss ich anderes machen um nach Einsatz des PTFs nicht auf der Nase zu liegen" ist immer noch nicht beantwortet. Auch mit IBM-ID findet man keine nennenswerten Hinweise.

Muss ich jetzt Prozeduren oder Funktionen immer explizit mit Lib aufrufen?
Quasi "select MyLib/MyFunction(f1) from MyLib/MyTable"?
Der Nachteil ist ja, dass Libnamen wie Tabellennamen nicht parametrierbar und nur per dynamic SQL änderbar sind.

[Pikachu]

Wahrscheinlich hat IBM bisher an ein paar Stellen einfach CALL QPGM gemacht und macht durch diese PTFs jetzt CALL QSYS/QPGM damit immer das richtige interne IBM-Programm aufgerufen wird.

[BenderD]

State of the art war halt schon immer, dass per LIBL schnell Test- und/oder Mandanten- oder Versionssystem aufgebaut werden konnten.
Was anderes ist ja auch nicht die "PATH"-Variable in Linux/Windows oder CLASSPATH für Java.
Warum soll das nun für SQL auf einmal schlecht sein?
Wenn es danach ginge dürfte man aus Sicherheitsgründen schon keine PATH-Variable haben sondern jede Anwendung zwingen, Calls außerhalb des eigenen Anwendungspfades explizit qualiizieren zu müssen.
Danach funktioniert dann erst mal überhaupt nichts.

Die Eingangsfrage: "was muss ich anderes machen um nach Einsatz des PTFs nicht auf der Nase zu liegen" ist immer noch nicht beantwortet. Auch mit IBM-ID findet man keine nennenswerten Hinweise.

Muss ich jetzt Prozeduren oder Funktionen immer explizit mit Lib aufrufen?
Quasi "select MyLib/MyFunction(f1) from MyLib/MyTable"?
Der Nachteil ist ja, dass Libnamen wie Tabellennamen nicht parametrierbar und nur per dynamic SQL änderbar sind.

... das Problem ist nicht der Aufgerufene, sondern der Aufrufer! Wenn ein Programm, das unter Privilegien läuft, ein anderes Benutzerprogramm nach libl aufruft, kann letzteres umgelenkt werden und ein Programm eingeklinkt werden, das z.B. Privilegien dauerhaft propagiert. Sprich: Aufruf nach libl ist nicht das Problem, sondern Programme, die Berechtigungen tragen und vererben, müssen kontrollieren, was sie da aufrufen.

D*B

[holgerscherer]

Interessant finde ich ja folgenden Hinweis:

Important note: [I]IBM recommends that all users running unsupported versions of affected products upgrade to supported and fixed version of affected products.

das bedeutet, wenn Du noch V7R1 fährst, dann upgraden! Die IBM will ja auch leben. :-)

[holgerscherer]

Es geht wohl um einen unqualifizierten Aufruf eines CL-Programms von IBM durch IBM i mit erhöhter Berechtigung. Dieses Programm wird normalerweise in QSYS gefunden. Wenn man aber ein eigenes Programm mit diesem Namen in eine Bibliothek vor QSYS stellt (z.B. in eine Sprachbibliothek) wird durch IBM i dieses eigene Programm gefunden und aufgerufen und leider auch mit erhöhter Berechtigung.

nein, Ihr Nasen. Es geht um einen SQL-Service, der ein CL aufruft ohne eine Betriebsystem-Bibliothek zu qualifizieren. Der Aufruf läuft aber schon als *OWNER daher ist eine beliebige Bibliotheksliste nützlich, der CVE-Score ist hoch und Details muss man selbst rausfinden ;-)

[Fuerchau]

Nun, beliebte Methoden sind ja auch, eine eigene SYS-Lib an den Anfang zu stellen um genau diesen Effekt zu erreichen. Also ein eigenes Programm aufrufen, dass bestimmte Aktionen vor-/nachher durchführen soll und das ersetzte Programm dann selber qualifiziert aufruft.
Dies wird dann nun wohl nicht mehr gehen, wenn IBM seine eigenen Programme nur noch qualifiziert aufruft.
Mal sehen, wer dann so auf die Nase fällt und sich wundern tut;-).

Und ich sach noch:
Früher war alles viel einfacher und weniger Energie wurde auch verbraucht.

[Pikachu]

IBM-Programme aus QSYS rufen intern IBM-Programme aus QSYS auf meistens über den SEPT oder qualifiziert mit Bibliothek QSYS aber bei diesem Fehler wohl ein IBM-Programm über die Bibliotheksliste. Hier soll aber niemand einen Effekt erreichen können da eine erhöhte Berechtigung im Spiel ist.

[Fuerchau]

Nun, wer das Paket Infor-XPPS (Brain, Rembold+Holzer) kennt, der sollte auch hier die größte Sicherheitslücke kennen:
Mittels Programm XXUSER kann man den aktuellen Job auf jeden x-beliebigen User switchen, natürlich auch QSECOFR.
Einfach "call xxuser qsecofr". Mit "call xxuser ' '" kommt man wieder zurück und das ganz ohne Kennwort!

Da nun mal jedes Programm, dessen Parameter man kennt, auch per SQL aufrufen kann, kann man sich ja gut vorstellen, dass man auch via ODBC ein riesiges, zusätzliches, Scheunentor findet.
Zumal der Aufruf von QCMDEXC mittels Wrapper-Prozedur ja auch ohne Längenberechnung möglich ist.

Da finde ich den obigen IBM-Fehler ja geradezu lachhaft, oder hat den mal irgendwer bemerkt?

[holgerscherer]

Nun, wer das Paket Infor-XPPS (Brain, Rembold+Holzer) kennt, der sollte auch hier die größte Sicherheitslücke kennen:

schrottige Software fliegt spätestens beim Audit raus. Aber da viele ja glauben, die "AS/400 ist von Haus aus sicher", trauen sich da nicht viele.
Wer sowas betreibt oder selbst so lange verbiegt, bis alles läuft, gehört einfach nur geschlagen.