Fwd: Infinite recursion in function causes DoS
Hi PostgreSQL hackers!
We recently received and discussed a Debian bug report agains
postgresql. If you have time, please have a look at
In short it was requested to limit the depth of (recursive) function
calls to prevent database crashes. Would it be possible to do that in
PostgreSQL? This depth should be configurable in
----- Forwarded message from Ivo Timmermans <ivo@debian.org> -----
From: Ivo Timmermans <ivo@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Infinite recursion in function causes DoS
Date: Wed, 24 Mar 2004 14:54:57 +0100
X-Spam-Status: No, hits=-7.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2004_03_12
Package: postgresql
Version: 7.4.2-1
Severity: important
Tags: security
Hi,
Consider the following function:
CREATE FUNCTION testfn(INT) RETURNS INT
AS '
SELECT testfn($1);
' LANGUAGE 'SQL';
which is obviously an infinite recursion. When I call this function,
the postmaster process tries to allocate more and more memory at an
astonishing rate, until either the kernel dies, or the OOM killer
decides that it has been letting postgres have enough fun.
Either way, this situation leads to a DoS of the database system or the
entire machine. Since any user with enough privileges to access the
database can create and execute functions, this raises a slight security
concern.
-- System Information:
Debian Release: testing/unstable
APT prefers experimental
APT policy: (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.3
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8
Versions of packages postgresql depends on:
ii adduser 3.51 Add and remove users and groups
ii debconf [debconf 1.4.17 Debian configuration management sy
ii debianutils 2.7.5 Miscellaneous utilities specific t
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an
ii libcomerr2 1.35-4 The Common Error Description libra
ii libkrb53 1.3.2-2 MIT Kerberos runtime libraries
ii libpam0g 0.76-15 Pluggable Authentication Modules l
ii libperl5.8 5.8.3-2 Shared Perl library.
ii libpq3 7.4.2-1 Shared library libpq.so.3 for Post
ii libreadline4 4.3-10 GNU readline and history libraries
ii libssl0.9.7 0.9.7d-1 SSL shared libraries
ii mailx 1:8.1.2-0.20031014cvs-1 A simple mail user agent
ii postgresql-clien 7.4.2-1 Front-end programs for PostgreSQL
ii procps 1:3.2.0-1 The /proc file system utilities
ii python2.3 2.3.3-6 An interactive high-level object-o
ii zlib1g 1:1.2.1-5 compression library - runtime
-- debconf information:
* postgresql/upgrade/preserve_location: /var/lib/postgres/preserve
* postgresql/settings/day_month_order: European
postgresql/convert-postmaster.init: true
* postgresql/upgrade/policy: true
postgresql/enable_lang: true
postgresql/contains_POSTGRESHOME: true
postgresql/very_old_version_warning: true
* postgresql/upgrade/dump_location: /var/lib/postgres
postgresql/convert-pg_hba.conf: true
* postgresql/settings/vacuum_full:
* postgresql/initdb/location: /var/lib/postgres/data
shared/postgresql/upgrade74: false
* postgresql/settings/locale: C
postgresql/peer-to-ident: true
postgresql/missing_conf: true
* postgresql/purge_data_too: false
* postgresql/settings/encoding: UNICODE
* postgresql/settings/date_style: ISO
----- End forwarded message -----
--
Martin Pitt Debian GNU/Linux Developer
martin@piware.de mpitt@debian.org
http://www.piware.de http://www.debian.org
Martin Pitt wrote:
Hi PostgreSQL hackers!
We recently received and discussed a Debian bug report agains
postgresql. If you have time, please have a look atIn short it was requested to limit the depth of (recursive) function
calls to prevent database crashes. Would it be possible to do that in
PostgreSQL? This depth should be configurable in
This will be fixed in 7.5 with a new max_stack_depth configuration
varible.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Martin Pitt <martin@piware.de> writes:
In short it was requested to limit the depth of (recursive) function
calls to prevent database crashes.
http://archives.postgresql.org/pgsql-committers/2004-03/msg00249.php
regards, tom lane
On Thu, Mar 25, 2004 at 12:25:33 +0100,
Martin Pitt <martin@piware.de> wrote:
Either way, this situation leads to a DoS of the database system or the
entire machine. Since any user with enough privileges to access the
database can create and execute functions, this raises a slight security
concern.
It is going to be very difficult to prevent authorized postgres users
from DOSing the server. While fixing this issue will make it harder
to accidentally shoot ones self in the foot, you cannot expect to give
untrusted users access to postgres and have the server be secure from
DOS attacks.