database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
ㆍPostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
PostgreSQL News 6076 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 6076
SECURITY: Two New Problems Found
작성자
신기배(소타)
작성일
2005-05-03 15:57
조회수
7,439

SECURITY: Two New Problems Found

 

Posted on 2005-05-02

Posted by david@fetter.org


We are currently preparing new releases that will correct these

problems in freshly initdb'd installations. However, because

these problems are really incorrect system catalog entries,

updating to a new release will NOT by itself solve the problems

in an existing installation. Instead, it is necessary for the

database administrator to fix the catalog entries manually, as

described below. We are releasing this advisory to encourage

administrators of PostgreSQL installations to perform these fixes

as soon as possible.



 

Character conversion vulnerability


The more severe of the two errors is that the functions that

support client-to-server character set conversion can be called

from SQL commands by unprivileged users, but these functions are

not designed to be safe against malicious choices of argument

values. This problem exists in PostgreSQL 7.3.* through 8.0.*.

The recommended fix is to disable public EXECUTE access for these

functions. This does not affect normal usage of the functions for

character set conversion, but it will prevent misuse.


To accomplish this change, execute the following SQL command as a

superuser:



UPDATE pg_proc SET proacl = '{=}'

WHERE pronamespace = 11 AND pronargs = 5

AND proargtypes[2] = 'cstring'::regtype;


In 7.3.* through 8.0.*, this should report having updated 90

rows. 7.4 and later will report a "WARNING: defaulting grantor to

user ID 1" which can be ignored.


The above command must be carried out in *each* database of an

installation, including template1, and ideally including

template0 as well. If you do not fix the template databases then

any subsequently created databases will contain the same

vulnerability. template1 can be fixed in the same way as any

other database, but fixing template0 requires additional steps.

First, from any database issue



UPDATE pg_database SET datallowconn = true WHERE datname =

'template0';


Next connect to template0 and perform the pg_proc update.

Finally, do



-- re-freeze template0:

VACUUM FREEZE;

-- and protect it against future alterations:

UPDATE pg_database SET datallowconn = false WHERE datname =

'template0';


 

tsearch2 vulnerability


The other error is that the contrib/tsearch2 module misdeclares

several functions as returning type "internal" when they do not

have any "internal" argument. This breaks the type safety of

"internal" by allowing users to construct SQL commands that

invoke other functions accepting "internal" arguments. The

consequences of this have not been investigated in detail, but it

is certainly at least possible to crash the backend.


This error affects PostgreSQL 7.4 and later, but only if you have

installed the contrib/tsearch2 module. The recommended fix is to

change the misdeclared functions so that they accept an

"internal" argument and therefore cannot be called directly from

SQL commands.

To do this, execute the following command as a superuser:



UPDATE pg_proc SET proargtypes[0] = 'internal'::regtype

WHERE oid IN (

'dex_init(text)'::regprocedure,

'snb_en_init(text)'::regprocedure,

'snb_ru_init(text)'::regprocedure,

'spell_init(text)'::regprocedure,

'syn_init(text)'::regprocedure

);


This should report 5 rows updated. (If it fails with a message

like "function "dex_init(text)" does not exist", then either

tsearch2 is not installed in this database, or you already did

the update.)


You will need to do this in *each* database in which you have

installed tsearch2, including template1. You need not worry about

template0, however, since it will certainly not contain

tsearch2.


If you frequently install tsearch2 in new databases, you will

also want to modify the tsearch.sql script to declare these

functions as taking type internal in the first place. (The script

fix will be part of the upcoming releases, so you may be able to

wait for those.)


On behalf of the PostgreSQL core committee, I'd like to apologize

for any problems that may arise from these errors.


regards, tom lane

 

이 글에 대한 댓글이 총 1건 있습니다.

어제였나, 아무튼 며칠전에 이 글을 보고, 게시물을 쓰려고 하다가 귀찮아서 안하고 있었는데, 기배님이 올려주셨네요.

 

요지는 문자셋 변환 함수들을 일반 사용자가 호출할 수 있는 문제가 있어 이것을 윗 쿼리로 조정할 수 있다는 것과, tsearch2 모듈의 몇 함수들에 대한 권한을 조정 해야한다는 것입니다.

 

실무속에서 일반사용자가 psql 같이 쿼리문을 이것저것 사용하는 경우는 극히 드문지라, 별로 중요하지 않아서 무시했습니다.

 

아무튼 찜찜하신 분은 윗 글 대로 조정하시고, 이런것에 별로 관심 없으면 무시해도 될 부분같습니다.

 

김상기(ioseph)님이 2005-05-04 14:58에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
6087Mammoth PostgreSQL Replicator 8.0.2 Released
신기배
2005-05-10
7549
6085EMS PostgreSQL Data Export 2.0 released
신기배
2005-05-06
7130
6078PostgreSQL beats Oracle and MySQL on Windows
신기배
2005-05-04
6582
6076SECURITY: Two New Problems Found [1]
신기배
2005-05-03
7439
6072OpenRPT - Open source GUI report writer and renderer for PostgreSQL
신기배
2005-04-27
6421
6071ANN: PostgresDAC 2.0.2 is released
신기배
2005-04-26
6148
6069QLR Manager now includes PostgreSQL support
신기배
2005-04-25
7081
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.017초, 이곳 서비스는
	PostgreSQL v16.4로 자료를 관리합니다