develooper Front page | perl.perl5.porters | Postings from October 2012

Re: Security Issues in perl-5.16.x

Thread Previous | Thread Next
Dave Mitchell
October 2, 2012 06:11
Re: Security Issues in perl-5.16.x
Message ID:
On Mon, Oct 01, 2012 at 08:30:40PM -0500, Reini Urban wrote:
> Aristotle: I already disclosed all the bugs pointed out to the sec list.
> 6 of 8 were fixed already.

Lets look at a bit of history on the
mailing list.

On the 18 Jun you posted to Tim Bunce and perl5-security-report, raising
two issues. First, that there was a dreadful security hole in DBI, that
you had reported months ago, and that Tim was refusing to address.

Tim very politely and at some length explained to you that yes, under some
circumstances, a freed buffer could be accessed, *but* that the only access
of that buffer was a specific integer read whose value was used in a
boolean comparison, the result of which could not affect the security of
the program. He ended the email with

> I agree. I will work hard to fix a security issue. If there is one.
> Please help me see the security issue here Reini as I'm still not seeing it.
> Simply repeating what you've already said won't help. Assume I'm really
> dumb and need to be walked though all the details. There's no need to
> use perl5-security-report for that. Just email me directly.

There was no reply from Reini, privately or to the list, as far as I'm

The second issue you raised in your 18 Jun email was:

> It already hurts that p5p shipped 5.16.0 with 5 known similar pointer
> overflows, though I reported them to the list and on RT timely.

I asked you list these issues, which you did in reply.

Let's look at these 5 issues:

* List::Util heap-overflow

    In your original ticket you yourself said
	"This does not look security relevant to me"
    Now, when the author of that CPAN module made the fix to this
    trivial non-security issue and included in the 1.24 release, it was
    close to the release date of 5.16.0, and Ricardo made the decision not
    to pull this new release in until 5.16.1, which was then done.

* cop_stashlen heap overflow

    This issue was reported by you 3 days *after* 5.16.0 was released,
    and was fixed in 5.16.1

* B::COP::stashlen

    You yourself described this as "(not a security issue, just API)";
    this was fixed in 5.16.1.

* clone issue

    Reported in March, fixed for 5.16.1

* and the final issue you described as:

    "(I'm not sure if this was ever reported or applied to
    blead, as you most likely will not be able to reproduce it)"

So of those 5 terrible security holes that we allowed 5.16.0 to be released
with, even though you had reported them in good time:

* two *you yourself* had earlier described as not security related;
* one you reported *after* 5.16.0 was released;
* one you were unable to identify;
* and only one was potentially security related and not fixed in time for

All were subsequently fixed for 5.16.1.

But there's a bit of further background to this; all these reports
were (AFAIKT) due to you running the address-sanitizer tool. But back in
November 2011 you posted to the security list saying that you had run this
tool, and found 45 issues, saying: "I'm not sure how many of them are
false alerts, but given the nature of the reported errors they look
security relevant".

You followed up this post 5 days later with "I found one true bug and most
others look like false positives."

So the lesson I think we drew from that was that when you report an issue
detected by this tool, we shouldn't necessarily immediate conclude that
its a valid security issue that needs to be immediately addressed.

The one other major issue you've raised on the security list and elsewhere
is that 5.16.0 allows null chars in module names and stashes. Well, there
were some changes in 5.16.0, but null chars in strings, symbol tables,
filenames etc has been a feature in perl since 5.000 or earlier.
Whether this is a good thing is something the can be discussed, but it's
hardly a new issue.

When we asked how this could be a security issue, the example you gave
was something along the lines of:

* an attacker could provide a module name with an embedded \0 and
  trailing payload (up to 8Mb of of it if it was via a POST request on a
  web server).
* This payload isn't exploitable of itself, but provides a convenient way
  to have exploit code loaded into memory ready for the use of one of the
  5 terrible security holes that 5.16.0 was released with.

Well, has has been commented elsewhere, if your code allows an attacker
to specify an arbitrary name of a module to be loaded and executed (via
POST data no less!), you've already lost the battle. The exploit would be
trivial: get the web server to store an uploaded file in a predicable
place, then just execute it!

And the null issue isn't an exploit in itself: you still require a
separate actual security hole to exploit in the first place, and as I've
listed above, the "5.16.0 issues" are all either definitely or probably
not security holes, and have all been fixed in 5.16.1 anyway.


Reini to world: "OMG! 5.16.0 is incredibly insecure; no-one must use it.
The Perl Porters don't understand security! They're all stupid! Why do
they refuse to fix these critical issues?"

Us: "No its not; yes we do, no we're not, no we don't".

I thought I was wrong once, but I was mistaken.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About