Anmelden

View Full Version : FLASH - Sicherheitslücke in IBM i DB2 - schnell mal PTF laden



Seiten : 1 [2] 3

Pikachu
15-03-24, 10:00
„IBM i is vulnerable to a user gaining elevated privilege due to a CL command being called without library qualification, in Db2 for IBM i, …“

„IBM i ist anfällig dafür, dass ein Benutzer erhöhte Berechtigungen erhält, weil ein CL-Befehl ohne Bibliotheksqualifizierung aufgerufen wird, in Db2 für IBM i, …“

Fuerchau
15-03-24, 10:25
Den Text habe ich verstanden. Dies kann jedoch nur passieren, wenn das Programm via OWNER erhöhte Berechtigung mitbringt. QCMDEXC ist es z.B. nicht.
Welche Sicherheitslücke wird da nun wie geschlossen? Ist der unqualifizierte Prozeduraufruf nicht mehr erlaubt? Das wäre wirklich fatal.

Sicherlich kann ich per SQL via ODBC einen DSPPGM *OUTFILE erstellen und mir Programme mit OWNER-Berechtigung ermitteln. Solange ich aber über die Parameter nichts herausfinde kann ich diese Programme nicht aufrufen ohne dass diese dann abstürzen.

Mit ein wenig Mühe kann ich via QCMDEXC eine SRC-PF erstellen, einen Quelltext schreiben und ein Programm erstellen (analog RDi). Aber ohne die nötige Berechtigung wie ALLOBJ kann ich den Eigner nicht auf z.B. QSECOFR stellen und die Ausführung auf *OWNER.

Ich musste mir mal selber bei einem Kunden erhöhte Rechte geben, weil der Admin Urlaub und der Produktionsleiter sein Profil abgeschossen hatte.
Per DSPUSRPRF in *OUTFILE habe ich mir einen User herausgesucht, der *ALLOBJ hatte und für den ich auf Grund des Gruppenprofiles ebenso Rechte hatte.
Somit konnte ich einen einmaligen SCD-Job erstellen, der einen SBMJOB mit QSECOFR ausführte mit der Berechtigung dieses Users, der dann wiederum einen CHGUSRPRF für mein Profil mit *ALLOBJ und *SECADM aufrief.
Aber ohne die Sicherheitslücke *ALLOBJ hätte ich nicht helfen können.

Fuerchau
15-03-24, 10:36
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
15-03-24, 11:33
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
15-03-24, 11:59
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
15-03-24, 13:21
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
15-03-24, 13:32
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
15-03-24, 18:47
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
15-03-24, 21:12
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
15-03-24, 21:14
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 ;-)