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

[holgerscherer]

es ist mal wieder Zeit für eine kritische (und peinliche) Sicherheitslücke.
Dringend V7R2 - V7R5 mit PTF versorgen!

https://www.ibm.com/support/pages/no..._-OCSS9QQS-_-E

[Andreas_Prouza]

Danke für den Hinweis Holger!

[Fuerchau]

Und was wird mit diesem PTF dann behoben?

Z.B. wird eine Prozedur/Funktion entwickelt, die mit OWNER-Privileg in eine Lib erstellt wird, die durch die System-LIBL an den Anfang eines Jobs gestellt wird.
Da nun die wenigsten im RPG mit Naming=*SQL (unqualifizierte Zugriffe mit Lib "USERNAME") sondern mit NAMING=*SYS (unqualifizierte Zugriffe per LIBL) arbeiten, kann diese Prozedur von jedem User aufgerufen werden und sie tut was sie soll.

Wenn dies nun mit dem PTF nicht mehr möglich ist, stehen viele Anwendungen plötzlich vor einem Problem.

Aus der Beschreibung zum PTF werde ich nicht schlau, was a) das Problem ist und b) was behoben wird.

[Pikachu]

Vielleicht ist bisher ein Mittelsmannangriff möglich!?

[Fuerchau]

Jedes Programm kann, wenn man die Berechtigung dazu hat, ausgetauscht werden um was anderes zu tun, als man ursprünglich geplant hat.
Dies macht man auch z.B. bei sog. Wrapperprogrammen, die in einem ERP ohne Quellen aufgerufen werden um vorher und/oder hinterher Zusatzfunktionen durchzuführen.
Wenn man die Quellen hätte, bräuchte man dies nicht, da man dort die passenden Änderungen durchführt.
Dies geht i.Ü. auch so mit Triggern, die man einfach einsetzt um Daten zu manipulieren oder zusätzliche Aktionen durchzuführen.
Dabei ist es auch legitim, Programme unter OWNER laufen zu lassen.

Manche propagierten Sicherheitslücken treten ja nur auf, wenn jemand mit hoher Berechtigung die Möglichkeit bekommt, ins System eingreifen zu können.

Deshalb möchte ich halt wissen, was mit dem PTF verhindert werden soll.

[Pikachu]

Vielleicht kann man ein eigenes Programm ins System reinschmuggeln (durch CHGSYSLIBL) und dieses wird wenn es passend heißt mit Systemrechten aufgerufen!?

[holgerscherer]

Und was wird mit diesem PTF dann behoben?

es geht um SQL-Functions, die (warum auch immer) teilweise eine API via CL aufrufen. Normalerweise qualifiziert in einer QSYS-Bibliothek. Was man wohl vergessen hat...

[holgerscherer]

Jedes Programm kann, wenn man die Berechtigung dazu hat, ausgetauscht werden um was anderes zu tun, als man ursprünglich geplant hat.
Deshalb möchte ich halt wissen, was mit dem PTF verhindert werden soll.

man könnte ja auch in die Tiefen der einzelnen PTF gehen und selbst nachsehen.
Wenn Du natürlich im System rumfummelst, um dem ERP auf die Beine zu helfen, ist das Dein Problem.
Oder wenn jeder User *ALLOBJ hat, oder seclvl 40 oder niedriger im Einsatz ist.
Falsch machen kann man viel. Aber in dem Fall hat die IBM einen Bock eingebaut, den jeder *USER ausnutzen könnte.

[Pikachu]

Alles halb so wild!? Der Befehl CHGSYSLIBL wird mit öffentlicher Berechtigung *EXCLUDE ausgeliefert. Nur ein Benutzer mit der Sonderberechtigung *ALLOBJ und *SECADM kann den Systemwert QSYSLIBL ändern. Nur auf diese beiden Arten können eigene Programme vor Systemprogramme in QSYS gestellt und zuerst gefunden werden solange ein Systemprogramm eh nicht direkt über Adresse im SEPT aufgerufen wird.

[Fuerchau]

Aber aus der PTF-Beschreibung werde ich halt nicht schlau, was denn genau verhindert werden soll.
Dass jeder User mit Sonderberechtigung *ALLOBJ eingerichtet ist, ist leider zu häufig die Regel.
Solange jedoch die User via ERP über Menü o.ä. keine Kommandozeile bekommen, und zumindest limmited User im Profil eingestellt ist, kann ich eben auch WRKSPLF aufrufen und mit der kurzen CMD-Line kann man keine Kommandos aufrufen.

Und was die SEPT angeht, so ist das eine Liste von fest eingestellten Programmadressen, die nicht geändert werden können. In Release 2.1 hatte ich das mal probiert und eine Adresse ausgetauscht. In der Folge mussten wir das System komplett neu installieren, da die SEPT nicht reparabel ist.

Wenn ich also QCMDEXC ersetzen will (wenn ich es könnte), also das Programm lösche und austausche, verbleibt in der SEPT entweder ein Pointer auf das Ursprungsobjekt oder auf einen verwaisten Pointer, was zum MCH-Fehler führt.

Was den CHGSYSLIBL angeht, so wird dieser auch gerne mit höherer Berechtigung aufgerufen um z.B. die entsprechende System-Sprachbibliothek je User individuell vorzuschalten.

Wenn ich das PTF lese, heißt dies nun, dass ich den SQL-CALL unqualifiziert nicht auf höher privelegierte Programme ausführen kann?

[Pikachu]

„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]

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.