Integer overflows in Perl. ----- Forwarded message from Jan Dubois ----- Date: Mon, 13 Oct 2003 12:36:07 -0700 From: Jan Dubois Subject: Re: Plan B for fixing 5.8.2 binary API To: Chip Salzenberg Cc: Perl 5 Porters , debian-perl@lists.debian.org X-Mailer: Forte Agent 1.8/32.548 On Mon, 13 Oct 2003 14:57:59 -0400, Chip Salzenberg wrote: >IMO, high-quality hash seeding is more important than XS binary >compatibility. Seeding is a security feature, and security trumps >just about anything else[*]. If we can't make any plan for seeding >*with* bincompat work right -- though I'm confident that we can -- >then we should break the binary API in a way that requires >recompilation of XSs that use PERL_HASH(). Weak hash seeding is >simply Not OK. IMO. I think the security implications of hash seeding are totally blown out of proportion. It only helps against one specific DoS attack. This vulnerability still doesn't provide the attacker with access to the box itself. And there are plenty of DDoS attacks that hash seeding won't help against at all. If security trumps everything else, then I wonder why we[*] don't bother to fix the known buffer overrun problems in Perl that result from ignoring integer overflow in New(), SvGROW() etc. Examples for 32 bit machines: perl -e "q(xxxx) x 0x40000000" perl -e "$a[0x40000000] = 1" This has been sitting in the bug database for years and might be a real security risk for applications not doing proper argument checking. As for hash seeding, binary compatibility for the maintenance track is more important *for the ActivePerl distribution* from my point of view. I understand that for other environments binary compatibility might be less of an issue. That's why it is cool that it is build time configurable. :) Cheers, -Jan [*] If nobody beats me to it, I'll look into the buffer size overflow problems sometime next month. I think this really should be fixed for 5.8.2. ----- End forwarded message -----