Bug 10928

perl-Proc-ProcessTable-0.480.0-4.mga2 and perl-Proc-ProcessTable-0.480.0-1.mga3 has been submitted.

CC: (none) => oe

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

CC: (none) => jquelin
Assignee: jquelin => qa-bugs

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

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

Whiteboard: MGA2TOO => MGA2TOO has_procedure mga3-64-ok

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.

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.

Whiteboard: MGA2TOO has_procedure feedback => MGA2TOO has_procedure mga3-64-ok mga2-32-ok

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

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

Whiteboard: MGA2TOO has_procedure mga3-64-ok mga2-32-ok mga2-64-ok => MGA2TOO has_procedure mga3-32-ok mga3-64-ok mga2-32-ok mga2-64-ok

Validating. Advisory from comment 2 uploaded.

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

Thanks!

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Update pushed:
http://advisories.mageia.org/MGASA-2013-0254.html

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED