Bug 10928 - perl-Proc-ProcessTable new security issue CVE-2011-4363
: perl-Proc-ProcessTable new security issue CVE-2011-4363
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 3
: i586 Linux
: Normal Severity: normal
: ---
Assigned To: QA Team
: Sec team
: http://lwn.net/Vulnerabilities/562195/
: MGA2TOO has_procedure mga3-32-ok mga3...
: validated_update
:
:
  Show dependency treegraph
 
Reported: 2013-08-05 20:24 CEST by David Walser
Modified: 2013-08-22 20:06 CEST (History)
4 users (show)

See Also:
Source RPM: perl-Proc-ProcessTable-0.460.0-2.mga3.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2013-08-05 20:24:45 CEST
Fedora has issued an advisory on July 25:
https://lists.fedoraproject.org/pipermail/package-announce/2013-August/113068.html

The issue is fixed upstream in 0.48.  Mageia 2 is also affected.

Reproducible: 

Steps to Reproduce:
Comment 1 Oden Eriksson 2013-08-15 14:28:22 CEST
perl-Proc-ProcessTable-0.480.0-4.mga2 and perl-Proc-ProcessTable-0.480.0-1.mga3 has been submitted.
Comment 2 David Walser 2013-08-15 14:43:58 CEST
Thanks Oden!

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

Updated perl-Proc-ProcessTable package fixes security vulnerability:

ProcessTable.pm in the Proc::ProcessTable module 0.45 for Perl, when TTY
information caching is enabled, allows local users to overwrite arbitrary
files via a symlink attack on /tmp/TTYDEVS (CVE-2011-4363).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4363
https://lists.fedoraproject.org/pipermail/package-announce/2013-August/113068.html
========================

Updated packages in core/updates_testing:
========================
perl-Proc-ProcessTable-0.480.0-1.mga2
perl-Proc-ProcessTable-0.480.0-1.mga3

from SRPMS:
perl-Proc-ProcessTable-0.480.0-1.mga2.src.rpm
perl-Proc-ProcessTable-0.480.0-1.mga3.src.rpm
Comment 3 claire robinson 2013-08-16 10:12:43 CEST
PoC: https://bugzilla.redhat.com/show_bug.cgi?id=758866

$ perl -MProc::ProcessTable -e 'my $t = Proc::ProcessTable->new(cache_ttys => 1, enable_ttys => 1); $t->table;'

It can be run under strace to see the tmp file path, /tmp/TTYDEVS
Comment 4 claire robinson 2013-08-16 10:53:04 CEST
Testing complete mga3 64

Before
------
$ strace -o strace.out perl -MProc::ProcessTable -e 'my $t = Proc::ProcessTable->new(cache_ttys => 1, enable_ttys => 1); $t->table;'

$ grep tmp/ strace.out
stat("/tmp/TTYDEVS", 0x18f0138)         = -1 ENOENT (No such file or directory)
open("/tmp/TTYDEVS", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3


After
-----
$ strace -o strace.out perl -MProc::ProcessTable -e 'my $t = Proc::ProcessTable->new(cache_ttys => 1, enable_ttys => 1); $t->table;'

$ grep tmp/ strace.out
stat("/tmp/TTYDEVS_12345678", 0x86a138) = -1 ENOENT (No such file or directory)
open("/tmp/TTYDEVS_12345678", O_WRONLY|O_CREAT|O_EXCL, 0666) = 3
Comment 5 claire robinson 2013-08-16 11:56:38 CEST
Testing complete mga2 32

The fix for this doesn't really prevent a symlink attack, it simple adds _12345678 to the filename. not really very random or unguessable. It's worse on mga2, it only adds _1234

$ grep tmp strace.out
read(4, "type='time_t'\ntmpnam_r_proto='RE"..., 8192) = 4880
stat64("/tmp/TTYDEVS_1234", 0x8d780c4)  = -1 ENOENT (No such file or directory)
open("/tmp/TTYDEVS_1234", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = 3
read(4, "9 (kdevtmpfs) S 2 0 0 0 -1 21302"..., 1024) = 141
read(4, "Name:\tkdevtmpfs\nState:\tS (sleepi"..., 1024) = 500

Is there a better fix for this David. If not then it might be worth reporting upstream.
Comment 6 David Walser 2013-08-17 18:22:47 CEST
Looking more into this, it looks like the issue isn't so much that the filename is predictable, it was a race condition in when this could actually be exploited, and that's been fixed.  This appears to be the intended behavior.
Comment 7 claire robinson 2013-08-19 09:27:52 CEST
Testing complete mga2 64

I notice it also changes the way it's opening the file..

Before
------
$ grep tmp strace.out 
stat("/tmp/TTYDEVS", 0x108e138)         = -1 ENOENT (No such file or directory)
open("/tmp/TTYDEVS", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
read(4, "13 (kdevtmpfs) S 2 0", 20)     = 20
read(4, "Name:\tkdevtmpfs\nStat", 20)   = 20

with  O_WRONLY|O_CREAT|O_TRUNC

After
-----
$ grep tmp strace.out
stat("/tmp/TTYDEVS_12345678", 0x1c68138) = -1 ENOENT (No such file or directory)
open("/tmp/TTYDEVS_12345678", O_WRONLY|O_CREAT|O_EXCL, 0666) = 3
read(4, "13 (kdevtmpfs) S 2 0 0 0 -1 2130"..., 1024) = 161
read(4, "Name:\tkdevtmpfs\nState:\tS (sleepi"..., 1024) = 520

with O_WRONLY|O_CREAT|O_EXCL

Perhaps that is the fix, googling O_EXCL suggets it is used to prevent the file being opened if it already exists, so I guess the race exists between the stat and the open. O_TRUNC deletes the contents of an existing file which makes sense as a symlink attack.

http://www.warpspeed.com.au/cgi-bin/inf2html.cmd?..\html\book\Toolkt40\XPG4REF.INF+205

/me learned something new
Comment 8 claire robinson 2013-08-19 09:45:38 CEST
Testing complete mga3 32

It changes from..
open("/tmp/TTYDEVS", O_RDONLY|O_LARGEFILE) = 3

to..
open("/tmp/TTYDEVS_1234", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = 3
Comment 9 claire robinson 2013-08-19 09:51:29 CEST
Validating. Advisory from comment 2 uploaded.

Could sysadmin please push from 2 & 3 core/updates_testing to updates

Thanks!
Comment 10 Thomas Backlund 2013-08-22 20:06:32 CEST
Update pushed:
http://advisories.mageia.org/MGASA-2013-0254.html

Note You need to log in before you can comment on or make changes to this bug.