Assigning to the Perl stack maintainers, CC'ing the registered maintainer.

CC: (none) => marja11, shlomif
Assignee: bugsquad => perl

Submitted updated packes to cauldron, mga6 and mga7. http://pkgsubmit.mageia.org/ .

Whiteboard: MGA6TOO => MGA5TOO
Version: Cauldron => 6

and what is the difference between cauldron and mga7 ? :)

Please keep the MGA6TOO key work and add the src + rpms fo the QA

Whiteboard: MGA5TOO => MGA5TOO, MAG6TOO
CC: (none) => mageia

Thanks Shlomi!

Advisory:
========================

Updated perl-Archive-Tar package fixes security vulnerability:

By default, the Archive::Tar Perl module doesn't allow extracting files outside
the current working directory. However, you can bypass this secure extraction
mode easily by putting a symlink and a regular file with the same name into the
tarball (CVE-2018-12015).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12015
http://openwall.com/lists/oss-security/2018/06/07/4
========================

Updated packages in core/updates_testing:
========================
perl-Archive-Tar-2.280.0-1.mga5
perl-Archive-Tar-2.280.0-1.mga6

from SRPMS:
perl-Archive-Tar-2.280.0-1.mga5.src.rpm
perl-Archive-Tar-2.280.0-1.mga6.src.rpm

Assignee: perl => qa-bugs
Whiteboard: MGA5TOO, MAG6TOO => MGA5TOO

MGA5-32 on Dell Latitude D600 Xfce
No installation issues
Googling for some example fiddled little script together (see  attachment), run it, and open the resulting tar. All expected files are there.
If you want to use this script, you'll have to adapt the directory string in the script.
OK for me.

CC: (none) => herman.viaene
Whiteboard: MGA5TOO => MGA5TOO MGA5-32-OK

Created attachment 10234 [details]
example script

MGA6-32 on IBM Thinkpad R50e MATE
No installation issues.
Hmmm, strange: trying to run the test before update: it was OK, but then I noticed there was no perl-Archive-Tar package at all installed on this machine. I am sure I picked up the script from https://stackoverflow.com/questions/515553/how-can-i-archive-a-directory-in-perl-like-tar-does-in-unix , but then the archive::tar module must also be in some other package?????
At least the new package does not break the test.

It must be bundled in perl itself then.  Have you tested the security issue itself yet?  It may need to be patched in the perl package too.

I can extract a softlink to a file external to the current working directory with the trick described in Comment 4 using the regular tar commands. So that's OK. But that still doesn't use any perl script then.

PoC in link in Comment 0.

Fiddled an extract script together and that does the job OK as described above.
But that still doesn't tell me which module is now used , the one in our package or somewhere else??? But maybe we shouldn't care????

Created attachment 10236 [details]
perlextract

Herman, please see the link in Comment 0.

As for what it uses, it will use the bundled one in the perl package unless you install perl-Archive-Tar, then it uses that one.

That's what I did: create a tar archive which such a link and prove (using the trick) that it gets extracted correctly.

Running this by Mageia 6, x86_64.

Before update:

Examine archive:
$ tar -tvvf traversal.tar.gz
lrwxrwxrwx root/root         0 2018-06-05 17:55 moo -> /tmp/moo
-rw-r--r-- root/root         4 2018-06-05 17:55 moo
$ pwd
/home/lcl/qa/perl-Archive-Tar
$ ls /tmp/moo
ls: cannot access '/tmp/moo': No such file or directory
$ perl -MArchive::Tar -e 'Archive::Tar->extract_archive("traversal.tar.gz")'
$ ls /tmp/moo
/tmp/moo
$ ls
moo@  traversal.tar.gz

After update:
$ unlink moo
$ ls
'#report.23148#'  traversal.tar.gz
$ rm -f /tmp/moo
$ perl -MArchive::Tar -e 'Archive::Tar->extract_archive("traversal.tar.gz")'
$ ls
moo  '#report.23148#'  traversal.tar.gz
$ ls /tmp/moo
ls: cannot access '/tmp/moo': No such file or directory

Good for Mageia 6 as well.

CC: (none) => tarazed25
Whiteboard: MGA5TOO MGA5-32-OK => MGA5TOO MGA5-32-OK MGA6-64-OK

Thanks Len.  Did you try it with the bundled one (uninstalling perl-Archive-Tar)?

Oops.  No.  Wait a bit.

As an extra check extracted the contents of an existing tarball.
$ perl -MArchive::Tar -e 'Archive::Tar->extract_archive("/data/bin.tar")'
$ ls
bin/  moo  report.23148  traversal.tar.gz
$ ls bin
accumulate*    contacts*         getlibcver*      pcard*         tbird*
backdocs*      copycal*          getyoutube*      pix*           tidy*
[.....]
coltotal*      freeview*         paddb*           stime*
coltotali*     fullsheet*        paddbak*         table*
conform*       gcalctool@        patterns*        tarback*

which is correct.

# urpme perl-Archive-Tar
removing perl-Archive-Tar-2.280.0-1.mga6.noarch
removing package perl-Archive-Tar-2.280.0-1.mga6.noarch

$ rm -rf bin
$ rm -f moo
$ tar -xzf traversal.tar.gz
$ ls
moo  report.23148  '#supplement#'  traversal.tar.gz
$ cat moo
moo

Wait, isn't moo bad?

If you look at the archive file using ark it reports one file, moo, as a symbolic link to /tmp/moo but if it is extracted it appears as a regular file with content.  The same happens with tar.  There is no /tmp/foo/, so yes something odd may be happening here.

This is an ASCII dump of traversal.tar:
$ od -a traversal.tar 
0000000   m   o   o nul nul nul nul nul nul nul nul nul nul nul nul nul
0000020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000140 nul nul nul nul   0   0   0   0   7   7   7 nul   0   0   0   0
0000160   0   0   0 nul   0   0   0   0   0   0   0 nul   0   0   0   0
0000200   0   0   0   0   0   0   0 nul   1   3   3   0   5   5   4   0
0000220   2   2   6 nul   0   1   1   6   6   2 nul  sp   2   /   t   m
0000240   p   /   m   o   o nul nul nul nul nul nul nul nul nul nul nul
0000260 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0000400 nul   u   s   t   a   r  sp  sp nul   r   o   o   t nul nul nul
0000420 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000440 nul nul nul nul nul nul nul nul nul   r   o   o   t nul nul nul
0000460 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001000   m   o   o nul nul nul nul nul nul nul nul nul nul nul nul nul
0001020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001140 nul nul nul nul   0   0   0   0   6   4   4 nul   0   0   0   0
0001160   0   0   0 nul   0   0   0   0   0   0   0 nul   0   0   0   0
0001200   0   0   0   0   0   0   4 nul   1   3   3   0   5   5   4   0
0001220   2   2   6 nul   0   1   0   2   6   3 nul  sp   0 nul nul nul
0001240 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0001400 nul   u   s   t   a   r  sp  sp nul   r   o   o   t nul nul nul
0001420 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0001440 nul nul nul nul nul nul nul nul nul   r   o   o   t nul nul nul
0001460 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0002000   m   o   o  nl nul nul nul nul nul nul nul nul nul nul nul nul
0002020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0024000

$ ls -i
94388427 moo  94388426 traversal.tar
$ ll
total 16
-rw-r--r-- 1 lcl lcl     4 Jun  5 17:55 moo
-rw-r--r-- 1 lcl lcl 10240 Jun 12 06:36 traversal.tar

I do not know what the format is for a tar file but inspection indicates that permissions and size for moo agree with those in the tar file.  I guess ownership is transferred to user on extraction.  The string 2/tmp/moo occurs in there - the symbolic link.

$ rm -f moo
$ $ tar --keep-directory-symlink -xf traversal.tar
$ ls
moo  traversal.tar
$ cat moo
moo
$ ls /tmp/moo
ls: cannot access '/tmp/moo': No such file or directory

I cannot tell if moo is bad or not.

Re comment 20, ignore the sentence: "I guess ownership is transferred to user on extraction."

I guess just /tmp/moo is bad.  So if you run the extraction with the bundled Archive::Tar in perl (and not the packaged one) it doesn't create it?

Just ran a simple experiment; created a tar file of a directory containing a valid symbolic link. 'tar tf file.tar' listed an entry for the symlink.  Extracted the tar file in a temporary directory and saw the symbolic link, still valid.
$ tar --get .get_iplayer/regulus -f bbc.tar
$ ls .get_iplayer
regulus@

So tar does handle symbolic links without any extra options, and moo is bad.  It is a symlink pointing nowhere, so its reappearance as an ordinary file implies that tar treats it as a bad link - does not know what to do with it and writes it as a normal file containing its own name.  That last bit is supposition of course.

Well I think the issue is that extracting the PoC creates the file in /tmp when you're not *in* /tmp.  Does it do this with the Archive::Tar bundled in perl???

Mid-air collision.  Long spiel to do with dangling links, but never mind that.

Reinstalled perl-Archive-Tar 2.40.0-3.
$ pwd
/home/lcl/qa/perl-Archive-Tar/tmp
$ perl -MArchive::Tar -e 'Archive::Tar->extract_archive("traversal.tar")'
$ ll
total 12
lrwxrwxrwx 1 lcl lcl     8 Jun 12 11:30 moo -> /tmp/moo
-rw-r--r-- 1 lcl lcl 10240 Jun 12 06:36 traversal.tar

which brings us back to the pre-update test.
So the answer is yes.
$ cat moo
moo
$ od -a moo
0000000   m   o   o  nl
0000004
$ cd /tmp
$ cat moo
moo

Sorry, I'm still not seeing the answer to my question.

Debian has issued an advisory for this today (June 12):
https://www.debian.org/security/2018/dsa-4226

This one is for the perl package itself, telling me that it does indeed need to be patched.

Assignee: qa-bugs => shlomif
Keywords: feedback => (none)
CC: (none) => qa-bugs
Summary: perl-Archive-Tar new security issue CVE-2018-12015 => perl, perl-Archive-Tar new security issue CVE-2018-12015
Source RPM: perl-Archive-Tar-2.260.0-2.mga7.src.rpm => perl, perl-Archive-Tar-2.260.0-2.mga7.src.rpm
Whiteboard: MGA5TOO MGA5-32-OK MGA6-64-OK => MGA5TOO

Re comment 26.  I am obviously too thick to understand what the question is.  I am too old and tired for this.  Half the morning wasted.

Summarizing the PoC:

re comment 28:
Using perl-Archive-Tar (pre-update == "bundled in perl with Core Release"?)
and working in a dedicated QA directory, the symbolic link is created in
the current directory and points to /tmp/moo, which exists at this point;
'cat /tmp/moo' returns "moo".

/bin/tar does not generate a symbolic link and places an ordinary file
named "moo" in the current directory only, nothing in /tmp.
After the update, perl-Archive-Tar behaves exactly the same way; no symlink.

If this does not answer the question then you must be using terms which I
do not understand.

Note that before this investigation there was no perl-Archive-Tar on this system.  It had to be installed.

Apropos comment 25; have just discovered /bin/ptar, which is an easier way to use Archive::Tar.
Before update:
$ ptar -x -f traversal.tar.gz
$ ll moo
lrwxrwxrwx 1 lcl lcl 8 Jun 12 16:22 moo -> /tmp/moo
$ ll /tmp/moo
-rw-r--r-- 1 lcl lcl 4 Jun 12 16:23 /tmp/moo

Ok, if I'm reading Comment 20 correctly, with the corrected perl-Archive-Tar, /tmp/moo does not get created, but with the old one it does.

What I was asking for is what happens with the bundled one (i.e. when the perl-Archive-Tar package is not installed)?  Can you confirm that it exhibits the undesired behavior of the old perl-Archive-Tar?

This is the bit I don't understand.  What bundled one.  I have removed perl-Archive-Tar.  This is what is left:
$ locate Archive | grep perl
/usr/lib/perl5/5.22.3/Archive
/usr/lib/perl5/5.22.3/Archive/Tar
/usr/lib/perl5/5.22.3/Archive/Tar.pm
/usr/lib/perl5/5.22.3/Archive/Tar/Constant.pm
/usr/lib/perl5/5.22.3/Archive/Tar/File.pm
/usr/lib/perl5/vendor_perl/5.22.0/Archive
/usr/lib/perl5/vendor_perl/5.22.0/Archive/Cpio
/usr/lib/perl5/vendor_perl/5.22.0/Archive/Cpio.pm
/usr/lib/perl5/vendor_perl/5.22.0/Archive/Cpio/Common.pm
/usr/lib/perl5/vendor_perl/5.22.0/Archive/Cpio/File.pm
/usr/lib/perl5/vendor_perl/5.22.0/Archive/Cpio/FileHandle_with_pushback.pm
/usr/lib/perl5/vendor_perl/5.22.0/Archive/Cpio/NewAscii.pm
/usr/lib/perl5/vendor_perl/5.22.0/Archive/Cpio/ODC.pm
/usr/lib/perl5/vendor_perl/5.22.0/Archive/Cpio/OldBinary.pm
/usr/lib/perl5/vendor_perl/5.22.2/Archive
/usr/lib/perl5/vendor_perl/5.22.2/Archive/Tar
/usr/lib/perl5/vendor_perl/5.22.2/Archive/Tar.pm
/usr/lib/perl5/vendor_perl/5.22.2/Archive/Tar/Constant.pm
/usr/lib/perl5/vendor_perl/5.22.2/Archive/Tar/File.pm
/usr/lib/perl5/vendor_perl/5.22.3/Archive

Is /bin/ptar the bundled one that you referred to?  tar does not exhibit the undesired behaviour but ptar does.  Just ran it and moo@ appeared in the test directory.
$ ptar -x -f traversal.tar.gz
$ ll
total 16
lrwxrwxrwx 1 lcl lcl     8 Jun 12 20:47 moo -> /tmp/moo
-rw-r--r-- 1 lcl lcl 10240 Jun 12 06:36 traversal.tar
-rw-r--r-- 1 lcl lcl   135 Jun 12 15:05 traversal.tar.gz
$ pwd
/home/lcl/qa/perl-Archive-Tar/tmp
$ cat /tmp/moo
moo

If it is ptar that you are talking about I wish I had been told about it.  It turned up quite by chance in a search for files in /bin with 'tar' in their names.

The perl package bundles *several* perl modules, many of which we have separately packaged as well.  If you don't have the separate package installed, calls to that module will use the one bundled by perl.

It's exactly like I said, run the PoC with perl-Archive-Tar *not* installed, which will use the Archive::Tar bundled in the perl package.  What happens???  Vulnerable or not?

That's the thing David.  What are you saying?  How do you call it?  What is the command?

Will this still work?
$ perl -MArchive::Tar -e 'Archive::Tar->extract_archive("traversal.tar")'

Never mind, I'll try that anyway.
$ perl -MArchive::Tar -e 'Archive::Tar->extract_archive("traversal.tar.gz")'
$ ls
moo@        spiel         supplement  traversal.tar.gz
$ cat /tmp/moo
moo

So the bundled Archive::Tar is vulnerable.
You must realize by now that I have absolutely no knowledge of the perl infrastructure.  I assumed that without the perl-Archive-Tar package that command would no longer work, which is why I went looking for an alternative way to run the PoC.

Looks like you figured it out.  It is vulnerable as expected.  You run it the exact same way.  Perl searches its module path to find the module.

Thanks for the coaching David.  When you don't actually know the countryside you are forced to make assumptions and mine was that the Archive::Tar module came with the package under test.  I had no real idea about "bundling" and expected
perl -MArchive::Tar to fail.....

Yeah it is confusing and this isn't the first time it has tripped me up (actually it does just about every time).  Bundling is annoying.

@ David Comment 35
So it looks like we can never be sure what module perl actually uses in such case, unless we start digging into its internals and figure a way to disable the bundled module?????

No, you can always be sure as long as you know what packages you have installed.  Perl will use the separately packaged ones if they're installed, and the bundled ones if they're the only ones available.

(In reply to David Walser from comment #27)
> Debian has issued an advisory for this today (June 12):
> https://www.debian.org/security/2018/dsa-4226
> 
> This one is for the perl package itself, telling me that it does indeed need
> to be patched.

Ubuntu has also issued an advisory for this today (June 13):
https://usn.ubuntu.com/3684-1/

openSUSE has issued advisories for this (for perl) today (July 20):
https://lists.opensuse.org/opensuse-updates/2018-07/msg00044.html
https://lists.opensuse.org/opensuse-updates/2018-07/msg00045.html

Mageia 6 is EOL.

Status: NEW => RESOLVED
CC: (none) => mrambo
Resolution: (none) => OLD