Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File write on PostgreSQL 9.1.15 fails #1170

Closed
bdamele opened this issue Feb 20, 2015 · 14 comments
Closed

File write on PostgreSQL 9.1.15 fails #1170

bdamele opened this issue Feb 20, 2015 · 14 comments
Assignees
Milestone

Comments

@bdamele
Copy link
Member

bdamele commented Feb 20, 2015

File write operations (hence takeover) fails on PostgreSQL 9.1.5 with an error on lo_export():

[20:47:01] [PAYLOAD] 1;SELECT lo_export(2008, '/tmp/test123.txt')--
[20:47:01] [WARNING] parsed DBMS error message: 'ERROR:  pg_largeobject entry for OID 2008, page 0 has invalid data field size 2378'

This happens also if connected as postgres with psql to the database locally. Same statements worked on PostgreSQL 9.1.11.

Check documentation on http://www.postgresql.org/docs/9.1/static/catalog-pg-largeobject.html.

@bdamele bdamele self-assigned this Feb 20, 2015
@bdamele bdamele added this to the 1.0 milestone Feb 20, 2015
@RicterZ
Copy link
Contributor

RicterZ commented Jun 2, 2015

Hello, I read the document and found:

 The amount of data per page is defined to be LOBLKSIZE (which is currently BLCKSZ/4, or typically 2 kB).

It means that every block of the data inserted into pg_largeobject less than 2kb.
So, I think you should split the data:

 SELECT lo_create(12345);
 INSERT INTO pg_largeobject VALUES (12345, 0, decode('7f454c4...0000', 'hex')); //less than 2kb
 INSERT INTO pg_largeobject VALUES (12345, 1, decode('0000000...0000', 'hex'));  //less than 2kb
 INSERT INTO pg_largeobject VALUES (12345, 2, decode('f604000...0000', 'hex')); //less than 2kb
 INSERT INTO pg_largeobject VALUES (12345, 3, decode('0000000...7400', 'hex')); //less than 2kb
 SELECT lo_export(12345, '/tmp/test.so');
 SELECT lo_unlink(12345);

@bdamele
Copy link
Member Author

bdamele commented Jun 4, 2015

@RicterZ thanks for trouble-shooting this.

@stamparm
Copy link
Member

Will deal with it these days
On Jul 21, 2015 9:07 PM, "Kamulha" [email protected] wrote:

Hi!
I encountered this problem with PostgreSQL 9.1.16 and 9.1.18 (64 bit).
The strange thing is that SQLMap doesn't output any problem, it says the
right file size on the server (8136 bytes).
But obliviously nothing is working, --os-shell gives no output and
--os-pwn encounters a timeout with all of the available options.
Are you going to fix this soon?
Thanks in advance.
Kamulha


Reply to this email directly or view it on GitHub
#1170 (comment)
.

@stamparm stamparm assigned stamparm and unassigned bdamele Jul 24, 2015
@stamparm
Copy link
Member

Couple of related screenshots:

1
2
3
4
5
6

@RicterZ
Copy link
Contributor

RicterZ commented Jul 24, 2015

👍

@stamparm
Copy link
Member

still have some stuff to do :)

@stamparm
Copy link
Member

Now it should work on both PostgreSQL 8 and >=9 ;)

@stamparm
Copy link
Member

@Kamulha Maybe you'll have problems with WRITE permissions, but that's maybe.

Combination of https://raw.githubusercontent.com/sqlmapproject/testenv/master/libs/pgsql.inc.php and https://raw.githubusercontent.com/sqlmapproject/testenv/master/pgsql/get_int.php should suffice. You'll have to modify them though (username, password, ...).

@stamparm
Copy link
Member

@Kamulha no. pgsql.inc.php also contains function dbQuery. Concatenate those two files (get_int.php and pgsql.inc.php), modify settings (username, password, port, etc.) and upload them as one file.

@stamparm
Copy link
Member

file size check is broken. its independent of this issue. will check later.

p.s. current implementation just checks whether the "supporting" table(s) have been filled as they should.

@stamparm
Copy link
Member

I am not sure if I follow. Can you please explain what you meant with this last message?

@stamparm
Copy link
Member

I would say that you have write permission problems. Have you tried to write to e.g. directory /tmp. I've warned you about this

@stamparm
Copy link
Member

table "sqlmapfile" does not exist is a standard error. Its just cleaning (if exists) the old table

@stamparm
Copy link
Member

@Kamulha this really doesn't look like a generic case. Not sure how to help you here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants