Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The question in my mind is "What are we protecting against?" ISTM it is the use of the pl as a vector to attack the machine and postgres. Does a segfault come into that category? After all, isn't it one of postgres's strengths that we can survive individual backends crashing?
Yeah, but a repeatable segfault certainly is an adequate tool for a
denial-of-service attack, since it takes out everyone else's sessions
along with your own. A possibly larger objection is how sure can you be
that the effects will *only* be a segfault, and not say the ability to
execute some user-injected machine code.
Ok, the release notes for perl 5.005 (which is now pretty ancient) say this:
"Perl now contains its own highly optimized qsort() routine. The new qsort() is resistant to inconsistent comparison functions, so Perl's |sort()| will not provoke coredumps any more when given poorly written sort subroutines."
Also, there were some apparent problems with sort routine reentrancy in perl < 5.6.1 - see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=60534.
I have not found any more recent refs on Google to "sort" causing problems.
Certainly in my testing it proved totally trivial to crash the backend with sprintf.
So I suggest a reasonable position w.r.t. the danger of SEGVs would be to allow "sort" but disallow sprintf.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
