perl NULL pointer dereference

Debian Bug report logs - #628817
perl NULL pointer dereference

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Thijs Kinkhorst" <thijs@debian.org>

To: submit@bugs.debian.org

Subject: perl NULL pointer dereference

Date: Wed, 1 Jun 2011 17:52:17 +0200

Package: perl
Severity: serious
Tags: security

Hi,

the following CVE (Common Vulnerabilities & Exposures) id was
published for perl.

CVE-2011-0761[0]:
| Perl 5.10.x allows context-dependent attackers to cause a denial of
| service (NULL pointer dereference and application crash) by leveraging
| an ability to inject arguments into a (1) getpeername, (2) readdir,
| (3) closedir, (4) getsockname, (5) rewinddir, (6) tell, or (7) telldir
| function call.

If you fix the vulnerability please also make sure to include the
CVE id in your changelog entry.

For further information see:

[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0761
    http://security-tracker.debian.org/tracker/CVE-2011-0761

Message #10 received at 628817@bugs.debian.org (full text, mbox, reply):

From: Dominic Hargreaves <dom@earth.li>

To: Thijs Kinkhorst <thijs@debian.org>, 628817@bugs.debian.org

Subject: Re: Bug#628817: perl NULL pointer dereference

Date: Wed, 1 Jun 2011 20:14:15 +0100

On Wed, Jun 01, 2011 at 05:52:17PM +0200, Thijs Kinkhorst wrote:
> the following CVE (Common Vulnerabilities & Exposures) id was
> published for perl.
> 
> CVE-2011-0761[0]:
> | Perl 5.10.x allows context-dependent attackers to cause a denial of
> | service (NULL pointer dereference and application crash) by leveraging
> | an ability to inject arguments into a (1) getpeername, (2) readdir,
> | (3) closedir, (4) getsockname, (5) rewinddir, (6) tell, or (7) telldir
> | function call.
> 
> If you fix the vulnerability please also make sure to include the
> CVE id in your changelog entry.
> 
> For further information see:
> 
> [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0761
>     http://security-tracker.debian.org/tracker/CVE-2011-0761

As some pointed out upstream[0], this is only an issue if an application
passes unvalidated input directly into those functions. Do we think
this makes this issue not worth fixing in stable/oldstable?

Dominic.

[0] <http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-06/msg00027.html>

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

Message #15 received at 628817@bugs.debian.org (full text, mbox, reply):

From: Niko Tyni <ntyni@debian.org>

To: Thijs Kinkhorst <thijs@debian.org>, 628817@bugs.debian.org

Subject: Re: Bug#628817: perl NULL pointer dereference

Date: Thu, 2 Jun 2011 14:39:35 +0300

On Wed, Jun 01, 2011 at 05:52:17PM +0200, Thijs Kinkhorst wrote:
> Package: perl
> Severity: serious
> Tags: security

> CVE-2011-0761[0]:
> | Perl 5.10.x allows context-dependent attackers to cause a denial of
> | service (NULL pointer dereference and application crash) by leveraging
> | an ability to inject arguments into a (1) getpeername, (2) readdir,
> | (3) closedir, (4) getsockname, (5) rewinddir, (6) tell, or (7) telldir
> | function call.

Some observations:

- the crash can be reproduced with just 
   perl -e 'getsockname(1,1)'

- the functions (at least getsockname) don't seem to check their argument
  count, they only use the last one. This is still the case in 5.12.
  I haven't found any indication of the Perl stack corrupting on 5.12
  though so this seems harmless.

- the crash is at gv.c:89 (as of 5.10.1):
    if (!gv || SvTYPE((const SV *)gv) != SVt_PVGV) {

- compiler optimization of gv.c affects the behaviour:
  + a regular perl built with -O0 gives the intended
      Bad symbol for filehandle at -e line 1

  + a debugging version (-DDEBUGGING) with -O0 gives an expected
    assertion failure:
      Assertion gv failed: file "gv.c", line 87 at -e line 1.

  + -DDEBUGGING at -O2 (i.e. what's in the perl-debug package)
    crashes the same way as the regular perl so the assertion check
    is bypassed.

I don't quite understand yet what happens in the optimized version of
Perl_gv_IOadd(); the gv is NULL so the !gv check above should prevent
referencing it AIUI.
-- 
Niko Tyni   ntyni@debian.org

Message #20 received at 628817@bugs.debian.org (full text, mbox, reply):

From: Dominic Hargreaves <dom@earth.li>

To: Niko Tyni <ntyni@debian.org>, 628817@bugs.debian.org

Cc: Thijs Kinkhorst <thijs@debian.org>

Subject: Re: Bug#628817: perl NULL pointer dereference

Date: Mon, 13 Jun 2011 18:48:46 +0100

On Thu, Jun 02, 2011 at 02:39:35PM +0300, Niko Tyni wrote:
> On Wed, Jun 01, 2011 at 05:52:17PM +0200, Thijs Kinkhorst wrote:
> > Package: perl
> > Severity: serious
> > Tags: security
> 
> > CVE-2011-0761[0]:
> > | Perl 5.10.x allows context-dependent attackers to cause a denial of
> > | service (NULL pointer dereference and application crash) by leveraging
> > | an ability to inject arguments into a (1) getpeername, (2) readdir,
> > | (3) closedir, (4) getsockname, (5) rewinddir, (6) tell, or (7) telldir
> > | function call.
> 
> Some observations:
> 
> - the crash can be reproduced with just 
>    perl -e 'getsockname(1,1)'
> 
> - the functions (at least getsockname) don't seem to check their argument
>   count, they only use the last one. This is still the case in 5.12.
>   I haven't found any indication of the Perl stack corrupting on 5.12
>   though so this seems harmless.
> 
> - the crash is at gv.c:89 (as of 5.10.1):
>     if (!gv || SvTYPE((const SV *)gv) != SVt_PVGV) {
> 
> - compiler optimization of gv.c affects the behaviour:
>   + a regular perl built with -O0 gives the intended
>       Bad symbol for filehandle at -e line 1
> 
>   + a debugging version (-DDEBUGGING) with -O0 gives an expected
>     assertion failure:
>       Assertion gv failed: file "gv.c", line 87 at -e line 1.
> 
>   + -DDEBUGGING at -O2 (i.e. what's in the perl-debug package)
>     crashes the same way as the regular perl so the assertion check
>     is bypassed.
> 
> I don't quite understand yet what happens in the optimized version of
> Perl_gv_IOadd(); the gv is NULL so the !gv check above should prevent
> referencing it AIUI.

Niko,

In your opinion, based on the above and the (only) upstream response
on
<http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-06/msg00027.html>
do you think that this bug should be downgraded from serious, since
apps should not (according to upstream, and I'm inclined to agree) be
passing unsanitised untrusted input into those functions?

Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

Message #25 received at 628817@bugs.debian.org (full text, mbox, reply):

From: Niko Tyni <ntyni@debian.org>

To: Dominic Hargreaves <dom@earth.li>, 628817@bugs.debian.org

Cc: team@security.debian.org

Subject: Re: Bug#628817: perl NULL pointer dereference

Date: Mon, 13 Jun 2011 21:09:43 +0300

severity 628817 important
thanks

Security team: please let us know if you disagree. See below.

On Mon, Jun 13, 2011 at 06:48:46PM +0100, Dominic Hargreaves wrote:
> On Thu, Jun 02, 2011 at 02:39:35PM +0300, Niko Tyni wrote:
> > On Wed, Jun 01, 2011 at 05:52:17PM +0200, Thijs Kinkhorst wrote:
> > > Package: perl
> > > Severity: serious
> > > Tags: security
> > 
> > > CVE-2011-0761[0]:
> > > | Perl 5.10.x allows context-dependent attackers to cause a denial of
> > > | service (NULL pointer dereference and application crash) by leveraging
> > > | an ability to inject arguments into a (1) getpeername, (2) readdir,
> > > | (3) closedir, (4) getsockname, (5) rewinddir, (6) tell, or (7) telldir
> > > | function call.
> > 
> > Some observations:
> > 
> > - the crash can be reproduced with just 
> >    perl -e 'getsockname(1,1)'
> > 
> > - the functions (at least getsockname) don't seem to check their argument
> >   count, they only use the last one. This is still the case in 5.12.
> >   I haven't found any indication of the Perl stack corrupting on 5.12
> >   though so this seems harmless.
> > 
> > - the crash is at gv.c:89 (as of 5.10.1):
> >     if (!gv || SvTYPE((const SV *)gv) != SVt_PVGV) {
> > 
> > - compiler optimization of gv.c affects the behaviour:
> >   + a regular perl built with -O0 gives the intended
> >       Bad symbol for filehandle at -e line 1
> > 
> >   + a debugging version (-DDEBUGGING) with -O0 gives an expected
> >     assertion failure:
> >       Assertion gv failed: file "gv.c", line 87 at -e line 1.
> > 
> >   + -DDEBUGGING at -O2 (i.e. what's in the perl-debug package)
> >     crashes the same way as the regular perl so the assertion check
> >     is bypassed.
> > 
> > I don't quite understand yet what happens in the optimized version of
> > Perl_gv_IOadd(); the gv is NULL so the !gv check above should prevent
> > referencing it AIUI.
> 
> Niko,
> 
> In your opinion, based on the above and the (only) upstream response
> on
> <http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-06/msg00027.html>
> do you think that this bug should be downgraded from serious, since
> apps should not (according to upstream, and I'm inclined to agree) be
> passing unsanitised untrusted input into those functions?

I haven't had the time to look at this any further, but I agree that
the severity should be downgraded. Doing that but Cc'ing the
security team (with extensive quoting) in case they think otherwise.
-- 
Niko Tyni   ntyni@debian.org

Message #40 received at 628817-done@bugs.debian.org (full text, mbox, reply):

From: Dominic Hargreaves <dom@earth.li>

To: 628817-done@bugs.debian.org

Subject: Not planning to fix in stable, so closing

Date: Wed, 4 Jan 2012 21:24:10 +0000

As I said in another mail:

> Upstream thinks this isn't classed as a security vulnerability[1], and
> I've not been able to find any evidence of anyone else having fixed this
> either. As such (and as I noted in the above bug report) I don't think
> it's worth fixing (if it is, I'm not the right person to attempt it).

> [1] <http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2011-06/msg00027.html>

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

Send a report that this bug log contains spam.