Zahlreiche Stored Procedures, die teilweise für den Betrieb von PostgreSQL notwendig sind, weisen Pufferüberlaufschwachstellen und andere Probleme auf.

Betroffene Systeme

• Systeme, die PostgreSQL (bis einschließlich 7.2.1) verwenden.

Einfallstor
Zugangsberechtigung zu einer beliebigen PostgreSQL-Datenbank.

Auswirkung

1. Denial of Service, wahrscheinlich auch Kompromittierung des Datenbank-Superusers (der in der Regel dem UNIX-Account "postgres" entspricht).
2. Denial of Service, Auslesen von internen Datenstrukturen des PostgreSQL-Servers

Typ der Verwundbarkeit

1. buffer overflow bug
2. design flaw

Gefahrenpotential
hoch
(Hinweise zur Einstufung des Gefahrenpotentials.)

Beschreibung

1. Eine Reihe von Stored Procedures zur Oracle-Kompatibilität berechnen Puffergrößen nicht korrekt, wodurch es zu Pufferüberläufen kommen kann. Die betroffenen Stored Procedures ("lpad", "rpad", "translate", "repeat") sind in üblichen Installationen verfügbar. Die Schwachstellen in "lpad, "rpad" und "translate" sind nur dann relevant, falls zur Kompilierzeit Multibyte-Unterstützung aktiviert wurde, was aber durchaus üblich ist.

   Es ist davon auszugehen, daß die Schwachstelle in "repeat" es Angreifern (mit der Möglichkeit, beliebige SQL-Befehle an die Datenbank zu schicken) ermöglicht, beliebigen Programmcode mit den Rechten des Datenbank-Superusers auszuführen (typischer sind dies die Rechte des UNIX-Accounts "postgres").

2. Eine weitere Schwachstelle betrifft den Umgang von PostgreSQL mit einigen internen Konvertierungsfunktionen. Diese Stored Procedures sind aus technischen Gründen so in der Datenbank registriert, das für ihre Argumente keinerlei Typüberprüfung notwendig ist. Übergebene Ganzzahlen werden als Zeiger interpretiert, damit ist es möglich, Speicherbereiche auszulesen, auf die der PostgreSQL-Nutzer normalerweise keinen Zugriff besitzt. Falls die übergebene Adresse nicht gültig ist, kommt es (wie z.B. SELECT cash_out(2);) zu einem Absturz (weswegen dieser Fehler auch als "cash_out bug" bezeichnet wird).

   Von dieser Problematik sind eine ganze Reihe von Stored Procedures betroffen. Eine Liste von Kandidaten kann über die SQL-Anweisung

   SELECT proname
       FROM pg_proc
       WHERE proargtypes = '' AND pronargs = 1 AND proisstrict = 't'
       ORDER BY proname;
   

   angezeigt werden; die Mehrheit dieser Stored Procedures ist auch tatsächlich von dem Fehler betroffen.

In beiden Fällen können Angreifer das Server-Backend komplett zum Absturz bringen (wodurch die Verbindungen zu anderen Clients ebenfalls unterbrochen werden). Dies ist insbesondere problematisch, wenn PostgreSQL-Clients unterbrochene Verbindungen nicht automatisch wiederherstellen.

Gegenmaßnahmen

1. Die verwundbaren Oracle-Kompatibilitätsfunktionen werden i.d.R. nicht benötigt und können daher entfernt werden. Das folgende (nur mit bash getestete) Shell-Skript erledigt dies für alle Datenbanken. Da auch aus template0 die Stored Procedures entfernt werden, enthalten auch zukünftig angelegte Datenbanken sie nicht.

   LISTDB="SELECT datname FROM pg_database"
   
   drop_function () {
       psql -e -c "DROP FUNCTION $2;" "$1"
   }
   
   drop_functions () {
       drop_function "$1" 'lpad (text, int4)'
       drop_function "$1" 'lpad (text, int4, text)'
       drop_function "$1" 'rpad (text, int4)'
       drop_function "$1" 'rpad (text, int4, text)'
       drop_function "$1" 'repeat (text, int4)'
       drop_function "$1" 'translate (text, text, text)'
   }
   
   
   psql -A -c "$LISTDB" template1 | tail +2 | grep -v '^(' | 
   while read db ; do
           echo "Modifying database $db..."
           drop_functions "$db"
   done
   

   Bis auf das Problem in translate wird diese Schwachstelle auch in PostgreSQL 7.2.2 behoben (zusammen mit einem weiteren Pufferüberlauf im SQL-Kommando SET TIME ZONE).

2. Bei der zweiten Schwachstelle ist keine leichte Abhilfe möglich, da die fehlende Typüberprüfung eine Schwäche im Design ist. Außerdem werden einige der Stored Procedures für den reibungslosen Betrieb benötigt.

   Vorschläge zur Behebung existieren; es ist jedoch noch unklar, ob sich diese im Kontext der 7.2-Versionen mit vertretbarem Aufwand umsetzen lassen. Ob das Problem in PostgreSQL 7.3 behoben werden wird, ist ebenfalls nicht sicher.

Weitere Information zu diesem Thema

• Mordred Labs advisory 0x0003: Multiple buffer overflows in PostgreSQL.
• Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL.
• Alvaro Herrera: cash_out bug
• Tom Lane: Proposal: make "opaque" obsolete
• Ankündigung von PostgreSQL 7.2.2

Revisionen dieser Meldung

• V.1.0 (2002-08-21)
• V.1.1 (2002-08-26) Veröffentlichung von PostgreSQL 7.2.2

Weitere Artikel zu diesem Thema:

• [Generic/PostgreSQL] Pufferüberlauf bei der Verarbeitung von Datumsangaben (2002-08-05)
  Die Routine, die in SQL-Abfragen Datums- und Zeitangaben verarbeitet, weist eine Pufferüberlaufschwachstelle auf.

Hinweis
Die in diesem Text enthaltene Information wurde für die Mitglieder der Universität Stuttgart recherchiert und zusammengestellt. Die Universität Stuttgart übernimmt keinerlei Haftung für die Inhalte. Dieser Artikel darf ausschließlich in unveränderter Form und nur zusammen mit diesem Hinweis sowie dem folgenden Copyrightverweis veröffentlicht werden. Eine Veröffentlichung unter diesen Bedingungen an anderer Stelle ist ausdrücklich gestattet.

Copyright © 2022 RUS-CERT, Universität Stuttgart, https://cert.uni-stuttgart.de/