[HACKERS] Just a thought
Just think, that maybe a postgresql php coder (or admin if you like it), email me, and give me *.php sources. Seems like most of his scripts written in a very insecure and lame style. Best regards. This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Just a thought
Sure not. I even don't argue that. But i dont like that a postgresql.org could be just that easily owned. On Wed, 9 Oct 2002, Sir Mordred The Traitor wrote: Just think, that maybe a postgresql php coder (or admin if you like it), email me, and give me *.php sources. Seems like most of his scripts written in a very insecure and lame style. Probably no worse than your writing style. Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup from $16.00/mo at Pop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com http://www.unknown-artists.com == This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Little note to php coders
Check out this link, if you need something to laugh at: http://www.postgresql.org/idocs/index.php?1' Keeping in mind, that there are bunch of overflows in PostgreSQL(really?), it is very dangerous i guess. Right? This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Little note to php coders
Nice. That little, cute admin :-). This is already fixed, and where is 'thanks' i wonder? I've been talking about sql injection. How about that in http://www.postgresql.org/mirrors/index.php: --- Warning: PostgreSQL query failed: ERROR: invalid INET value 'r' in /usr/local/www/www/mirrors/index.php on line 263 Database update failed, contact the webmaster. insert into mirrorsites(mirrorhostid,ipaddr,portnum,...) values(..) -- Insert statement is shortened. This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Misc replies
And dealing with a real name would be nice, IMHO. Otherwise we may end up with 'SMtT' as the nickname, 'SMitTy' perhaps ? :-) Never camed across with such an offensive bullshit. But we will not end up with 'SMtT' nor with 'SMitTy', i am sure of it. Also , i never camed across with the situation, when people asked me in rather offensive style to provide my real name and i a bit confused... Thanks anyway. That was a very interesting experience. If he wants to call himself 'Sir Modred' or 'Donald Duck' or 'Jack the Ripper' or whatever... I do NOT want to call myself 'Donald Duck' nor 'Jack The Ripper' nor 'whatever'... Even in the security business, where people routinely use pseudonyms ... I am not in a security business, in fact i don't give a fuck about the security business at all... I am just an ordinary javascript programmer. When you have to read and process nearly 1,000 e-mails a day (as I have had to do) That'is your problem, if you are not able to do that, change the job.. At least I didn't just bitch and moan about the bugs. ;) Good boy, but surely that's me who is moaning and bitching about the bugs here? This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] @(#)Mordre Labs advisory 0x0005: Several buffer overruns in PostgreSQL
//@(#) Mordred Labs advisory 0x0005 Release data: 23/08/02 Name: Several buffer overruns in PostgreSQL Versions affected: all versions Risk: from average to low --[ Description: PostgreSQL provides you with several builint geo types (circle,polygon,box...etc). Unfortunately the code for geo functions written in a very insecure style and should be totally rewritten, as a quick search revealed this: ---[ Details: 1) Upon invoking a polygon(integer, circle) function a src/backend/utils/adt/geo_ops.c:circle_poly() function will gets called, which suffers from a buffer overflow. 2) A src/backend/adt/utils/geo_ops.c:path_encode() fails to detect a buffer overrun condition. It is called in multiple places, the most interesting are path_out() and poly_out() functions. 3) Upon converting a char string to a path object, a src/backend/utils/adt/geo_ops.c:path_in() function will gets called, which suffers from a buffer overrun, caused by a very long argument. 4) A src/backend/utils/adt/geo_ops.c:poly_in() function fails to detect a buffer overrun condition caused by a very long argument. 5) A src/backend/utils/adt/geo_ops.c:path_add() also fails to detect a simple buffer overrun. 6) And finally, a truly dumb feature (not a security related though) in postmaster: $ postmaster -o `perl -e 'print \x66 x 1200'` Segmentation fault (core dumped) --[ How to reproduce: I only show how to reproduce a first buffer overrun condition, as the others too memory consuming :-) 1) template1=# select polygon(268435455,'((1,2),3)'::circle); pqReadData() -- backend closed the channel unexpectedly. This probably means the backend terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. !# --[ Solution Drop the vulnerable functions. This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
//@(#) Mordred Labs advisory 0x0007
Release data: 26/08/02
Name: Remote DoS condition in PostgreSQL
Versions affected: all versions
Conditions: entry in a pg_hba.conf file that matches attacker's host.
Risk: average
---[ Description:
Upon connecting to a database, postmaster will fork a new process.
After that, a child process will call a
src/backend/postmaster/postmaster.c:DoBackend() routine,
which after processing a startup packet (see src/include/libpq/pqcomm.h),
will invoke a src/backend/libpq/auth.c:ClientAuthentication() routine to
perform client authentication.
If there is an entry in pg_hba.conf file, that matches an attacker's host,
an attacker could trigger
invocation of src/backend/libpq/auth.c:recv_and_check_password0(), which
fails to detect a DoS condition.
---[ Details:
Consider this snip of code from src/backend/libpq/auth.c:
[snip]
static int recv_and_check_password0(Port *port) {
int32 len;
char *buf;
if (pq_getint(len, 4) == EOF)
return STATUS_EOF;
len -= 4;
buf = palloc(len); /* len is taken from a packet */
[snip]
Note, that the size of palloced memory is taken from the user's input,
which is stupid if you ask me.
--[ How to reproduce:
I dont want to provide any tools to illustrate this vulnerability.
--[ Solution
Disable network access for untrusted users.
This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com/inf/en
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
The point is really simple. Allocate a huge chunk of memory (no sense to cause out of memory error, as palloc will bail is a requested size 1 gb). The postgres will be ready to suck your input, via pg_getbytes(), now in a loop send junk to postgresql. Of course you can fork a number of processes to improve your effect. The issues is that postgres allocate a chunk of memory and reads data, using an user's input, which has not completed authentication. This is badly anyway. Of course i tried, and wrote proggy for that, but i can repeat, i dont want to provide it here. Sir Mordred The Traitor [EMAIL PROTECTED] writes: Note, that the size of palloced memory is taken from the user's input, which is stupid if you ask me. Beyond causing an out of memory error during the handshake, I fail to see how there can be any problem. palloc is considerably more robust than malloc. I dont want to provide any tools to illustrate this vulnerability. Perhaps you haven't tried. It may indeed make sense to put a range check here, but I'm getting tired of hearing the words dos attack applied to conditions that cannot be exploited to cause any real problem. All you are accomplishing is to spread FUD among people who aren't sufficiently familiar with the code to evaluate the seriousness of problems... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] btw
By the way, seems like a beer DOSsed me a little:-). I've made i mistake in email subject. Remove-remote This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Upcoming Beta
Hi. There is no need to ask me to attack a postgresql source code, as long as i remember myself, i was always in studing someone's source code or disasm output.. By the way, the code i write being a plain web programmer, even for small projects is fairly buggy:-))). One little thing saves me a bit - i am using a perl, and the code itself dont suffer from the buffer/integer overflows much, not talking about DBD::Pg. So i can repeat the above, don't ask me to do the things which i am doing 24 hours in a day... Best regards. This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Release of v7.2.2
Marc G. Fournier [EMAIL PROTECTED] writes: Are we all caught up now on the known bugs/fixes? Would it be reasonably safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon? Maybe it makes sense to wait about a week. This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] i'll promise, i'll be polite :-)
Hi. This post certainly contains no valuable information, but i feel i should clarify some points. 1) I like postgresql and i worked with it for a long time. 2) Solution like killall -9 postmaster was just a joke. 3) ...Hm..i forgot...maybe later ... This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] @(#)Mordred Labs advisory 0x0002: Buffer overflow in PostgreSQL
Seems like this one was lost or was filtered out... //@(#)Mordred Labs advisory 0x0002 Release data: 19/08/02 Name: Buffer overflow in PostgreSQL Versions affected: all versions Risk: high --[ Description: There exists a buffer overflow in a SET TIME ZONE command, that allows an attacker to execute malicious code. --[ Details: Upon executing the SET TIME ZONE 'STRING' command, parse_timezone() function is invoked, which will overwrite a static buffer tzbuf with the supplied string. Look at the src/backend/commands/variable.c if you need something to laugh at. --[ How to reproduce: psql SET TIMEZONE to 'XX...very long string...X' ... NOTICE: Buffer Leak: [27191] (freeNext=0, freePrev=0, rel=0/0, blockNum=0, flags=0x0, refcount=0 128) NOTICE: Buffer Leak: [27192] (freeNext=0, freePrev=0, rel=0/0, blockNum=0, flags=0x0, refcount=0 1249) NOTICE: Buffer Leak: [27193] (freeNext=0, freePrev=0, rel=0/0, blockNum=0, flags=0x0, refcount=0 1651799137) NOTICE: Buffer Leak: [27194] (freeNext=0, freePrev=0, rel=0/0, blockNum=0, flags=0x0, refcount=0 1818326649) ... pqReadData() -- backend closed the channel unexpectedly. This probably means the backend terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. --[ Solution: Just wait... This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
