Skip Menu |
Report information
Id: 127322
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: ntyni [at] debian.org
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: (no value)
Type: (no value)
Perl Version: (no value)
Fixed In: (no value)



Date: Tue, 19 Jan 2016 22:02:04 +0200
Subject: mkstemp(3) and umask
From: Niko Tyni <ntyni [...] debian.org>
To: perl5-security-report [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
Hi, I believe there's a minor security issue around mkstemp(3) usage in Perl, mainly 5.21.1 and newer. With commit v5.21.0-67-g60f7fc1 http://perl5.git.perl.org/perl.git/commitdiff/60f7fc1ea42054e92f34b4ce9d608efd14357392 perl started setting umask to 0600 before calling mkstemp(3), and then restoring it afterwards. This looks like a logical error as it tells open(2) to strip the owner read and write bits from the given mode before applying it. I think umask(0177) is what was intended. The mkstemp(3) function uses mode 0600 on at least modern GNU/Linux systems, so the resulting file becomes mode 0000. This is not a security problem, but it might be a usability problem - see https://bugs.debian.org/810924 which prompted this report. However, my mkstemp(3) manual page says that "the application should make sure its file mode creation mask (see umask(2)) is set appropriately before calling mkstemp()", and mentions ancient versions of glibc using mode 0666. Since the above commit, systems using mode 0666 in mkstemp(3) would get a file with 0066 (---rw-rw-) regardless of the original umask. This looks like a security problem, although the window of exploitation seems to be very small, as both relevant code paths in Perl unlink the file soon afterwards. The first code path in perl.c seems to be for some very obscure systems without /dev/null, but the other one in perlio.c is for things like 'open(my $fh, "+>", undef)' which are quite normal usage. So, it looks to me like the error has potential security implications for systems whose mkstemp(3) uses something else than mode 0600. I don't know if those exist, and the impact seems to be very small, but I'm reporting this as a security bug to be on the safe side. Feel free to turn this into a normal bug report if you think that's overly cautious. Many thanks for your work on Perl, -- Niko Tyni ntyni@debian.org
From: Jarkko Hietaniemi <jhi [...] iki.fi>
Date: Wed, 20 Jan 2016 00:20:53 +0100
To: "perl5-security-report [...] perl.org" <perl5-security-report [...] perl.org>
CC: "bugs-bitbucket [...] rt.perl.org" <bugs-bitbucket [...] rt.perl.org>
Subject: Re: [perl #127322] mkstemp(3) and umask
Download (untitled) / with headers
text/plain 2.3k


On Tuesday, January 19, 2016, Niko Tyni <perl5-security-report@perl.org> wrote:
Show quoted text
# New Ticket Created by  Niko Tyni
# Please include the string:  [perl #127322]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=127322 >


Hi, I believe there's a minor security issue around mkstemp(3) usage in
Perl, mainly 5.21.1 and newer.

With commit v5.21.0-67-g60f7fc1
 http://perl5.git.perl.org/perl.git/commitdiff/60f7fc1ea42054e92f34b4ce9d608efd14357392
perl started setting umask to 0600 before calling mkstemp(3),
and then restoring it afterwards.

This looks like a logical error as it tells open(2) to strip the
owner read and write bits from the given mode before applying it.
I think umask(0177) is what was intended.

Duh, yes. My bad. Forgot the NOT taking place.
 
Show quoted text
The mkstemp(3) function uses mode 0600 on at least modern GNU/Linux
systems, so the resulting file becomes mode 0000. This is not
a security problem, but it might be a usability problem  - see
https://bugs.debian.org/810924 which prompted this report.

However, my mkstemp(3) manual page says that "the application should
make sure its file mode creation mask (see umask(2)) is set appropriately
before calling mkstemp()", and mentions ancient versions of glibc using
mode 0666.

Since the above commit, systems using mode 0666 in mkstemp(3) would
get a file with 0066 (---rw-rw-) regardless of the original umask. This
looks like a security problem, although the window of exploitation seems
to be very small, as both relevant code paths in Perl unlink the file
soon afterwards.

The first code path in perl.c seems to be for some very obscure systems
without /dev/null, but the other one in perlio.c is for things like
'open(my $fh, "+>", undef)' which are quite normal usage.

So, it looks to me like the error has potential security implications for
systems whose mkstemp(3) uses something else than mode 0600. I don't know
if those exist, and the impact seems to be very small, but I'm reporting
this as a security bug to be on the safe side. Feel free to turn this
into a normal bug report if you think that's overly cautious.

Many thanks for your work on Perl,
--
Niko Tyni   ntyni@debian.org



--
There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Subject: Re: [perl #127322] mkstemp(3) and umask
Date: Thu, 21 Jan 2016 18:28:49 +0200
From: Niko Tyni <ntyni [...] debian.org>
To: Jarkko Hietaniemi via RT <perl5-security-report [...] perl.org>
On Tue, Jan 19, 2016 at 03:21:22PM -0800, Jarkko Hietaniemi via RT wrote: Show quoted text
> On Tuesday, January 19, 2016, Niko Tyni <perl5-security-report@perl.org> > wrote: >
> > # New Ticket Created by Niko Tyni > > # Please include the string: [perl #127322] > > # in the subject line of all future correspondence about this issue. > > # <URL: https://rt.perl.org/Ticket/Display.html?id=127322 > > > > > > > Hi, I believe there's a minor security issue around mkstemp(3) usage in > > Perl, mainly 5.21.1 and newer. > > > > With commit v5.21.0-67-g60f7fc1 > > > > http://perl5.git.perl.org/perl.git/commitdiff/60f7fc1ea42054e92f34b4ce9d608efd14357392 > > perl started setting umask to 0600 before calling mkstemp(3), > > and then restoring it afterwards. > > > > This looks like a logical error as it tells open(2) to strip the > > owner read and write bits from the given mode before applying it. > > I think umask(0177) is what was intended.
> > Duh, yes. My bad. Forgot the NOT taking place.
Thanks for the confirmation. Trivial proposed patch attached. -- Niko Tyni ntyni@debian.org

Message body is not shown because sender requested not to inline it.

Subject: Re: [perl #127322] mkstemp(3) and umask
To: perl5-security-report [...] perl.org
Date: Sun, 24 Jan 2016 11:12:28 -0500
From: Jarkko Hietaniemi <jhi [...] iki.fi>
Download (untitled) / with headers
text/plain 2.4k
I am prepared just to apply Niko's suggested patch (while noting the obvious need to have this in 5.22.2) and not bother with CVE-ing this issue. But then again, I'm quite biased against not making a big fuss about this, for obvious selfish reasons. Anyone less partial might to weigh in? On Tuesday-201601-19 15:02, Niko Tyni (via RT) wrote: Show quoted text
> # New Ticket Created by Niko Tyni > # Please include the string: [perl #127322] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=127322 > > > > Hi, I believe there's a minor security issue around mkstemp(3) usage in > Perl, mainly 5.21.1 and newer. > > With commit v5.21.0-67-g60f7fc1 > http://perl5.git.perl.org/perl.git/commitdiff/60f7fc1ea42054e92f34b4ce9d608efd14357392 > perl started setting umask to 0600 before calling mkstemp(3), > and then restoring it afterwards. > > This looks like a logical error as it tells open(2) to strip the > owner read and write bits from the given mode before applying it. > I think umask(0177) is what was intended. > > The mkstemp(3) function uses mode 0600 on at least modern GNU/Linux > systems, so the resulting file becomes mode 0000. This is not > a security problem, but it might be a usability problem - see > https://bugs.debian.org/810924 which prompted this report. > > However, my mkstemp(3) manual page says that "the application should > make sure its file mode creation mask (see umask(2)) is set appropriately > before calling mkstemp()", and mentions ancient versions of glibc using > mode 0666. > > Since the above commit, systems using mode 0666 in mkstemp(3) would > get a file with 0066 (---rw-rw-) regardless of the original umask. This > looks like a security problem, although the window of exploitation seems > to be very small, as both relevant code paths in Perl unlink the file > soon afterwards. > > The first code path in perl.c seems to be for some very obscure systems > without /dev/null, but the other one in perlio.c is for things like > 'open(my $fh, "+>", undef)' which are quite normal usage. > > So, it looks to me like the error has potential security implications for > systems whose mkstemp(3) uses something else than mode 0600. I don't know > if those exist, and the impact seems to be very small, but I'm reporting > this as a security bug to be on the safe side. Feel free to turn this > into a normal bug report if you think that's overly cautious. > > Many thanks for your work on Perl, >
CC: perl5-security-report [...] perl.org
To: Jarkko Hietaniemi <jhi [...] iki.fi>
From: Ricardo Signes <perl.security [...] rjbs.manxome.org>
Subject: Re: [perl #127322] mkstemp(3) and umask
Date: Mon, 25 Jan 2016 23:47:13 -0500
Download (untitled) / with headers
text/plain 555b
* Jarkko Hietaniemi <jhi@iki.fi> [2016-01-24T11:12:28] Show quoted text
> I am prepared just to apply Niko's suggested patch (while noting the obvious > need to have this in 5.22.2) and not bother with CVE-ing this issue. But > then again, I'm quite biased against not making a big > fuss about this, for obvious selfish reasons. Anyone less partial > might to weigh in?
I'm partial, too, because CVEs are a big pain. :-) Nonetheless, I think this is not CVE-worthy. Unless there are objections in the next few days, go ahead and push it. Friday the 29th? -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

Subject: Re: [perl #127322] mkstemp(3) and umask
CC: perl5-security-report [...] perl.org
To: Ricardo Signes <perl.security [...] rjbs.manxome.org>
Date: Tue, 26 Jan 2016 06:34:16 -0500
From: Jarkko Hietaniemi <jhi [...] iki.fi>
Download (untitled) / with headers
text/plain 639b
On Monday-201601-25 23:47, Ricardo Signes wrote: Show quoted text
> * Jarkko Hietaniemi <jhi@iki.fi> [2016-01-24T11:12:28]
>> I am prepared just to apply Niko's suggested patch (while noting the obvious >> need to have this in 5.22.2) and not bother with CVE-ing this issue. But >> then again, I'm quite biased against not making a big >> fuss about this, for obvious selfish reasons. Anyone less partial >> might to weigh in?
> > I'm partial, too, because CVEs are a big pain. :-) Nonetheless, I think this > is not CVE-worthy. Unless there are objections in the next few days, go ahead > and push it. Friday the 29th?
Sounds like a plan to me. Show quoted text
>
RT-Send-CC: rt-deliver-to-perl5-security-report [...] rt.perl.org
Download (untitled) / with headers
text/plain 809b
On Tue Jan 26 03:34:41 2016, jhi wrote: Show quoted text
> On Monday-201601-25 23:47, Ricardo Signes wrote:
> > * Jarkko Hietaniemi <jhi@iki.fi> [2016-01-24T11:12:28]
> >> I am prepared just to apply Niko's suggested patch (while noting the > >> obvious > >> need to have this in 5.22.2) and not bother with CVE-ing this issue. > >> But > >> then again, I'm quite biased against not making a big > >> fuss about this, for obvious selfish reasons. Anyone less partial > >> might to weigh in?
> > > > I'm partial, too, because CVEs are a big pain. :-) Nonetheless, I > > think this > > is not CVE-worthy. Unless there are objections in the next few days, > > go ahead > > and push it. Friday the 29th?
> > Sounds like a plan to me.
http://perl5.git.perl.org/perl.git/commit/e57270be442bfaa9dc23eebd67485e5a806b44e3 Show quoted text
> >
RT-Send-CC: perl5-porters [...] perl.org
Thanks, I have moved this ticket to perl5 queue and marked it pending release. -- rjbs
Download (untitled) / with headers
text/plain 252b
Thank you for submitting this report. You have helped make Perl better. With the release of Perl 5.24.0 on May 9, 2016, this and 149 other issues have been resolved. Perl 5.24.0 may be downloaded via https://metacpan.org/release/RJBS/perl-5.24.0


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org