[HACKERS] Build failure in current CVS (src/backend/utils/mb/conversion_procs)
Hi all, I get the following when I attempt to build outside of the source tree. All goes well until make[4]: Entering directory `/home/jgray/postgres/pg-build/src/backend/utils/mb/conversion_procs/ascii_and_mic' Makefile:11: ../proc.mk: No such file or directory make[4]: *** No rule to make target `../proc.mk'. Stop. Any suggestions. I've tried various things (cf. my previous message to -hackers but had no success -I really don't quite get all the details of the build or I would send a patch...) Regards John -- John Gray Azuli IT www.azuli.co.uk ---(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] [SECURITY] DoS attack on backend possible
On Mon, 19 Aug 2002 [EMAIL PROTECTED] wrote:
$input = user'name;
INSERT INTO db (name) VALUES ('$input');
will fail because the ' in the input needs to be escaped with a
backslash.
It will fail because you're doing this a very, very, very bad way.
Why rewrite this kind of stuff when the vendor has already made
correct code available?
PreparedStatement stmt = connection.prepareStatement(
INSERT INTO db (name) VALUES (?));
stmt.setString(user'name);
stmt.execute();
cjs
--
Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Mon, 19 Aug 2002, Tom Lane wrote: Justin Clift [EMAIL PROTECTED] writes: From the info still around, this looks to mean that the cash_words() problem was fixed, but the cash_out() problem was harder to fix. Tom/Bruce, is that correct? The cash_out problem can't really be fixed until we do something about subdividing type opaque into multiple pseudo-types with more carefully defined meanings. cash_out is declared cash_out(opaque) which does not really mean that it accepts any input type ... but one of the several meanings of opaque is accepts any type, so the parser doesn't reject cash_out(2). I'd like to see something done about this fairly soon, but it's not happening for 7.3 ... Can we trap and just return an error before it goes into the weeds and put the subdividing opaque fix in later? 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 == ---(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] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Mon, 19 Aug 2002, Tom Lane wrote: Justin Clift [EMAIL PROTECTED] writes: From the info still around, this looks to mean that the cash_words() problem was fixed, but the cash_out() problem was harder to fix. Tom/Bruce, is that correct? The cash_out problem can't really be fixed until we do something about subdividing type opaque into multiple pseudo-types with more carefully defined meanings. cash_out is declared cash_out(opaque) which does not really mean that it accepts any input type ... but one of the several meanings of opaque is accepts any type, so the parser doesn't reject cash_out(2). I'd like to see something done about this fairly soon, but it's not happening for 7.3 ... Does anyone have an idea about what other functions are affected by this? As a stop gap measure to remove the *known* DoS issue how about changing the pg_proc entry to restrict input types, i.e. not cash_out(opaque)? cash_words is already listed as only taking the money type is cash_out really that different? On a related topic cash_out() is listed in pg_proc as returning an int4 but doesn't the code clearly show that is incorrect? -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] regression test failures in CVS HEAD
Looks like the expected files weren't updated.
Probably my fault, but the tests themselves are fine.
On Tue, 2002-08-20 at 01:37, Neil Conway wrote:
The 'type_sanity' and 'domain' regression tests seem to fail with CVS
HEAD. Here's the diff:
*** ./expected/type_sanity.outSun Aug 4 15:48:11 2002
--- ./results/type_sanity.out Tue Aug 20 01:32:35 2002
***
*** 16,22
SELECT p1.oid, p1.typname
FROM pg_type as p1
WHERE (p1.typlen = 0 AND p1.typlen != -1) OR
! (p1.typtype != 'b' AND p1.typtype != 'c' AND p1.typtype != 'p') OR
NOT p1.typisdefined OR
(p1.typalign != 'c' AND p1.typalign != 's' AND
p1.typalign != 'i' AND p1.typalign != 'd') OR
--- 16,22
SELECT p1.oid, p1.typname
FROM pg_type as p1
WHERE (p1.typlen = 0 AND p1.typlen != -1) OR
! p1.typtype not in('b', 'c', 'd', 'p') OR
NOT p1.typisdefined OR
(p1.typalign != 'c' AND p1.typalign != 's' AND
p1.typalign != 'i' AND p1.typalign != 'd') OR
***
*** 60,66
-- NOTE: as of 7.3, this check finds SET, smgr, and unknown.
SELECT p1.oid, p1.typname
FROM pg_type as p1
! WHERE p1.typtype = 'b' AND p1.typname NOT LIKE '\\_%' AND NOT EXISTS
(SELECT 1 FROM pg_type as p2
WHERE p2.typname = ('_' || p1.typname)::name AND
p2.typelem = p1.oid);
--- 60,66
-- NOTE: as of 7.3, this check finds SET, smgr, and unknown.
SELECT p1.oid, p1.typname
FROM pg_type as p1
! WHERE p1.typtype in ('b','d') AND p1.typname NOT LIKE '\\_%' AND NOT EXISTS
(SELECT 1 FROM pg_type as p2
WHERE p2.typname = ('_' || p1.typname)::name AND
p2.typelem = p1.oid);
==
*** ./expected/domain.out Fri Jul 12 14:43:19 2002
--- ./results/domain.out Tue Aug 20 01:32:57 2002
***
*** 143,154
( col1 ddef1
, col2 ddef2
, col3 ddef3
! , col4 ddef4
, col5 ddef1 NOT NULL DEFAULT NULL
, col6 ddef2 DEFAULT '88'
, col7 ddef4 DEFAULT 8000
, col8 ddef5
);
insert into defaulttest default values;
insert into defaulttest default values;
insert into defaulttest default values;
--- 143,155
( col1 ddef1
, col2 ddef2
, col3 ddef3
! , col4 ddef4 PRIMARY KEY
, col5 ddef1 NOT NULL DEFAULT NULL
, col6 ddef2 DEFAULT '88'
, col7 ddef4 DEFAULT 8000
, col8 ddef5
);
+ NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index 'defaulttest_pkey'
for table 'defaulttest'
insert into defaulttest default values;
insert into defaulttest default values;
insert into defaulttest default values;
==
Cheers,
Neil
--
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
---(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 0x0001: Buffer overflow in
On August 19, 2002 11:58 pm, Rod Taylor wrote:
On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
The simple fix is to drop the money type entirely as it serves few
purposes -- but there are some who use it.
As the original creator of the type I probably have the most emotional
attachment to it but even I am thinking of dropping its use. I would have
preferred to fix it (more automatic casts and 64 bit storage as well as the
fixes in the current thread) but I seem to be alone so it hardly seems worth
it. I still think that there is some benefit to being able to do integer
arithmetic though. I know that I do a lot of calculations (mostly sums) on
money and going to numeric is going to be a hit. No matter how efficient it
is it can't be as efficient as a cpu register addition.
But maybe I'm wrong and the hit will be negligible.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] bison news
I just got the latest beta and it compiles ecpg grammar correctly! I had to make one change to my source though as bison no longer accepts a comma inside the token list. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [SECURITY] DoS attack on backend possible
[EMAIL PROTECTED] (Curt Sampson) wrote in
On Mon, 19 Aug 2002 [EMAIL PROTECTED] wrote:
$input = user'name;
INSERT INTO db (name) VALUES ('$input');
will fail because the ' in the input needs to be escaped with a
backslash.
It will fail because you're doing this a very, very, very bad way.
Why rewrite this kind of stuff when the vendor has already made
correct code available?
PreparedStatement stmt = connection.prepareStatement(
INSERT INTO db (name) VALUES (?));
stmt.setString(user'name);
stmt.execute();
cjs
Curt:
I am not doing it this way, I am trying to point out that doing it without
doing something (whether it be using preparedstatement or WHATEVER), is,
as you say, very very very bad (I am agreeing with you). I am further
saying that whatever it is you do, you should also be doing some other
simple validation, like the length of the inputs, because most inputs wont
be over 255 chars before being prepared. This is just an example, but you
should do whatever validation would apply to you (and this is probably true
coding for any user input whether it involves a db or not). I am just
saying this is good practice in my opinion and had these people that
brought up the issue in the first place were doing it, then pgsql's
shortcomings would not have been as severe a problem. Things I am not
saying are: its ok for pgsql to have this DoS problem; its the frontends
responsibility to maintain data integrity not the backend.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 20 Aug 2002, D'Arcy J.M. Cain wrote: On August 19, 2002 11:58 pm, Rod Taylor wrote: On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote: The simple fix is to drop the money type entirely as it serves few purposes -- but there are some who use it. As the original creator of the type I probably have the most emotional attachment to it but even I am thinking of dropping its use. I would have preferred to fix it (more automatic casts and 64 bit storage as well as the fixes in the current thread) but I seem to be alone so it hardly seems worth it. I still think that there is some benefit to being able to do integer arithmetic though. I know that I do a lot of calculations (mostly sums) on money and going to numeric is going to be a hit. No matter how efficient it is it can't be as efficient as a cpu register addition. But maybe I'm wrong and the hit will be negligible. I used to use the money tag but someone said it was going away in a future version and to use the numeric type instead. I was under the impression that it was going to be history long before now - it seems I was told this back in 6.3.something. 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 == ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Mon, Aug 19, 2002 at 22:35:26 -0700, Most computer virus problems are caused by buffer overrun. Someone decided it wasn't very important. I disaggree with this. Most computer viruses that I see are rely on poorly designed software and poorly trained users to propagate. Buffer overruns are used by worms and by some tools designed to get unauthorized access to machines. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Justin Clift wrote: Hi Mark, Mark Pritchard wrote: [...] Finally, question the due dilligence process that selects an ISP partner who would leave a database open to the world, even if they run unbreakable Oracle :) This is the one point of yours I don't feel you've quite got down pat. Err... *why* is it safe to leave a HTTP, SSH, IMAP, etc server open to the world (configured correctly of course), but somehow fundamentally wrong to leave a database server open to the world. If we've got a product without these bugs, there wouldnt be a security vulnerability would there? Because in every system I've seen so far, the application plays a major role in ensuring the data integrity by implementing at least part of the business logic. Referential integrity and all the stuff is nice to have and supports the application developer fighting against concurrency issues, very hard to solve on the application layer. But the decision if accountant Victor is permitted to cancel this payment for Hugo is still up to the application. If you say your users need direct DB access on the SQL interface level, I say trash your application because the data it produces isn't worth the magnetism on the media. It's not that we ugently need to fix such a bug that can only cause a DOS in case someone finds a way to hack through the application into the SQL interface. It's that the application has to be fixed not to allow that, because even if the server wouldn't be crashable, such a hack would end in a disaster. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Vince Vielhaber [EMAIL PROTECTED] writes: On Mon, 19 Aug 2002, Tom Lane wrote: I'd like to see something done about this fairly soon, but it's not happening for 7.3 ... Can we trap and just return an error before it goes into the weeds and put the subdividing opaque fix in later? I don't think there's any quick and dirty solution. One thing we could probably do in a relatively short amount of time, considering that we already have one pseudo-type in the system, is to go ahead and invent the C string pseudo-type and then change all the built-in I/O functions to be declared as taking or returning C string (as appropriate). We couldn't really do strong type checking on this yet, because we couldn't expect user-defined types' I/O functions to be declared correctly for awhile yet, but at least it would plug the hole for built-in types. What this needs is someone to do the legwork... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 2002-08-20 at 00:35, Dann Corbit wrote: Most computer virus problems are caused by buffer overrun. Someone decided it wasn't very important. This is true. IMO, it is extremely arrogant to ignore a buffer overrun and announce it can't be exploited. There is many cases where this assertion has been proved to be false. The real risk of overrun is not what you think can be done with it (or lack there of), rather, it's how someone else might decide to use it in some obscure manner which you can not currently fathom or foresee. Will you trust your multi-million dollar database to someone who says the above? I think the priorities are upside down. Any *known* buffer-overrun _must_ be repaired, and as quickly as possible. And I agree with that too. When setting priorities, using a scale of 1-10, 10 being highest priority, anything that effects stability or reliability should always be a 10. As such, they should always be repaired even above new wiz-bang features. IMO, if you don't embrace that rule of thumb, a developer shouldn't be working on a project where stability and reliability are key components of the end product. potential overruns should be identified. A grep for memcpy, strcpy, gets, etc. should hunt down most of them. A known buffer overrun should fill the designer of a product with abject terror. And I really mean Agreed. It is horribly irresponsible to thumb a nose at such things in this day and age. that, literally. If you *know* of a buffer overrun, and simply decide not to fix it, that sounds very negligent to me. For a public project like PostgreSQL, there is probably very little liability for the programmers, but I am thinking of the damage that can be inflicted upon potential clients using the database. Not a question of it sounding negligent. It is negligent. If quality and stability is not the core developers #1 goal then expecting people to trust the resulting product is laughable. Please tell me why anyone should use a database to maintain important data when quality and stability is not important to the developers of such a product. It's an oxymoron. Time and time again I've read what basically amounts to, ...if someone can crash it it's because someone is stupid enough to allow someone to be able to do it in the first place... Maybe you're right. After all, if core developers continue to turn a blind eye to such issues, they are in fact, the facilitators of allowing people to do it to begin with. That is, they are the ones that allowing people to do it in the first place. In short, every time I see that response, I immediately think, ...now that's the pot calling the kettle black. At some point in time, you have to stand and say, the buck stops here. Now then, after that long rant and rave, since these are known issues, I don't have a problem with the next release going out as planned. Once it does go out, I would certainly hope that the developers would readjust their priorities and target a bug fix release to immediately follow. You know, I've seen many people trash Oracle's unbreakable mantra. I'm sure no one is confused at the fact that it is nothing but a marketing ploy, however, perhaps there is a culture behind it. Perhaps this is their way of saying stability and reliability is very important to them. Perhaps their mantra is the rule of thumb outlined above. Sign, Greg Copeland signature.asc Description: This is a digitally signed message part
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Dann Corbit wrote: [...] What I am saying is that there is nothing that could possibly be more important than fixing this, except some other known problem that could also cause billions of dollars worth of damage. Are there any such problems besides the buffer overrun problems? And what others tried to tell you is, that there are different types of systems and levels of vulnerability. A software that by nature needs to be exposed to the internet (like an SMTP, HTTP or SSH server) is in high danger and needs to be fixed immediately. But software that by nature needs to be well protected from uncontrolled access (like a database, a backup management system or a logical volume manager) does not. The matter of the fact is, that if you grant someone access to your database that gives him the power to execute the statement that triggers this bug, you're lost anyway. Whatever constraints you have set up, an empty database is usually very consistent but not neccessarily useful. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(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 0x0001: Buffer overflow in
On Tue, 2002-08-20 at 08:05, Jan Wieck wrote: If you say your users need direct DB access on the SQL interface level, I say trash your application because the data it produces isn't worth the magnetism on the media. It's not that we ugently need to fix such a bug that can only cause a DOS in case someone finds a way to hack through the application into the SQL interface. It's that the application has to be fixed not to allow that, because even if the server wouldn't be crashable, such a hack would end in a disaster. The problem is, the vast majority of these issues are actually caused by internal resources (people) rather than external attacks. The real fear is internal resources DoSing internal resources. The reaction on the list is usually to look outward for sources of possible problems. That in it self is a problem. It's well documented the vast majority (what, 70+%) of these issues actually originate internally. It is because of these issues that it is often, no longer an issue of application this or that, as an application may of been completely bypassed. And yes, you can argue all day long that if this happens, you should be fearing destruction of your data. While that's true, data can be restored. It also requires a different personality type. Many people would be willing to DoS a system, however, that doesn't have to mean they are willing to destroy data. Regards, Greg Copeland signature.asc Description: This is a digitally signed message part
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Nigel J. Andrews [EMAIL PROTECTED] writes: I'd like to see something done about this fairly soon, but it's not happening for 7.3 ... Does anyone have an idea about what other functions are affected by this? As a first approximation, every output function for a built-in pass-by-reference datatype will show this same behavior. cash_out is just getting picked on because it was the one mentioned in the first complaint. For that matter, every input function for any datatype has the same problem: regression=# select cash_in(2); server closed the connection unexpectedly Let's see ... I count 264 standard pg_proc entries that are declared with one or more opaque parameters. Many but by no means all are I/O functions. There are another 13 standard functions declared to return opaque. To plug the hole in a credible fashion we'd need to do something about every one of these; so belay that last suggestion that just implementing a C string pseudo-type would be enough to be meaningful. Right offhand it looks like we'd need at least: C string for the I/O functions internal type for index access functions, selectivity, etc any array for array_eq and array_dims any type for count(*) (and not much else!) tuple for the return type of trigger functions void for the return type of things that return void not sure about encoding conversion functions The functions handling internal-type stuff are probably things we don't want the user calling at all. As long as we don't declare any of them to *return* an internal type, there would be no way to construct a function call that the parser would accept, so that hole would be plugged with just one pseudo-type; we don't really need to distinguish which internal type is meant in any one case. The any array pseudo-type would probably take a special-case kluge in parse_coerce, but that doesn't seem intolerable. Anyone see something I missed? Tatsuo, what exactly should the function signature really be for all those encoding conversion functions you just added? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 2002-08-20 at 08:22, D'Arcy J.M. Cain wrote: On August 19, 2002 11:58 pm, Rod Taylor wrote: On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote: The simple fix is to drop the money type entirely as it serves few purposes -- but there are some who use it. As the original creator of the type I probably have the most emotional attachment to it but even I am thinking of dropping its use. I would have preferred to fix it (more automatic casts and 64 bit storage as well as the But maybe I'm wrong and the hit will be negligible. It wouldn't fix this particular problem anyway :) -- so I'm going to vote to keep it. Though for my own work I've created a money domain due to lack of digits with the type -- not to mention I needed to store hundredths of a cent. ---(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] bison news
On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote: BTW, I spent some time looking at the problem, and it seems the issue is not overrun of any bison internal table, but failure to compress the resulting action table into 32K entries. This means that the required Ouch! This of course is not so much a problem for ecpg but for the backend should we run into the problem there too. ... Also, it seemed to me that the most leverage on the size of the compressed action table would be gained by reducing the number of terminal symbols, more so than the number of rules. Dunno if there is a lot you can do about that, but it's a thought. Will look at it. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bison news
Michael Meskes [EMAIL PROTECTED] writes: On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote: BTW, I spent some time looking at the problem, and it seems the issue is not overrun of any bison internal table, but failure to compress the resulting action table into 32K entries. This means that the required Ouch! This of course is not so much a problem for ecpg but for the backend should we run into the problem there too. As of CVS tip a few days ago, the backend's action table was about 27K entries. So we have some breathing room, but certainly in the foreseeable future there will be a problem... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SECURITY] DoS attack on backend possible
with Perl and *using placeholders and bind values*, the application developer has not to worry about this. So, usually I don't check the values in my applications (e.g. if only values between 1 and 5 are allowed and under normal circumstances only these are possible), it's the task of the database (check constraint). That's the idea. It's the job of the database to guarantee data integrety. Yes, but what is currently missing is a protocol to the backend where a statement is prepared with placeholders and then executed (multiple times) with given values. Then there is no doubt what is a value, and what a part of the SQL. I think that this would be a wanted feature of the next protocol version. iirc the backend side part is currently beeing implemented. Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Tatsuo Ishii [EMAIL PROTECTED] writes: Anyone see something I missed? Tatsuo, what exactly should the function signature really be for all those encoding conversion functions you just added? test=# \df iso8859_1_to_utf8 List of functions Result data type | Schema | Name| Argument data types --++---+- integer | pg_catalog | iso8859_1_to_utf8 | integer, integer, -, -, integer Right, that's what they are now, but what do the - entries really mean? Also, are the integer args and result truthful, or do they really mean something else? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 20 Aug 2002, Tom Lane wrote: Nigel J. Andrews [EMAIL PROTECTED] writes: I'd like to see something done about this fairly soon, but it's not happening for 7.3 ... Does anyone have an idea about what other functions are affected by this? As a first approximation, every output function for a built-in pass-by-reference datatype will show this same behavior. cash_out is just getting picked on because it was the one mentioned in the first complaint. For that matter, every input function for any datatype has the same problem: regression=# select cash_in(2); server closed the connection unexpectedly ... But going back to the idea that it seems that the only problem being publicised in the 'outside world' is the cash_out(2) version can we not do the restriction on acceptable input type in order to claim that the fix? Obviously this is only a marketing ploy but on the basis that a real fix seems unlikely before beta in 11 days time (I'm still trying to work out what Tom's suggestion is) perhaps one worth implementing. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants ---(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 0x0001: Buffer overflow in
Nigel J. Andrews [EMAIL PROTECTED] writes: But going back to the idea that it seems that the only problem being publicised in the 'outside world' is the cash_out(2) version can we not do the restriction on acceptable input type in order to claim that the fix? Totally pointless IMHO, when the same problem exists in hundreds of other functions. Also, there really is no way to patch cash_out per se; the problem is a system-level problem, namely failure to enforce type checking. cash_out has no way to know that what it's been passed is the wrong kind of datum. Basically, we've used opaque as a substitute for accurate type declarations; that's got to stop. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow
Tom Lane wrote: Nigel J. Andrews [EMAIL PROTECTED] writes: I'd like to see something done about this fairly soon, but it's not happening for 7.3 ... Does anyone have an idea about what other functions are affected by this? As a first approximation, every output function for a built-in pass-by-reference datatype will show this same behavior. cash_out is just getting picked on because it was the one mentioned in the first complaint. For that matter, every input function for any datatype has the same problem: regression=# select cash_in(2); server closed the connection unexpectedly Let's see ... I count 264 standard pg_proc entries that are declared with one or more opaque parameters. Many but by no means all are I/O functions. There are another 13 standard functions declared to return opaque. To plug the hole in a credible fashion we'd need to do something about every one of these; so belay that last suggestion that just implementing a C string pseudo-type would be enough to be meaningful. Is there ever a reason for a user to call a function with an opaque parameter directly? If not, can we simply REVOKE EXECUTE for these functions? Joe ---(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] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, Aug 20, 2002 at 11:28:32AM -0400, Tom Lane wrote: Nigel J. Andrews [EMAIL PROTECTED] writes: But going back to the idea that it seems that the only problem being publicised in the 'outside world' is the cash_out(2) version can we not do the restriction on acceptable input type in order to claim that the fix? Totally pointless IMHO, when the same problem exists in hundreds of other functions. Also, there really is no way to patch cash_out per se; the problem is a system-level problem, namely failure to enforce type checking. cash_out has no way to know that what it's been passed is the wrong kind of datum. Basically, we've used opaque as a substitute for accurate type declarations; that's got to stop. Hmm, are there _any_ cases where it's appropriate to call an 'opaque' function directly from user code? cash_out() and it's kin are type output functions that are called under controlled conditions, with backend controlled parameters. Trigger functions also are called with backend controlled parameters. Is there a 'hack' fix that doesn't allow opaque returning functions in user-defined locations? Ross ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tuesday 20 August 2002 11:28 am, Tom Lane wrote: Nigel J. Andrews [EMAIL PROTECTED] writes: But going back to the idea that it seems that the only problem being publicised in the 'outside world' is the cash_out(2) version can we not do the restriction on acceptable input type in order to claim that the fix? Basically, we've used opaque as a substitute for accurate type declarations; that's got to stop. Umm, but what about the reply buffer overrun advisory? I've read this whole thread, and the reply advisory (AFAICT, unless I've just hit delete too quickly) has NOT been addressed. Let's repeat the salient portion of Florian Weimer's message: PostgreSQL 7.2.1 has a buffer overflow bug in the date parser (which is invoked each time a string is converted to a datetime object). If a frontend does not perform proper date checking and rejects overlong date strings, a buffer is overwritten by parser. The string has to pass some checks of the parser, so it is not immediately obvious that this can be exploited. Denial of service is possible, though, especially if the frontend does not automatically reestablish the database connection. (All connections are affected, not just the one that is issueing the query.) In the DATE parser, not money. Not cash_out. Where do we stand on the DATE overrun, if one actually exists? If it exists, can it be exploited by a bad date entry on someone's web form or other client application? If it's not exploitable, then it lessens the impact -- but it is irresponsible to assume that just because we can't find a way to exploit it that no one else can. Now it's possible I just hit delete too quickly; but it's also possible that everyone has just assumed that this was the cash_out problem and has started hashing on that. Although this reply advisory hasn't been out as long as the original one, which WAS cash_words. If there is indeed an exploitable overrun in the DATE parser, then I believe we should issue a 7.2.2 to fix this problem. I know that MANY people will be using 7.2.x for quite awhile, as they won't want to make a MAJOR database upgrade (which is not painless thanks to the need to use 7.3's pg_dump for things). If the upgrade was painless, I'd agree that 7.3 is the solution -- but a real security fix shouldn't wait for 7.3. But I'm holding judgment on a proven exploit. A proven exploit will change my mind to say 'we need a 7.2.2 NOW that fixes this overrun.' -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Lamar Owen [EMAIL PROTECTED] writes: Umm, but what about the reply buffer overrun advisory? I've read this whole thread, and the reply advisory (AFAICT, unless I've just hit delete too quickly) has NOT been addressed. Yes it has. CVS logs show 2002-08-04 02:44 thomas * src/backend/utils/adt/: date.c, datetime.c, format_type.c, nabstime.c, timestamp.c, varlena.c: Add guard code to protect from buffer overruns on long date/time input strings. [other comments pruned, but note this commit did a lot of other stuff too] The original argument was about whether we should push out a 7.2.2 release just because of this fix. AFAIK no one has even troubled to look at the patch and see whether it applies directly to the 7.2 branch; Thomas has revised the date/time code quite a bit since 7.2, so I'd expect that it's not going to apply exactly. I'd put more stock in the concern level of the people making complaints if anyone had bothered to do even that much legwork. Without an offered patch against 7.2 branch, I don't think the folks who push out releases (which is not me, but Marc, Bruce, you, Trond, etc) should bother to take notice of the complaints at all. regards, tom lane ---(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] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tuesday 20 August 2002 12:15 pm, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: Umm, but what about the reply buffer overrun advisory? I've read this whole thread, and the reply advisory (AFAICT, unless I've just hit delete too quickly) has NOT been addressed. Yes it has. CVS logs show I'd put more stock in the concern level of the people making complaints if anyone had bothered to do even that much legwork. Without an offered patch against 7.2 branch, I don't think the folks who push out releases (which is not me, but Marc, Bruce, you, Trond, etc) should bother to take notice of the complaints at all. If a patch is proffered to 7.2.1 to fix this, I'll be happy to roll a new RPMset. I tend to agree with you on this detail, Tom. I had just apparently missed that portion; thanks for the reminder. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] [SECURITY] DoS attack on backend possible
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: Yes, but what is currently missing is a protocol to the backend where a statement is prepared with placeholders and then executed (multiple times) with given values. Then there is no doubt what is a value, and what a part of the SQL. This wouldn't have helped in the current case. The bug is in the datetime parser which translates strings to an external representation, not in the SQL parser. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 ---(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] Build failure in current CVS (src/backend/utils/mb/conversion_procs)
John Gray [EMAIL PROTECTED] writes: I get the following when I attempt to build outside of the source tree. It looks like the new stuff for loadable conversion modules is not correct for building outside the source tree; it's being careless about the paths it uses to find files. Tatsuo, can you fix that, or ask Peter for help? 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])
[HACKERS] Proposal: make opaque obsolete
Okay, I'm tired of hearing about this, and I've decided I can make the problem
go away with a day or so's concentrated work.
Here is the plan:
Create several pseudo types (typtype 'p' in pg_type). We already have one
pseudo-type (RECORD), plus the logic in heap.c to reject any attempt to create
a table column that's of a pseudo-type. I think we need the following
pseudotypes:
cstring -- represents a null-terminated C string
anytype -- for count(*), nullvalue, nonnullvalue *ONLY*
anyarraytype-- for array_eq, array_dims
void-- result type for functions with no useful result
tuple -- result type for BEFORE triggers
internal-- catchall for non-SQL internal data structures
I am not by any means wedded to the above type names; does anyone have
suggestions for better names? (In particular, I am wondering if tuple
and internal would be better named pg_tuple and pg_internal. We
might also consider making a type specifically named trigger and using
that to declare trigger functions, rather than tuple.)
I am also thinking of creating a pseudotype for opaque itself, so that
we can get rid of the kluge of using type OID 0 in places where a valid type
is expected. We cannot remove opaque completely (yet) because of backwards
compatibility with existing user I/O functions and triggers; but we can see
to it that no built-in or contrib function is declared with opaque.
About I/O behavior: the pg_type entries for these pseudo-types will have to
have typinput and typoutput functions. In general these I/O routines must
just throw errors. Otherwise you could break the intended type safety by
supplying user-written constants. For instance, the present definition of
RECORD is wrong (sorry Joe) because it uses oidin and oidout; so I could
write SELECT foo('42'::record) and thereby crash a function expecting
RECORD. Not that there will be any such function, but the analogous case
with, say, INTERNAL would be bad news.
An exception is that void_out should succeed and just return an empty string;
this allows functions-returning-void to be called by SELECT and behave
reasonably. Less obviously, void_in should succeed (and return nothing
interesting, probably just a zero datum; it can ignore its input). This
allows plpgsql functions to be defined to return VOID.
I am also considering allowing cstring_out to succeed (and, of course,
just return a copy of what it's given). That would allow explicit invocation
of an output function to work, viz SELECT cash_out('42'::money) would
actually do what the user expects. This is not really necessary though.
We can't allow cstring_in to succeed, although that looks like a no-brainer,
because the system isn't ready to support CSTRING Datums in general contexts.
Trigger functions will now be expected to take no arguments and return
either tuple (or trigger if we call it that) or opaque. It would also be
sensible to allow VOID in the case of AFTER triggers, but I'm inclined not
to do so: I think it's better that a trigger function be declared in a way
that makes it clear it's supposed to be a trigger. If CREATE TRIGGER accepts
functions returning void then I think you lose some useful error checking.
Should we throw a NOTICE stating that opaque is deprecated if a trigger
is declared with opaque? Or should we wait a release or two for that?
Similarly, the preferred signature for I/O functions now uses cstring
and the function's actual datatype, rather than OPAQUE (and again we
could consider throwing a NOTICE).
One of the original concerns about this was how to handle the circularity
problem for user-defined I/O functions. If we don't do anything special,
then it will still work as long as people define the input function first:
create function foo_in(cstring) returns foo as ' ... ';
-- you'll get a NOTICE here about type foo is not yet defined
create function foo_out(foo) returns cstring as '...';
-- you'll get another NOTICE here about foo is only a shell
create type foo (input = foo_in, output = foo_out, ...);
Are the notices annoying enough to be a problem? Is there a way around
them?
Currently, most of the PL languages explicitly check for type opaque as a
function argument or result type, and reject it. This should be generalized
to reject any pseudo-type except those explicitly supported (which will
probably be nothing except VOID).
Comments?
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])
Re: [HACKERS] Proposal: make opaque obsolete
anyarraytype-- for array_eq, array_dims Will this allow generic array iterator functions in the future? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal: make opaque obsolete
Rod Taylor [EMAIL PROTECTED] writes: anyarraytype -- for array_eq, array_dims Will this allow generic array iterator functions in the future? Hm. Not directly; there's still the issue of how to tell what element type the array is. array_dims doesn't care, and I think that we have some kluge for array_eq, but in general it'd be a problem for generic functions. I had been thinking that as long as we are going to break datafile compatibility (due to Manfred's tuple-header changes) this would be a good time to try to clean up the representation of arrays. It's bothered me for a long while that the array code is not doing alignment correctly --- it seems not to matter for any standard type, but arrays of, say, interval are not aligned the way pg_type says they should be. The reason I bring this up is that if we are changing the internal representation of arrays, we could add type OID and perhaps typmod to the array header, thus making an array value interpretable without any outside info. Then you could actually do something interesting with a function taking anyarraytype. 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])
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
The cash_out problem can't really be fixed until we do something about subdividing type opaque into multiple pseudo-types with more carefully defined meanings. cash_out is declared cash_out(opaque) which does not really mean that it accepts any input type ... but one of the several meanings of opaque is accepts any type, so the parser doesn't reject cash_out(2). Would it be possible to update the system tables, so that cash_out does not take opaque but really takes type money ? I mean the first thing cash_out does is PG_GETARG_CASH(0), so it really only copes with a money type. I know the problem is that the cat chases its tail here, because of what comes first, the type or the io functions. But couldn't this be overcome, at least for internal types ? Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CREATE CAST WITHOUT FUNCTION should require superuserness?
Tom Lane writes: I think it might be a good idea to require superuser permissions to create a binary-equivalence cast. OK Also, in the present state of the code a WITHOUT FUNCTION cast does not work if AS ASSIGNMENT isn't given: parse_coerce.c won't ever find it. Is this intentional, or just an oversight? It's a transition state that might be inadequately documented. In the near future the code should be restructured to allow for non-implicit binary compatible casts. But currently there are not candidates for that anyway. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proposal: make opaque obsolete
On Tue, 20 Aug 2002, Tom Lane wrote:
In general I think it sounds good, so I'm only responding to places where
I want to say something specific.
I am not by any means wedded to the above type names; does anyone have
suggestions for better names? (In particular, I am wondering if tuple
and internal would be better named pg_tuple and pg_internal. We
might also consider making a type specifically named trigger and using
that to declare trigger functions, rather than tuple.)
I like something with trigger better, makes it very obvious that it's a
trigger function.
An exception is that void_out should succeed and just return an empty string;
this allows functions-returning-void to be called by SELECT and behave
reasonably. Less obviously, void_in should succeed (and return nothing
interesting, probably just a zero datum; it can ignore its input). This
allows plpgsql functions to be defined to return VOID.
Does this require additional work to the plpgsql grammar? The
natural way to return from such a function (return;) doesn't seem like
it'd work without some changes. In any case I don't think this would
be necessary for 7.3.
I am also considering allowing cstring_out to succeed (and, of course,
just return a copy of what it's given). That would allow explicit invocation
of an output function to work, viz SELECT cash_out('42'::money) would
actually do what the user expects. This is not really necessary though.
I like the idea of cstring_out working, but I wonder if we should stop
users from calling the I/O functions directly anyway even if they were
made to be safe.
Should we throw a NOTICE stating that opaque is deprecated if a trigger
is declared with opaque? Or should we wait a release or two for that?
Similarly, the preferred signature for I/O functions now uses cstring
and the function's actual datatype, rather than OPAQUE (and again we
could consider throwing a NOTICE).
I think we should throw the notices right away, although this makes me
wonder in general about upgrade path. Are we ever planning to make that
an error, and if so, how are we going to handle functions that are coming
from previous versions where it was okay? It's relatively easy to do fix
ones that are currently used as trigger functions or type i/o functions,
but what about ones that aren't being used at dump time? Do we even need
to do anything?
One of the original concerns about this was how to handle the circularity
problem for user-defined I/O functions. If we don't do anything special,
then it will still work as long as people define the input function first:
create function foo_in(cstring) returns foo as ' ... ';
-- you'll get a NOTICE here about type foo is not yet defined
create function foo_out(foo) returns cstring as '...';
-- you'll get another NOTICE here about foo is only a shell
create type foo (input = foo_in, output = foo_out, ...);
Are the notices annoying enough to be a problem? Is there a way around
them?
I personally don't think it's a big deal, although I'm alot less annoyed
by notices than alot of people.
---(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] Proposal: make opaque obsolete
Stephan Szabo [EMAIL PROTECTED] writes: On Tue, 20 Aug 2002, Tom Lane wrote: Less obviously, void_in should succeed (and return nothing interesting, probably just a zero datum; it can ignore its input). This allows plpgsql functions to be defined to return VOID. Does this require additional work to the plpgsql grammar? I suspect you'd need to say return 0 (or return anything-at-all, pretty much) to make it fly with the current plpgsql sources. This is a tad ugly but I think we can live with it until someone wants to fix it. If we have type void then for sure people will want to use it for plpgsql functions; there are plenty of cases where you run a plpgsql function just for side-effects. I think we should throw the notices right away, although this makes me wonder in general about upgrade path. Are we ever planning to make that an error, and if so, how are we going to handle functions that are coming from previous versions where it was okay? We can't make it an error until sufficiently far down the road that we don't care about forward compatibility from 7.2-or-before dump files. That'll be a long while, probably. Throwing a notice right away is okay with me personally, but I wanted to see what other people thought... regards, tom lane ---(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] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL(fwd)
Here's yet another. He claims malicious code can be run on the server
with this one.
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
==
-- Forwarded message --
Date: Tue, 20 Aug 2002 14:28:49 +
From: Sir Mordred The Traitor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL
//@(#)Mordred Labs advisory 0x0003
Release data: 20/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: all versions
Risk: high
--[ Description:
...PostgreSQL is a sophisticated Object-Relational DBMS,
supporting almost all SQL constructs, including subselects,
transactions, and user-defined types and functions. It is the
most advanced open-source database available anywhere...blah...blah...
For more info check out this link:
http://www.postgresql.org/idocs/index.php?preface.html#INTRO-WHATIS
There exists a heap buffer overflow in a repeat(text, integer) function,
which
allows an attacker to execute malicious code.
--[ Details:
Upon invoking a repeat() function, a
src/backend/utils/adt/oracle_compat.c::repeat() function
will gets called which suffers from a buffer overflow.
--[ How to reproduce:
psql select repeat('xxx',1431655765);
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
Do you still running postgresql? ...Can't believe that...
If so, execute the following command as a root: killall -9 postmaster,
and wait until the patch will be available.
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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Vince Vielhaber [EMAIL PROTECTED] writes:
Here's yet another. He claims malicious code can be run on the server
with this one.
regression=# select repeat('xxx',1431655765);
server closed the connection unexpectedly
This is probably caused by integer overflow in calculating the size of
the repeat's result buffer. It'd take some considerable doing to create
an arbitrary-code exploit, but perhaps could be done. Anyone want to
investigate a patch? I think we likely need something like
bufsize = input_length * repeats;
+ /* check for overflow in multiplication */
+ if (bufsize / repeats != input_length)
+ elog(ERROR, repeat result too long);
but I haven't thought it through in detail.
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])
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
On Tue, 20 Aug 2002, Tom Lane wrote:
Vince Vielhaber [EMAIL PROTECTED] writes:
Here's yet another. He claims malicious code can be run on the server
with this one.
regression=# select repeat('xxx',1431655765);
server closed the connection unexpectedly
This is probably caused by integer overflow in calculating the size of
the repeat's result buffer. It'd take some considerable doing to create
an arbitrary-code exploit, but perhaps could be done. Anyone want to
investigate a patch? I think we likely need something like
bufsize = input_length * repeats;
+ /* check for overflow in multiplication */
+ if (bufsize / repeats != input_length)
+ elog(ERROR, repeat result too long);
but I haven't thought it through in detail.
Where do we check that this:
result = (text *) palloc(tlen);
is even successful? Is it in one of the macros (VARATT_SIZEP or VARDATA)?
It appears like it goes into the count and copy regardless.
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
==
---(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 0x0003: Buffer overflow in PostgreSQL (fwd)
Vince Vielhaber [EMAIL PROTECTED] writes: Where do we check that this: result = (text *) palloc(tlen); is even successful? palloc elogs if it can't allocate the space; it's unlike malloc in that respect. I believe it also has a guard to reject requests 1Gb, so I think it's reasonably proof against internal arithmetic overflows. This problem is strictly repeat's error, not palloc's. 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])
[HACKERS] SRA purchases TurboLinux
SRA/Japan, my employer and a big PostgreSQL support company in Japan, has announced they have purchased TurboLinux: http://www.turbolinux.com/news/pr/020820.html Here is a summary from someone on Slashdot: * Turbolinux Inc. sold Turbolinux Japan K.K. (its Japanese subsidary) to SRA. (This is the $1 mil. transaction according to Slashdot Japan [slashdot.jp] (in Japanese)) * Turbolinux Japan K.K. will become the new Turbolinux Inc. * Turbolinux Inc. also sold all its Linux distribution business, logo, trademarks to SRA, but the price is not yet disclosed. * SRA is also planning to buy the Chinese and Korean joint ventures between Turbolinux Inc. and local companies. * The old Turbolinux Inc. will change its name to CenterRex and focus on software it developed like PowerCockpit or EnFusion. Not sure how this effects PostgreSQL usage, but it certainly could. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Large file support available
Large file support is now compiled by default if available. (Use --disable-largefile to turn it off. That's what Autoconf gives us.) But: The zlib library uses unsigned ints and unsigned longs for file positions and offsets. Depending on how that is used in detail and depending on how zlib itself is compiled, this may or may not work. The tar file format (POSIX and traditional) has an inherent limitation on the size of the member files of 2^33 bytes (pg_dump currently only handles 2^30). The result in that case continues to be a broken archive. The GNU tar format has an extension that would handle 2^89 bytes. This may be something interesting to work on. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Tom Lane [EMAIL PROTECTED] writes:
Vince Vielhaber [EMAIL PROTECTED] writes:
Here's yet another. He claims malicious code can be run on the server
with this one.
regression=# select repeat('xxx',1431655765);
server closed the connection unexpectedly
This is probably caused by integer overflow in calculating the size of
the repeat's result buffer. It'd take some considerable doing to create
an arbitrary-code exploit, but perhaps could be done. Anyone want to
investigate a patch?
This seems to fix the problem:
nconway=# select repeat('xxx',1431655765);
ERROR: Requested buffer is too large.
It uses the logic you suggested. Just a quick and dirty fix, I may
have missed something... The patch applies cleanly to both CVS HEAD
and the 7.2 stable branch.
Cheers,
Neil
--
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC
Index: src/backend/utils/adt/oracle_compat.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/adt/oracle_compat.c,v
retrieving revision 1.38
diff -c -r1.38 oracle_compat.c
*** src/backend/utils/adt/oracle_compat.c 20 Jun 2002 20:51:45 - 1.38
--- src/backend/utils/adt/oracle_compat.c 20 Aug 2002 20:27:21 -
***
*** 997,1002
--- 997,1006
slen = (VARSIZE(string) - VARHDRSZ);
tlen = (VARHDRSZ + (count * slen));
+ /* Check for integer overflow */
+ if (tlen / slen != count)
+ elog(ERROR, Requested buffer is too large.);
+
result = (text *) palloc(tlen);
VARATT_SIZEP(result) = tlen;
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Neil Conway [EMAIL PROTECTED] writes: + /* Check for integer overflow */ + if (tlen / slen != count) + elog(ERROR, Requested buffer is too large.); What about slen == 0? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Vince Vielhaber [EMAIL PROTECTED] writes: Here's yet another. Should someone from the core team perhaps get in contact with this guy and ask if he could get in contact with the development team before publicizing any further security holes? AFAIK that is standard operating procedure in most cases... Second, it might be worth pushing a 7.2.2 release containing the fix for this bug, as well as the datetime problem. If that sounds reasonable to the people who have to do the most work on a new release (e.g. Marc), I can volunteer to backport a fix for the datetime problem. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows inPostgreSQL. (fwd)
And another one. Sure would be nice if shit-for-brains would mention
it to us first.
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
==
-- Forwarded message --
Date: Tue, 20 Aug 2002 15:01:34 +
From: Sir Mordred The Traitor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in
PostgreSQL.
//@(#) Mordred Labs advisory 0x0004
Release data: 20/08/02
Name: Two buffer overflows in PostgreSQL
Versions affected: all versions
Conditions: multibyte support
Risk: average
--[ Description:
I guess all of you already hear about the PostgreSQL.
If not, try to visit
http://www.postgresql.org/idocs/index.php?preface.html#INTRO-WHATIS.
There are two buffer overflows in src/backend/utils/adt/oracle_compat.c.
1) lpad(text, integer, text) function
2) rpad(text, integer, text) function
--[ Details:
The code for this functions is
src/backend/utils/adt/oracle_compat.c::lpad() and
src/backend/utils/adt/oracle_compat.c::rpad() respectively.
The code suffers from a buffer overflow (of course).
--[ How to reproduce:
shell pgsql template1 postgres
template1=# select version();
version
---
PostgreSQL 7.2 on i686-pc-linux-gnu, compiled by GCC 2.96
(1 row)
template1=# create database my_db with encoding='UNICODE';
CREATE DATABASE
template1# \c my_db
You are now connected to database my_db.
my_db=# select lpad('x',1431655765,'');
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.
!#
The same for rpad() function.
The vulnerable encodings are: EUC_JP, EUC_CN, EUC_KR, EUC_TW, UNICODE,
MULE_INTERNAL.
--[ Solution
Secure coding of web applications, input validation checks...etc...
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
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
-Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 20, 2002 1:44 PM To: Vince Vielhaber Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd) Vince Vielhaber [EMAIL PROTECTED] writes: Here's yet another. Should someone from the core team perhaps get in contact with this guy and ask if he could get in contact with the development team before publicizing any further security holes? AFAIK that is standard operating procedure in most cases... As long as we continue to find out about them, I would just let him work away. He is clearly an excellent tester, and if you had to hire him it would be very expensive. As long as he is producing results of such great value, I think it is wonderful. Second, it might be worth pushing a 7.2.2 release containing the fix for this bug, as well as the datetime problem. If that sounds reasonable to the people who have to do the most work on a new release (e.g. Marc), I can volunteer to backport a fix for the datetime problem. Bugs that cause a catastrophic error (e.g. crash of the database engine, causing loss of data) should have the highest priority. Call them category zero. Bugs that cause incorrect results should have the next highest priority. Call them category one. Bugs that are minor annoyances (e.g. appearance such as a misspelled word in a help file) should be low priority. Bugs that are only suggestions for improvements should have the lowest priority. All known category zero and one bugs should be fixed before each and every new release. IMO-YMMV. ---(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] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
On 20 Aug 2002, Neil Conway wrote: Vince Vielhaber [EMAIL PROTECTED] writes: Here's yet another. Should someone from the core team perhaps get in contact with this guy and ask if he could get in contact with the development team before publicizing any further security holes? AFAIK that is standard operating procedure in most cases... I just asked him/her that on bugtraq. 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 == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows inPostgreSQL. (fwd)
-Original Message- From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 20, 2002 1:48 PM To: [EMAIL PROTECTED] Subject: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows inPostgreSQL. (fwd) And another one. Sure would be nice if shit-for-brains would mention it to us first. It looks to me like he may be the most valuable tester on the staff. As long as we find out what the problem is, why complain? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Tom Lane [EMAIL PROTECTED] writes: Neil Conway [EMAIL PROTECTED] writes: + /* Check for integer overflow */ + if (tlen / slen != count) + elog(ERROR, Requested buffer is too large.); What about slen == 0? Good point -- that wouldn't cause incorrect results or a security problem, but it would reject input that we should really accept. Revised patch is attached. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC Index: src/backend/utils/adt/oracle_compat.c === RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/adt/oracle_compat.c,v retrieving revision 1.38 diff -c -r1.38 oracle_compat.c *** src/backend/utils/adt/oracle_compat.c 20 Jun 2002 20:51:45 - 1.38 --- src/backend/utils/adt/oracle_compat.c 20 Aug 2002 20:51:20 - *** *** 997,1002 --- 997,1006 slen = (VARSIZE(string) - VARHDRSZ); tlen = (VARHDRSZ + (count * slen)); + /* Check for integer overflow */ + if (slen != 0 count != 0 tlen / slen != count) + elog(ERROR, Requested buffer is too large.); + result = (text *) palloc(tlen); VARATT_SIZEP(result) = tlen; ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows inPostgreSQL. (fwd)
-Original Message- From: Frank Wiles [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 20, 2002 1:57 PM To: Dann Corbit Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows inPostgreSQL. (fwd) .--[ Dann Corbit wrote (2002/08/20 at 13:54:53) ]-- | | From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] | Sent: Tuesday, August 20, 2002 1:48 PM | To: [EMAIL PROTECTED] | Subject: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple | buffer overflows inPostgreSQL. (fwd) | | | | And another one. Sure would be nice if shit-for-brains would | mention it to us first. | | It looks to me like he may be the most valuable tester on the staff. | As long as we find out what the problem is, why complain? | `- The reason to complain is that he is not notifying the development team before hand. Giving them absolutely no chance to work on a fix prior to the whole world freaking out over these bugs. If I was your neighbor, and I noticed your front door was open I would contact you and let you know... not take out a full page ad in the local news paper! Same idea applies here. :) Also, if I'm not mistaken this guy isn't on staff. Well, of course, a well mannered team member would report the bugs through one of the normal channels. On the other hand, a malicious tester who finds these problems performs two valuable services: 1. Through great effort, he has found a problem that needs to be addressed or serious consequences will result. 2. He has raised a large public rancor. The result of which is that the serious problem must be addressed. The motivation is suspect. The character is suspect. But the result is of great value. In a similar manner, it is a common practice to hire hackers to try to break into your site. While their methods will be unconventional, and they can be very seedy and immoral characters, they will reveal information of great value to show you exactly where the hole needs to be plugged. ---(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] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)
Vince Vielhaber [EMAIL PROTECTED] writes: And another one. Sure would be nice if shit-for-brains would mention it to us first. I don't even mind the first part, but it would certainly be polite of him to cc: pghackers rather than expecting us to dig it off bugtraq. But, as someone else pointed out, he's not doing this for our benefit, it's to make himself look good. The only audience he cares about is bugtraq, I suspect. regards, tom lane ---(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] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows inPostgreSQL. (fwd)
.--[ Dann Corbit wrote (2002/08/20 at 14:05:37) ]-- | | ... [large snip] ... | | Well, of course, a well mannered team member would report the bugs | through one of the normal channels. | On the other hand, a malicious tester who finds these problems performs | two valuable services: | 1. Through great effort, he has found a problem that needs to be | addressed or serious consequences will result. | | ... [small snip] ... | `- Reading the TODO list is great effort? What puzzles me most is that you speak as if you have personal knowledge of how much effort it took. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - ---(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 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)
Vince Vielhaber [EMAIL PROTECTED] writes:
And another one.
This patch should fix the problem. Doesn't include my previous patch
for repeat(). Again, somewhat off-the-cuff, so I might have missed
something...
test=# select lpad('x',1431655765,'');
ERROR: Requested length too large
test=# select rpad('x',1431655765,'');
ERROR: Requested length too large
(That's on a Unicode DB, haven't tested other encodings but AFAICT
this fix should still work.)
Cheers,
Neil
--
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC
Index: src/backend/utils/adt/oracle_compat.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/adt/oracle_compat.c,v
retrieving revision 1.38
diff -c -r1.38 oracle_compat.c
*** src/backend/utils/adt/oracle_compat.c 20 Jun 2002 20:51:45 - 1.38
--- src/backend/utils/adt/oracle_compat.c 20 Aug 2002 21:04:07 -
***
*** 199,204
--- 199,209
#ifdef MULTIBYTE
bytelen = pg_database_encoding_max_length() * len;
+
+ /* check for integer overflow */
+ if (len != 0 bytelen / pg_database_encoding_max_length() != len)
+ elog(ERROR, Requested length too large);
+
ret = (text *) palloc(VARHDRSZ + bytelen);
#else
ret = (text *) palloc(VARHDRSZ + len);
***
*** 310,315
--- 315,325
#ifdef MULTIBYTE
bytelen = pg_database_encoding_max_length() * len;
+
+ /* Check for integer overflow */
+ if (len != 0 bytelen / pg_database_encoding_max_length() != len)
+ elog(ERROR, Requested length too large);
+
ret = (text *) palloc(VARHDRSZ + bytelen);
#else
ret = (text *) palloc(VARHDRSZ + len);
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer
On 20 Aug 2002, Neil Conway wrote:
Vince Vielhaber [EMAIL PROTECTED] writes:
And another one.
This patch should fix the problem. Doesn't include my previous patch
for repeat(). Again, somewhat off-the-cuff, so I might have missed
something...
test=# select lpad('x',1431655765,'');
ERROR: Requested length too large
test=# select rpad('x',1431655765,'');
ERROR: Requested length too large
(That's on a Unicode DB, haven't tested other encodings but AFAICT
this fix should still work.)
Is there any chance that pg_database_encoding_max_length() could return
zero and give a divide by zero error? Or is that trapped?
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
==
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)
Vince Vielhaber [EMAIL PROTECTED] writes: On 20 Aug 2002, Neil Conway wrote: Is there any chance that pg_database_encoding_max_length() could return zero and give a divide by zero error? Or is that trapped? I don't think so (the array of encodings that contains the data seems to be pre-defined), but I know next to nothing about multibyte, so I may be wrong. In any case, the divide by zero error would cause an elog(ERROR) anyway, not a segfault... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Multiple vulnerabilities in PostgreSQL
Hi Mordred, Thanks for doing this testing for vulnerabilities for us. Some PostgreSQL team members have been looking to organise an audit team to remove vulnerabilities like this, and your posts to BugTraq have assisted in getting that further mobilised. Something that is concerning us though, is that whilst one of these bugs was known and on our to fix list, there are some that were not known and you're not notifying us up front so we can fix them before details are publicly released. Would you be able to work in with us from here, notifying us of these vulnerabilities with some decent amount of time in advance so we can create the necessary patches/fixes, etc? :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(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] [BUGS] Long strings, short varchars
Tom Lane writes: In any case we need to distinguish implicit coercion for a store from explicit coercion. Do your recent pg_cast changes make that any easier? Possibly we could allow for registering both implicit and explicit cast functions for the same combination. Or we could make cast functions take an optional second argument that tells whether the cast is implicit or explicit. We probably also need to take into account the typemod coercion functions that are currently handled in a semi-internal way. (Any formalization of those should probably consider the possibility of allowing typemods on arbitrary types.) Not sure which way to go. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CREATE CAST WITHOUT FUNCTION should require superuserness?
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Also, in the present state of the code a WITHOUT FUNCTION cast does not work if AS ASSIGNMENT isn't given: parse_coerce.c won't ever find it. Is this intentional, or just an oversight? It's a transition state that might be inadequately documented. Okay. Are you intending to work on it? I was thinking of doing some cleanup work in parse_coerce, but will refrain from joggling your elbow if you're going to deal with it. regards, tom lane ---(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] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: Would it be possible to update the system tables, so that cash_out does not take opaque but really takes type money ? That is part of the solution, but only part: we have hundreds of functions that take opaque because we don't currently have any way to declare what they really take. (In particular, all the typinput functions are like that --- so fixing typoutput functions isn't plugging even half of the gap.) See my proposal to make opaque obsolete. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Large file support available
Peter Eisentraut [EMAIL PROTECTED] writes: Large file support is now compiled by default if available. I am now getting (on HPUX 10.20) /usr/include/sys/resource.h: In function `getrlimit': /usr/include/sys/resource.h:168: warning: implicit declaration of function `__getrlimit64' /usr/include/sys/resource.h: In function `setrlimit': /usr/include/sys/resource.h:170: warning: implicit declaration of function `__setrlimit64' for essentially every file in the system. A little digging shows that this is happening because _FILE64 is defined and _LARGEFILE64_SOURCE is not; this is evidently a Bad Idea on HPUX. Further digging shows that noplace in the standard headers is _LARGEFILE64_SOURCE #define'd, so evidently one is supposed to supply it from user headers. Ugh. Please add this to the list of platform-specific symbols that had better be turned on to support large files. regards, tom lane ---(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] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: Would it be possible to update the system tables, so that cash_out does not take opaque but really takes type money ? That is part of the solution, but only part: we have hundreds of functions that take opaque because we don't currently have any way to declare what they really take. So the idea is, that input functions take cstring type, and output functions take the explicit type they are designed for ? Is there anything that can be done vs that types only exist after the functions ? e.g. create it in one tx with constraints deferred ? Or is that no issue ? (In particular, all the typinput functions are like that --- so fixing typoutput functions isn't plugging even half of the gap.) See my proposal to make opaque obsolete. Yes, it is great that you will look into this !! About the names, would it be good to use SQL99 reserved words ? (e.g. ROW for tuple) nice url: http://developer.mimer.se/validator/sql-reserved-words.tml count(*)-- anynumeric :-) (two flies with one strike) NULL/NONNULL-- null|nullvalue|anynull ? We only need this internally, no ? Hard to say what is good for those names imho, don't like anytype :-( (maybe even leave that opaque for now) I like cstring, void and internal. Maybe anyarray instead of anyarraytype. And I would prefer row instead of tuple. Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Large file support available
Also, even with configure --disable-largefile, I find that pg_config.h still contains /* Define to 1 to make fseeko visible on some hosts. */ #define _LARGEFILE_SOURCE 1 /* Define to 1 if fseeko (and presumably ftello) exists and is declared. */ #define HAVE_FSEEKO 1 This strikes me as probably Not a Good Thing, although I haven't dug to see what the implications are. regards, tom lane ---(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] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: Hard to say what is good for those names imho, don't like anytype :-( How about any? It's a reserved word per SQL99, I think. I like cstring, void and internal. Okay. Maybe anyarray instead of anyarraytype. That would match with any. And I would prefer row instead of tuple. I'm leaning towards agreeing with Stephan: we should use typename trigger to declare triggers. Tuple (or row) is strictly correct only for BEFORE triggers, not AFTER triggers, so it's a bit of a misnomer for triggers anyhow. I'm now also toying with inventing a pseudotype just for procedural language handlers, which are currently foo() returns opaque. If we want the type system to catch misuses of trigger functions, we should want it for handlers too. Maybe name this type language_handler? (I had thought we could declare handlers to return internal, but we can't do that without breaking type safety. We don't want *any* way for an SQL construct to look like it returns type internal.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: Hard to say what is good for those names imho, don't like anytype :-( How about any? It's a reserved word per SQL99, I think. I would actually stick to opaque in that case, already used in other db's. I like cstring, void and internal. Okay. Maybe anyarray instead of anyarraytype. That would match with any. I thought you wanted it separate ? And I would prefer row instead of tuple. I'm leaning towards agreeing with Stephan: we should use typename trigger to declare triggers. Tuple (or row) is strictly correct only for BEFORE triggers, not AFTER triggers, so it's a bit of a misnomer for triggers anyhow. Convinced. I'm now also toying with inventing a pseudotype just for procedural language handlers, which are currently foo() returns opaque. If we want the type system to catch misuses of trigger functions, we should want it for handlers too. Maybe name this type language_handler? HANDLER would again already be a reserved word, sounds good. Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: Hard to say what is good for those names imho, don't like anytype :-( How about any? It's a reserved word per SQL99, I think. I would actually stick to opaque in that case, already used in other db's. I want to change the name because (a) we are changing the semantics, (b) we can't throw notices for opaque if we keep it as a valid choice. Maybe anyarray instead of anyarraytype. That would match with any. I thought you wanted it separate ? I meant that if the one name is any, then making the other anyarray (ie, both without type on the end) is consistent. regards, tom lane ---(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] bison news
OK, now that _a_ bison exists that works, how does this effect our release? I don't see preproc.[ch] in CVS. Do we need this new bison version on postgresql.org because Marc generates these as part of his install script? --- Tom Lane wrote: Michael Meskes [EMAIL PROTECTED] writes: On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote: BTW, I spent some time looking at the problem, and it seems the issue is not overrun of any bison internal table, but failure to compress the resulting action table into 32K entries. This means that the required Ouch! This of course is not so much a problem for ecpg but for the backend should we run into the problem there too. As of CVS tip a few days ago, the backend's action table was about 27K entries. So we have some breathing room, but certainly in the foreseeable future there will be a problem... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
[EMAIL PROTECTED] (Greg Copeland) wrote Time and time again I've read what basically amounts to, ...if someone can crash it it's because someone is stupid enough to allow someone to be able to do it in the first place... Maybe you're right. After all, if core developers continue to turn a blind eye to such issues, they are in fact, the facilitators of allowing people to do it to begin with.=20 That is, they are the ones that allowing people to do it in the first place. In short, every time I see that response, I immediately think, ...now that's the pot calling the kettle black. At some point in time, you have to stand and say, the buck stops here. I agree here, but at the same time you cannot put 100% of the responsibility on the developers. If you are the dba/sysadmin/whatever/etc then it is your responsibility. It is up to you to know about potential problems and have workarounds or whatever it is you need to do. I think that is one of the things that seperates a good admin from a not-so- good one. Afterall, when your boss calls you into his office monday morning and asks for a really good explanation for why the db was cracked, I dont think he is going to accept the excuse this guy, you dont know him but his name is tom lane.. well anyway, he didnt fix this bug i knew about so i didnt do nothing about it because i shouldnt have to because that would be like the pot calling the kettle black That being said, I do agree the developers should give things like this more priority. But, its open source... so you either live with it or write your own patch. ---(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] Proposal: make opaque obsolete
Tom Lane wrote: I think we should throw the notices right away, although this makes me wonder in general about upgrade path. Are we ever planning to make that an error, and if so, how are we going to handle functions that are coming from previous versions where it was okay? We can't make it an error until sufficiently far down the road that we don't care about forward compatibility from 7.2-or-before dump files. That'll be a long while, probably. Throwing a notice right away is okay with me personally, but I wanted to see what other people thought... NOTICE seems good. We will have all this mentioned in the release notes too. In fact, we can point to the release notes in the NOTICE if desired. I like the array storage format change too. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Hard to say what is good for those names imho, don't like anytype :-( How about any? It's a reserved word per SQL99, I think. I would actually stick to opaque in that case, already used in other db's. I want to change the name because (a) we are changing the semantics, (b) we can't throw notices for opaque if we keep it as a valid choice. Hmm, any would sound like it is the same as opaque. Would any really be all allowed types ? I think we would want to eliminate that altogether. If it is not all types I would rather use a more restrictive name (nulltype / anynumeric). Imho opaque is missing a runtime type info, like a descriptor, and thus only pass by value could not be allowed anymore. I guess I must sleep over this, not convinced about depricating opaque yet :-) I meant that if the one name is any, then making the other anyarray (ie, both without type on the end) is consistent. Ah, good. Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 2002-08-20 at 16:46, Zeugswetter Andreas SB SD wrote: Hard to say what is good for those names imho, don't like anytype :-( How about any? It's a reserved word per SQL99, I think. I would actually stick to opaque in that case, already used in other db's. I want to change the name because (a) we are changing the semantics, (b) we can't throw notices for opaque if we keep it as a valid choice. Hmm, any would sound like it is the same as opaque. Would any really be all allowed types ? I think we would want to eliminate that altogether. Erm.. count(*) - * is literally anything. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL
Vince Vielhaber wrote: Here's yet another. He claims malicious code can be run on the server with this one. --[ Solution Do you still running postgresql? ...Can't believe that... If so, execute the following command as a root: killall -9 postmaster, and wait until the patch will be available. You've got to love this last part. ;-) This has the attitude of Oh, look at me, I found a bug. Let me publicize it and get more attention. Aren't you proud of me? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] pgstattuple change using SRF
I'm going to change contrib/pgstattuple so that it returns a tuple rather than a NOTICE using new SRF interface. I believe this way is much more convenient for users. Any objection? -- Tatsuo Ishii ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL
Dann Corbit wrote: -Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 20, 2002 1:44 PM To: Vince Vielhaber Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd) Vince Vielhaber [EMAIL PROTECTED] writes: Here's yet another. Should someone from the core team perhaps get in contact with this guy and ask if he could get in contact with the development team before publicizing any further security holes? AFAIK that is standard operating procedure in most cases... As long as we continue to find out about them, I would just let him work away. He is clearly an excellent tester, and if you had to hire him it would be very expensive. As long as he is producing results of such great value, I think it is wonderful. Yea, someone please contact him and tell him to keep going. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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 0x0001: Buffer overflow in
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: Hmm, any would sound like it is the same as opaque. Would any really be all allowed types ? I think we would want to eliminate that altogether. Do you plan on eliminating the COUNT() aggregate, then? Imho opaque is missing a runtime type info, like a descriptor, and thus only pass by value could not be allowed anymore. AFAICS it's only useful for functions that only care whether their argument is NULL or not, and don't inspect its value. But that just happens to describe COUNT, as well as nullvalue/nonnullvalue. I don't really think that using ANY instead of OPAQUE for this purpose will affect users, because they will never be declaring any functions that would legitimately take ANY, much less return ANY (the latter probably makes no sense at all). It seems to me that COUNT, nullvalue, and nonnullvalue pretty much cover the spectrum of what you can usefully do with only an isnull bit to look at... 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])
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
This is all an indication of our increasing usage. Several PostgreSQL articles have appeared in the past week in _major_ media outlets, not just the open-source press (eweek, Bloomburg), a major PostgreSQL support company bought a Linux distribution (SRA-Turbolinux), and we have independent projects auditing our code. It is only going to get worse. ;-) --- Vince Vielhaber wrote: On 20 Aug 2002, Neil Conway wrote: Vince Vielhaber [EMAIL PROTECTED] writes: Here's yet another. Should someone from the core team perhaps get in contact with this guy and ask if he could get in contact with the development team before publicizing any further security holes? AFAIK that is standard operating procedure in most cases... I just asked him/her that on bugtraq. 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 == ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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] Proposal: make opaque obsolete
Tom Lane wrote:
About I/O behavior: the pg_type entries for these pseudo-types will have to
have typinput and typoutput functions. In general these I/O routines must
just throw errors. Otherwise you could break the intended type safety by
supplying user-written constants. For instance, the present definition of
RECORD is wrong (sorry Joe) because it uses oidin and oidout; so I could
write SELECT foo('42'::record) and thereby crash a function expecting
RECORD. Not that there will be any such function, but the analogous case
with, say, INTERNAL would be bad news.
Sorry I've been unable to be very involved today. Anything you want me
to do here?
An exception is that void_out should succeed and just return an empty string;
this allows functions-returning-void to be called by SELECT and behave
reasonably. Less obviously, void_in should succeed (and return nothing
interesting, probably just a zero datum; it can ignore its input). This
allows plpgsql functions to be defined to return VOID.
This will be useful if/when we want to implement CALL stored_proc;
Should we throw a NOTICE stating that opaque is deprecated if a trigger
is declared with opaque? Or should we wait a release or two for that?
I'd throw the NOTICE now.
Joe
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proposal: make opaque obsolete
Tom Lane wrote: The reason I bring this up is that if we are changing the internal representation of arrays, we could add type OID and perhaps typmod to the array header, thus making an array value interpretable without any outside info. Then you could actually do something interesting with a function taking anyarraytype. This sounds very cool. I'd vote for that. Joe ---(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] pgstattuple change using SRF
Tatsuo Ishii [EMAIL PROTECTED] writes: I'm going to change contrib/pgstattuple so that it returns a tuple rather than a NOTICE using new SRF interface. I believe this way is much more convenient for users. Any objection? Sure. I like the way Joe did show_all() better than the way Neil did lock_status() --- I'm in the middle of getting rid of zero type OIDs throughout the system, and so I'm not happy with anything that re-introduces them, even if it's only transient during initdb. Other than that minor point, go for it... 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])
Re: [HACKERS] bison news
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, now that _a_ bison exists that works, how does this effect our release? I don't see preproc.[ch] in CVS. Do we need this new bison version on postgresql.org because Marc generates these as part of his install script? I don't think we want a beta bison on postgres.org. Let's see if we can hold out for a release... Well, we had better get it on or it will get zero testing, and we _need_ it for the 7.3 release of ecpg, because as I remember, we didn't have any other good backup plans. ;-) This may be a case where we have to do some beta testing on our own. I will grab the bison beta myself for my machine. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] How to disable encoding validation during database restore
Hi Tatsuo Ishii : Thank you very much for your reply. Somehow I managed to restore the data by creating by database in SQL_ASCII encoding. Then I changed the encoding of my database into EUC_CN thru update pg_database set encoding=2. But the same problem happened in vacuum verbose analyze. I went thru the changelog and found out that you have add the multibyte validation feature from release 7.2 on. Looks like the only way to get around is to patch the source. But I would like to suggest that this feature should be made configurable. You know encoding is a such a mess in the Chinese language, the popular Chinese input methods actually allow the input of any Chinese character from different encodings(e.g., GB2312/GBK, big5), it is difficult to make sure that the user always input valid characters unless you validate the insert and update clause. But the encoding validation is made for such cases. It will prevent the database from INSERT/UPDATE with wrong encoding data. If you really want to allow input any GB2312/GBK, big5 etc. encoded data to the database, why don't you simply use SQL_ASCII or some other single byte encodings? If you mix up GB2312/GBK, big5 in a database you could not perform sort or any other database operation properly anyway. -- Tatsuo Ishii ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgstattuple change using SRF
Tatsuo Ishii [EMAIL PROTECTED] writes: I'm going to change contrib/pgstattuple so that it returns a tuple rather than a NOTICE using new SRF interface. I believe this way is much more convenient for users. Any objection? Sure. I like the way Joe did show_all() better than the way Neil did lock_status() --- I'm in the middle of getting rid of zero type OIDs throughout the system, and so I'm not happy with anything that re-introduces them, even if it's only transient during initdb. Other than that minor point, go for it... I think pgstattuple() never uses OPAQUE... -- Tatsuo Ishii ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proposal: make opaque obsolete
Joe Conway [EMAIL PROTECTED] writes: Tom Lane wrote: ... Then you could actually do something interesting with a function taking anyarraytype. This sounds very cool. I'd vote for that. Um, am I hearing a volunteer to make it happen? I have other problems I need to deal with ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Build failure in current CVS
It looks like the new stuff for loadable conversion modules is not correct for building outside the source tree; it's being careless about the paths it uses to find files. Tatsuo, can you fix that, or ask Peter for help? I have applied following changes and am getting: make: *** No rule to make target `ascii_and_mic.o', needed by `libascii_and_mic.so.0.0'. Stop. under one of a conversion directory. The weird thing is I do not get this if I do a build inside the source tree. Any idea? Index: proc.mk === RCS file: /cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/proc.mk,v retrieving revision 1.2 diff -c -r1.2 proc.mk *** proc.mk 8 Aug 2002 07:47:43 - 1.2 --- proc.mk 21 Aug 2002 06:09:13 - *** *** 16,21 clean distclean maintainer-clean: clean-lib $(RM) $(OBJS) ! include $(top_builddir)/src/Makefile.shlib all: $(shlib) --- 16,21 clean distclean maintainer-clean: clean-lib $(RM) $(OBJS) ! include $(top_srcdir)/src/Makefile.shlib all: $(shlib) Index: ascii_and_mic/Makefile === RCS file: /cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic/Makefile,v retrieving revision 1.1 diff -c -r1.1 Makefile *** ascii_and_mic/Makefile 14 Aug 2002 02:45:10 - 1.1 --- ascii_and_mic/Makefile 21 Aug 2002 06:09:13 - *** *** 8,11 NAME := ascii_and_mic ! include ../proc.mk --- 8,12 NAME := ascii_and_mic ! include $(top_srcdir)/src/backend/utils/mb/conversion_procs/proc.mk ! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SQL99 CONVERT() function
Tatsuo Ishii writes: Done. See current doc (user's guide 6.4. String Functions and Operators Table 6-7 Available conversion names) how I changed the conversion names. What guideline did you follow? For example, should koi8r be koi8_r? Or should winXXX be win_XXX? -- Peter Eisentraut [EMAIL PROTECTED] ---(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 0x0001: Buffer overflow in
On Tue, 2002-08-20 at 17:15, Tom Lane wrote: Yes it has. CVS logs show 2002-08-04 02:44 thomas * src/backend/utils/adt/: date.c, datetime.c, format_type.c, nabstime.c, timestamp.c, varlena.c: Add guard code to protect from buffer overruns on long date/time input strings. [other comments pruned, but note this commit did a lot of other stuff too] The original argument was about whether we should push out a 7.2.2 release just because of this fix. AFAIK no one has even troubled to look at the patch and see whether it applies directly to the 7.2 branch; Thomas has revised the date/time code quite a bit since 7.2, so I'd expect that it's not going to apply exactly. It doesn't. I tried, since there's a Debian bug requesting those patches be applied, but as far as I remember every hunk failed. I didn't have time to try to make it fit. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C But I would not have you to be ignorant, brethren, concerning them which are asleep, that ye sorrow not, even as others which have no hope. For if we believe that Jesus died and rose again, even so them also which sleep in Jesus will God bring with him. I Thessalonians 4:13,14 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [PATCHES] Patch for roll forward recovery (PITR)
J.R, Richard, we only have 10 days until beta. Can you give us any status on PITR? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 20 Aug 2002 23:48, Greg Copeland wrote: On Tue, 2002-08-20 at 00:35, Dann Corbit wrote: Most computer virus problems are caused by buffer overrun. Someone decided it wasn't very important. This is true. IMO, it is extremely arrogant to ignore a buffer overrun and announce it can't be exploited. There is many cases where this assertion has been proved to be false. The real risk of overrun is not I would certainly hope you are not misquoting me here. I have never stated we should ignore the bug. I suggested that with proper network level protection, the bug should not be exploitable. If you did indeed misquote me, perhaps extreme arrogance in this case is the attribution of comments to people without basis? I agree with that too. When setting priorities, using a scale of 1-10, 10 being highest priority, anything that effects stability or reliability should always be a 10. As such, they should always be repaired even above new wiz-bang features. So, cutting through the self-supporting hyperbole, you believe that stability or reliability is more important than new features. I don't disagree. What I do disagree with is the panic mentality that seems so evident in this type of post. If you have set up your production infrastructure in a sensible manner (of course sensible is open for interpretation), this bug does not affect you. This does highlight the root cause of our difference in opinions - I don't feel this is an issue because it doesn't affect me. You may be concerned by these issues because your infrastructure allows the general 'net using public to directly access your database. While I disagree with this configuration...it doesn't make you fundamentely wrong, simply different in our respective approaches. IMO, if you don't embrace that rule of thumb, a developer shouldn't be working on a project where stability and reliability are key components of the end product. I wasn't aware that PostgreSQL as an open source collaborative project had any specific requirements of upon it at all. While stability and reliability are obvious goals, if you feel the project does not meet your needs you are more than welcome to try one of the alternatives. MySQL for example :) Seriously though, its similar to the people who run Linus' kernels. Oh my god they say, the stable 2.4.x series has VM issues. We can't trust it anymore! Why are you using that kernel in the first place? Where has Linus said that this is suitable for production use? Stable does not mean production ready. potential overruns should be identified. A grep for memcpy, strcpy, gets, etc. should hunt down most of them. A known buffer overrun should fill the designer of a product with abject terror. And I really mean Agreed. It is horribly irresponsible to thumb a nose at such things in this day and age. I'm not going to restate my previous response to this view, but I will ask, who is affected by the horribly irresponsible approach? If it is you, then why hasn't your due dilligence process audited the code? Perhaps you would feel more comfortable with one of the closed source/closed development model organisations? But what bugs lie within the depths of DBs such as SQL Server? How will you audit those? Or will you just trust the sales guy? programmers, but I am thinking of the damage that can be inflicted upon potential clients using the database. Not a question of it sounding negligent. It is negligent. If quality and stability is not the core developers #1 goal then expecting people to trust the resulting product is laughable. Please Where is an expectation at all? If you want to use PostgreSQL, then use it. If it doesn't meet your needs, don't use it, or start fixing the issues yourself. If you can't do it, buy Oracle, or DB2, or whatever else. Time and time again I've read what basically amounts to, ...if someone can crash it it's because someone is stupid enough to allow someone to be able to do it in the first place... Maybe you're right. After all, if core developers continue to turn a blind eye to such issues, they are in fact, the facilitators of allowing people to do it to begin with. I'm not sure how you make the jump from knowing that an issue exists and allowing people to exploit it, to the inference that core developers are turning a blind eye to it. Forgive me if I misquote you Tom, but I don't think he has ever said we should not fix this bug, simply that the effort is significant, and there are other factors to consider. You know, I've seen many people trash Oracle's unbreakable mantra. I'm sure no one is confused at the fact that it is nothing but a marketing ploy, however, perhaps there is a culture behind it. Perhaps this is their way of saying stability and reliability is very important to them. Perhaps their mantra is the rule of thumb outlined above. Perhaps we need a pgsql-hackers-heated_discussions list so we can
Re: [HACKERS] Build failure in current CVS
Tatsuo, why is there one directory per encoding combination with only one source file each? Couldn't we put all the files in one directory? euc_tw_and_big5 has *two* files. Also Unicode mapping files could be moved to each directory. So the Unicode related functions might have one more file. IMO giving a directory to each conversion is more manageable than putting everything in single directory. -- Tatsuo Ishii ---(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] Large file support available
Large file support is now compiled by default if available. (Use --disable-largefile to turn it off. That's what Autoconf gives us.) Are you sure that backend gains more performance than 1GB segmented file (I mean large file support turn on LET_OS_MANAGE_FILESIZE)? I myself have not tried yet, but a linux kernel hacker around me gave this question sometime ago. -- Tatsuo Ishii ---(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 0x0001: Buffer overflow
test=# \df iso8859_1_to_utf8 List of functions Result data type | Schema | Name| Argument data types --++---+- integer | pg_catalog | iso8859_1_to_utf8 | integer, integer, -, -, integer Right, that's what they are now, but what do the - entries really mean? Also, are the integer args and result truthful, or do they really mean something else? They are like: * conv_proc( * INTEGER,-- source encoding id * INTEGER,-- destination encoding id * OPAQUE, -- source string (null terminated C string) * OPAQUE, -- destination string (null terminated C string) * INTEGER -- source string length For the second and third argument they are actually treated as: unsigned char *src = PG_GETARG_CSTRING(2); unsigned char *dest = PG_GETARG_CSTRING(3); The first one is an input parameter(source string), and second one is an output parameter(destination string). The caller of this function is responsible for allocationg enough memory for destination string. The returned integer is actually dummy. The function always returns 1. -- Tatsuo Ishii ---(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] backpatch of datetime fixes
Neil Conway wrote: I've backpatched Thomas's fixes for the potential buffer overruns in the datetime code to the REL7_2_STABLE branch. The required changes are pretty minimal, and the code passes the regression tests. However, I haven't yet seen a test-case that demonstrates the buffer overrun in 7.2 code (I originally found the problem when playing with datetime on 7.3-dev with integer datetimes) I've had trouble provoking an error also, but the circumstances should be related to having a long date/time input, especially if it has more fields than one would expect in a valid date/time string. - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal: make opaque obsolete
Trigger functions will now be expected to take no arguments and return either tuple (or trigger if we call it that) or opaque. It would also be sensible to allow VOID in the case of AFTER triggers, but I'm inclined not to do so: I think it's better that a trigger function be declared in a way that makes it clear it's supposed to be a trigger. If CREATE TRIGGER accepts functions returning void then I think you lose some useful error checking. Should we throw a NOTICE stating that opaque is deprecated if a trigger is declared with opaque? Or should we wait a release or two for that? I think a NOTICE at creation time is fine. Comments? Sounds really good. Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Should someone from the core team perhaps get in contact with this guy and ask if he could get in contact with the development team before publicizing any further security holes? AFAIK that is standard operating procedure in most cases... Second, it might be worth pushing a 7.2.2 release containing the fix for this bug, as well as the datetime problem. If that sounds reasonable to the people who have to do the most work on a new release (e.g. Marc), I can volunteer to backport a fix for the datetime problem. It'd be better to contact the dude and get all his bugs out of him, fix them all and issue a 7.2.2 with all the fixes. I think this is now essential - people will be using 7.2 series for ages even after the 7.3 release... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
On Wed, 21 Aug 2002, Christopher Kings-Lynne wrote: Should someone from the core team perhaps get in contact with this guy and ask if he could get in contact with the development team before publicizing any further security holes? AFAIK that is standard operating procedure in most cases... Second, it might be worth pushing a 7.2.2 release containing the fix for this bug, as well as the datetime problem. If that sounds reasonable to the people who have to do the most work on a new release (e.g. Marc), I can volunteer to backport a fix for the datetime problem. It'd be better to contact the dude and get all his bugs out of him, fix them all and issue a 7.2.2 with all the fixes. That wouldn't work because it seems he is making advisories at the time he discovers a bug/flaw. That is, he is not directly interested in the robustness of Postgres -- rather, another poster put it, his reputation on bugtraq. That's fine but it doesn't mesh well with the co-ordinated effort you describe. I still do not see this as being a serious security problem unless you are providing access to postgres to untrusted users. The advisory's recommendation of killing the postmaster as a solution to these bugs is akin to saying 'kill ssh if there's a libc bug'. If you are providing access to untrusted users, that advice is worthwhile. But if your users are trusted and could produce the same effect in any other number of reasons, the advice is useless. As for making a 7.2.2 release for the sake of form and for those users who do provide access to untrusted users (universities, ISPs, say) this would be pointless without the changes to opaque which Tom has put forward and may/may not work on before 7.3 beta. I'm not sure that the core guys would be too happy doing that *and* requiring an initdb for a minor release (as I presume Tom's changes will require one). Gavin ---(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] Build failure in current CVS (src/backend/utils/mb/conversion_procs)
Tatsuo Ishii [EMAIL PROTECTED] writes: IMO giving a directory to each conversion is more manageable than putting everything in single directory. I lean towards Peter's point here. One or two files per conversion is not unmanageable to keep in a single directory. And I have noticed that make and make install are visibly slower than before because they have to recurse into all these new subdirectories. I think the accumulated developer time spent watching make will soon exceed any possible benefit from splitting these files into subdirectories :-( regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Tatsuo Ishii [EMAIL PROTECTED] writes: They are like: * conv_proc( *INTEGER,-- source encoding id *INTEGER,-- destination encoding id *OPAQUE, -- source string (null terminated C string) *OPAQUE, -- destination string (null terminated C string) *INTEGER -- source string length Got it (shoulda read the documentation before asking ;-)) The returned integer is actually dummy. The function always returns 1. Yes. I will change these to be declared as foo(int, int, cstring, cstring, int) returns void unless anyone has a problem with that? regards, tom lane ---(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] Trouble debugging contrib/fulltextindex
Hi All, Few quick questions. 1. How do you compile contribs with full debugging symbols. I always get heuristic-fencepost-blah probs with gdb even though I've configured postgres with all the debugging stuff. Makes it really hard to find probs in the contribs. 2. Should contribs exclusively use palloc/pfree? I notice that fulltextindex is using malloc and free - is there any real reason not to change them? I've attached the current tarball (extract in contrib) but my regression test is crashing and I've had to fill it full of elogs to see that nargs is being overwritten by an overflow or something. Florian - feel like helping me test/fix it. go 'gmake install' and then 'gmake installcheck' to test it. Thanks, Chris fulltextindex.tar.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
Gavin Sherry [EMAIL PROTECTED] writes: As for making a 7.2.2 release for the sake of form and for those users who do provide access to untrusted users (universities, ISPs, say) this would be pointless without the changes to opaque which Tom has put forward and may/may not work on before 7.3 beta. I don't think that releasing 7.2.2 without the opaque changes would be pointless. For one thing, the opaque-related security problems are comparatively minor: the cracker must be able to execute arbitrary SQL commands against the database, and by that stage of the game, a DoS attack is already trivial (e.g. disable GEQO and execute a 15 table join query). Also, from skimming the discussion on fixing the opaque problems, there will be at least some degree of backwards incompatibility. That is definitely undesirable for a stable point release -- as is an initdb, as you point out. This amount of pain to fix a minor security hole is *not* worth it, IMHO. So I think that fixing the opaque problems in 7.2.x is simply impossible. Given that, the question is whether we should make a 7.2.2 release with fixes for the other security holes (lpad(), rpad(), reverse(), and the datetime overruns). IMHO, we should. The datetime hole is fairly serious: it's not unreasonable for developers to accept datetime input from the user without limiting it's length. So it's quite likely that there are 7.2 systems in production that have a sane security policy (e.g. hidden behind a firewall, validate user input, etc.) that are still vulnerable. The alternative seems unattractive: if we require that users wait for 7.3 to come out, it may be months before the 7.3.0 release. And even then, upgrading to 7.3 is non-trivial: it requires an initdb and reload, as well as testing to ensure that the user's applications run smoothly on 7.3. Therefore, it may be several months before many production sites upgrade to 7.3; leaving them in the cold for that period isn't something I think we should do, if we can avoid it. That said, there's only a limited amount that I can do. I think we should make a 7.2.2 release, and to that end I've posted patches against REL7_2_STABLE for all four of the security holes. The rest of the work that goes into making a release needs to be done by others (Marc, Vince, Bruce, etc.) -- if there's anything I can do to help, let me know. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(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
