pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedDoS Vulnerability
2+ messages / 2 participants
[nested] [flat]
* DoS Vulnerability
@ 2024-05-14 16:18 emad al-mousa <emadalmousa2002@yahoo.com>
0 siblings, 1 reply; 2+ messages in thread
From: emad al-mousa @ 2024-05-14 16:18 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Hello,
In the documentation: 5.7. Privileges
| | |
5.7. Privileges
|
“For other types of objects, the default privileges granted to PUBLIC are as follows: CONNECT and TEMPORARY (create temporary tables) privileges for databases; EXECUTE privilege for functions and procedures; and USAGE privilege for languages and data types (including domains). The object owner can, of course, REVOKE both default and expressly granted privileges. (For maximum security, issue the REVOKE in the same transaction that creates the object; then there is no window in which another user can use the object.)”
by default any role/user in postgresql can connect to "ANY" database in the cluster so even though the account can only connect, the account can still create temporary object (for example temporary table). This table will be created in the default database tablespace of the database associated with...it will consume the space until it exhausts it....this means an application performing bulk write will face problems inserting data. keeping connect permission by default granted to PUBLIC in PostgreSQL is opening a wide security hole that shouldn't exist in the first. I strongly believe this should be patched and connect permission should be revoked from PUBLIC in all databases and template1 database (the base database where DB's are created based on)
account donald who is defined in pg_hba.conf file to authenticate against postgres database as shown below, will be able t connect to "odsdb" database and exhaust tablespace and cause Denial Of Service.
$ /usr/pgsql-15/bin/psql -h localhost -U donald -d postgres -WPassword:psql (15.6)SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)Type "help" for help.
postgres=> \c odsdbPassword:SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)You are now connected to database "odsdb" as user "donald".odsdb=> create temporary table tempo as select * from generate_series(1,1000000000000000000000000000000000000);ERROR: could not write to file "pg_tblspc/16389/PG_15_202209061/pgsql_tmp/pgsql_tmp7557.7": No space left on device
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: DoS Vulnerability
@ 2024-05-14 17:28 David G. Johnston <david.g.johnston@gmail.com>
parent: emad al-mousa <emadalmousa2002@yahoo.com>
0 siblings, 0 replies; 2+ messages in thread
From: David G. Johnston @ 2024-05-14 17:28 UTC (permalink / raw)
To: emad al-mousa <emadalmousa2002@yahoo.com>; +Cc: PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
On Tue, May 14, 2024, 10:12 emad al-mousa <emadalmousa2002@yahoo.com> wrote:
>
> keeping connect permission by default granted to PUBLIC in PostgreSQL is
> opening a wide security hole that shouldn't exist in the first.
>
This isn't a bug nor a security issue, but I do concur that we should
remove these defaults. We've successfully (without being questioned why by
users) done both public schema and createrole attribute changes in the past
couple of years and this seems like a natural progression of secure
defaults.
David J.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-05-14 17:28 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-05-14 16:18 DoS Vulnerability emad al-mousa <emadalmousa2002@yahoo.com>
2024-05-14 17:28 ` David G. Johnston <david.g.johnston@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox