Andrew Bartlett wrote:
> This code in psql/command.c allows *any* system user to place a
> predictably named symbolic link in /tmp and use it to alter/destroy
> files owned by the user running psql. (tested - postgresql 7.0.2).
> All the information a potential attacker would need are available via a
> simple 'ps'.
> It might (untested) also allow an another user to exploit the race
> between the closing of the file by the editor and the re-reading of its
> contents to execute arbitrary SQL commands.
> IMHO these files, if they must be created in /tmp should at least be
> created O_EXCL, but there are still editor vulnerabilities with opening
> any files in a world writeable directory (see recent joe Vulnerability:
> My system is RedHat 6.2 on an i686, with Postgresql 7.0.2 but the same
> code currently exists in CVS (or at least CVS-web).
> I am not subscribed to this list, so please CC me for replies. (Also
> tell me if there is a more appropriate forum for this, but
> www.postgresql.org doesn't have a listed security issue address).
> Andrew Bartlett
Sorry, forgot to inlude the offending code....
(This is part of do_edit, called from edit_file and the \e query buffer
fname = filename_arg;
/* make a temp file to edit */
const char *tmpdirenv = getenv("TMPDIR");
tmpdirenv ? tmpdirenv : "/tmp",
(long) geteuid(), (long) getpid());
GetTempFileName(".", "psql", 0, fnametmp);
fname = (const char *) fnametmp;
oldumask = umask(0177);
stream = fopen(fname, "w");
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2000-11-25 01:15:30|
|Subject: Are pg_control contents really variable-length?|
|Previous:||From: Lamar Owen||Date: 2000-11-25 00:41:46|
|Subject: Re: OK, that's one LOCALE bug report too many...|