CVE-2016-1238 (local privilege escalation) is easily exploitable but it is not addressed in Trisquel 8.0

Proxecto:Trisquel
Versión:8.0
Componente:Packages
Categoría:informe de erro
Prioridade:critical
Asignado:Sen asignar
Estado:patch (needs work)
Descrición

Steps to reproduce:

1. Execute the following command:

mkdir /tmp/Encode; echo "system(q(id)); 1;" > /tmp/Encode/ConfigLocal.pm

2. Change the current working directory to /tmp:

cd /tmp

3. Run dpkg-reconfigure, adduser, deluser or tasksel as root:

sudo tasksel

Expected result:
/tmp/Encode/ConfigLocal.pm should not be executed.

Observed result:
You will see a line containing output of the "id" command: "uid=0(root) gid=0(root) groups=0(root)".

Trisquel 8.0 and earlier versions are affected, the upcoming Trisquel 9 is not affected.

Canonical has decided to ignore this vulnerability in Ubuntu 16.04, cf.: https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-1238.html, https://bugs.launchpad.net/ubuntu/+source/perl/+bug/1705145. This vulnerability has been mitigated in Debian "jessie", I propose that their patches for Perl 5.20 should be ported to Perl 5.22 (this version is in Trisquel 8.0).

External links:
https://security-tracker.debian.org/tracker/CVE-2016-1238
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-1238
https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-1238.html
https://bugs.launchpad.net/ubuntu/+source/perl/+bug/1705145
https://sources.debian.org/src/perl/5.20.2-3+deb8u11/debian/patches/debian/CVE-2016-1238/
https://sources.debian.org/src/perl/5.20.2-3+deb8u11/debian/patches/fixes/CVE-2016-1238/

Mar, 11/12/2019 - 14:32

Hello! Any suggestions from Trisquel maintainers on their preferred approarch to fixing this issue? Should Debian patches be ported to perl 5.22.1-9ubuntu0.6? Or maybe somebody should rebase Ubuntu patches to upstream perl 5.22.4? Or a mitigation described in https://bugzilla.redhat.com/show_bug.cgi?id=1355695#c29?

Mar, 11/12/2019 - 20:39

Hi marit. I started on this a while back. I found the patches for perl 5.22.1 in Debian's VCS. However, after applying them and building the source package several binaries were not built. sbuild did not give any errors, so I wasn't sure why these binaries were missing. Since perl is so level, it would be risky to merge the change before making sure that everything checks out, and I haven't gotten around to investigating further. Maybe I'll be able to find time this weekend. Sorry for the delay.

See: https://devel.trisquel.info/trisquel/package-helpers/merge_requests/232

Mér, 11/13/2019 - 20:57

Problems with building perl-modules-5.22 are probably related to https://salsa.debian.org/perl-team/interpreter/perl/commit/fe67e31bb17f54b6dae8ca495e36edcd517f0bb6 (patch mb-without-dot.diff) being missed in https://salsa.debian.org/perl-team/interpreter/perl/tree/debian-5.22/ branch. It can also be worth checking what upstream perl 5.22.x does with Module::Build.

There is a list of 11 "updated packages to address optional module loading vulnerabilities related to CVE-2016-1238, or to address build failures which occur when '.' is removed from @INC" in https://www.debian.org/security/2016/dsa-3628.

Ven, 11/15/2019 - 19:53

From today's meeting

10:32:36 quidam | chaosmonk: I'm worried the behavior changes in perl would break production servers for users
10:45:04 quidam | the bug doesn't seem too serious, it requires that you have write access to the directory running the attacked script
10:45:37 quidam | which would be such a big hole in the first place that makes the exploit barely a thing

Sáb, 11/16/2019 - 13:56

> I'm worried the behavior changes in perl would break production servers for users
"." should not be removed from @INC by default, this will prevent breakage. In 2016 Debian developers removed "." from @INC in sid, but kept "." in @INC in stable. "." in @INC is not a vulnerability per se, however many modules, including core Perl modules such as Encode and Storable, attempted to load optional modules without sanitizing @INC.
> the bug doesn't seem too serious, it requires that you have write access to the directory running the attacked script
According to https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-1238#c0:
> The most severe example discovered on Debian is that apt-get will load and execute the /tmp/Log/Agent.pm file regardless of the directory it is started from since it automatically changes directory to /tmp.

To reproduce this apt-show-versions needs to be installed.

> 10:45:37 quidam | which would be such a big hole in the first place that makes the exploit barely a thing
https://salsa.debian.org/perl-team/interpreter/perl/commit/10ed0afeb8df1e2fd182526c35cfe626ae673a5b

Lun, 11/18/2019 - 00:47

> "." should not be removed from @INC by default

Would these changes[1] not remove "." from @INC by default?

[1] https://devel.trisquel.info/trisquel/package-helpers/merge_requests/232/diffs

Lun, 11/18/2019 - 18:58

They would not remove "." globally by default. The global removal code is in https://salsa.debian.org/perl-team/interpreter/perl/blob/debian-5.22/debian/sitecustomize.pl which is not included in this diff. However, of course, the changes from [1] remove it locally in the scopes of previously vulnerable modules. I guess that changes to base.pm are the only thing in this diff that is capable of causing breakage. The upstream and Debian 8 include better patches for base.pm: https://salsa.debian.org/perl-team/interpreter/perl/blob/jessie-security/debian/patches/debian/CVE-2016-1238/base-pm-amends-pt1.diff and https://salsa.debian.org/perl-team/interpreter/perl/blob/jessie-security/debian/patches/debian/CVE-2016-1238/base-pm-amends-pt2.diff. I'll try to build Trisquel perl packages with your patched package helper + https://salsa.debian.org/perl-team/interpreter/perl/commit/1490573ff87254b315eded941c99a26a36cc73b3 + https://salsa.debian.org/perl-team/interpreter/perl/commit/4ccea5570132e2c69f0fbf265eabc8ed2f75bbb1 + https://salsa.debian.org/perl-team/interpreter/perl/commit/d24969904210e3d76d311bdb37810bfe2e761e70

Lun, 11/18/2019 - 19:33

Are you able to join this Friday's IRC meeting on #trisquel-dev at 16:00 UTC? It's quidam's decision whether to or not to make these changes, so it would be more efficient to discuss it with him directly. If you can't make the meeting I'll ask him to reply to you here, but it will likely get addressed sooner if you bring it up in the meeting.

Lun, 11/18/2019 - 20:17

> Are you able to join this Friday's IRC meeting on #trisquel-dev at 16:00 UTC?
Yes, most likely I will be able to join.