[HACKERS] Security bugs
I heard that 2 security bugs were fixed in 8.1.4. Since I like to upgrade from 8.1.3, I like to know the bugs. Can somebody give the description of those bugs? Thanks Dhanaraj ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Security bugs
On Jul 26, 2006, at 19:17 , Dhanaraj M wrote: I heard that 2 security bugs were fixed in 8.1.4. Since I like to upgrade from 8.1.3, I like to know the bugs. Can somebody give the description of those bugs? Following the Security link from the Postgres home page: http://www.postgresql.org/support/security.html You'll see a list of all security issues. The top two (CVE-2006-2314 and CVE-2006-2313) are probably the two you heard about. Hope this helps. Michael Glaesemann grzm seespotcode net ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Security bugs
Dhanaraj M wrote: I heard that 2 security bugs were fixed in 8.1.4. Since I like to upgrade from 8.1.3, I like to know the bugs. Can somebody give the description of those bugs? There is a list of the changes in each release in the Release Notes. In this case, you want: http://www.postgresql.org/docs/current/static/release.html#RELEASE-8-1-4 For this particular case there are also other docs: see http://www.postgresql.org/docs/techdocs.48 Essentially the security issues are related to uses of multi-byte encodings. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Security bugs in tsearch2
I just noticed that all of tsearch2's dict init routines are declared like this: CREATE FUNCTION dex_init(text) returns internal as 'MODULE_PATHNAME' language 'C'; This is really unacceptable, because it breaks the type safety of the internal pseudotype. I quote from datatype.sgml: The internal pseudo-type is used to declare functions that are meant only to be called internally by the database system, and not by direct invocation in a SQL query. If a function has at least one internal-type argument then it cannot be called from SQL. To preserve the type safety of this restriction it is important to follow this coding rule: do not create any function that is declared to return internal unless it has at least one internal argument. In a database with these functions installed, it will be trivial for anyone to crash the backend (and perhaps do worse things) since he can pass the result of dex_init to any function taking an internal argument --- almost none of which are expecting a dict data structure. Please change these at once. The best solution might be to declare an actual dict datatype for these functions to return. Another security issue is that these functions can be used to read any file that the backend can read. I'm not sure at the moment whether a bad guy could do anything useful with the result (are the contents of stoplists exposed anywhere?) but it seems fairly dangerous to allow arbitrary pathnames in the argument. A possible short-term solution is to revoke public execute rights on these functions, so that only superusers can call them. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
