From: Alexey Tourbin <at@altlinux.ru>
To: devel@altlinux.ru
Subject: [devel] Fwd: Re: Plan B for fixing 5.8.2 binary API
Date: Tue, 14 Oct 2003 14:00:04 +0400
Message-ID: <20031014100004.GE1724@julia.office.altlinux.ru> (raw)
[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]
Integer overflows in Perl.
----- Forwarded message from Jan Dubois <jand@ActiveState.com> -----
Date: Mon, 13 Oct 2003 12:36:07 -0700
From: Jan Dubois <jand@ActiveState.com>
Subject: Re: Plan B for fixing 5.8.2 binary API
To: Chip Salzenberg <chip@debian.org>
Cc: Perl 5 Porters <perl5-porters@perl.org>,
debian-perl@lists.debian.org
X-Mailer: Forte Agent 1.8/32.548
On Mon, 13 Oct 2003 14:57:59 -0400, Chip Salzenberg <chip@debian.org>
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 -----
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
reply other threads:[~2003-10-14 10:00 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031014100004.GE1724@julia.office.altlinux.ru \
--to=at@altlinux.ru \
--cc=devel@altlinux.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git