Re: For review: Server instrumentation patch

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> didn't. One way that the attacker might proceed is to try to make a .so
> file that he can LOAD into the backend containing the equivalent of a
> system() function. I believe this is not feasible using COPY in its
> current form, mainly because you can't write arbitrary binary files with
> it (no embedded zeroes for instance). With a function to write

Now, I'm not the best hacker in the world, so I didn't actually get this
all the way to working (wish I had more time to play with it but I don't
really), but:

test=# create function unlink (text) RETURNS integer LANGUAGE 'C' AS
'/lib/libc-2.3.2.so', 'unlink';
CREATE FUNCTION
test=# select unlink('/tmp/test');

unlink
--------
-1

I had created /tmp/test, but it appears the 'oldstyle' function calls
pass in the arguments with some garbage on the front (about 4 bytes it
looked like from gdb). Figure out how to skip those 4 bytes per
argument and you hardly need any other .so, you've got libc. I suspect
it can be done. The newstyle API looks like it'd probably make it a bit
more difficult but still, being able to load any function from any .so
you've got access to seems *extremely* powerful to me, just as much as
any untrusted language.

If you want to secure your system against a superuser()-level intrusion
then you need to secure the unix account, or disable creation of
C-language and other untrusted languages (at least).

Stephen