[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Apr 2015 14:40:32 -0400 (EDT)
From: cve-assign@...re.org
To: fweimer@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, keescook@...omium.org
Subject: Re: kernel: fs.suid_dumpable=2 privilege escalation
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> http://lwn.net/Articles/503682/
An alternative perspective might be:
If any program is designed to execute code in a file (or perform
a similar security-relevant action on the contents of a file)
on the basis that the file exists in a specific directory, then
the program is responsible for reasonably distinguishing between
"intended files" and "stray files." The stray files must always
be ignored.
You had mentioned content-based recognition of stray files, i.e., a
program should not choose a loose parsing strategy that results in
finding an executable item within a core dump. However, there can also
be name-based recognition.
An example of a program roughly consistent with this is run-parts -
http://manpages.debian.org/cgi-bin/man.cgi?query=run-parts&manpath=Debian+7.0+wheezy&format=html
"the names must not end in .dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp"
Relative to the http://www.securityfocus.com/archive/1/439869 exploit
code for CVE-2006-2451, this would mean: cron is required to recognize
/etc/cron.d/core (regardless of content) as a stray file and ignore
its existence. This would similarly apply to other cron-like programs
that use the /etc/cron.d directory, or a different directory in an
analogous role.
The possible advantage of this perspective is that it covers the case
of root having a current working directory of /etc/cron.d while
running a non-setuid program. If that program happens to dump core, it
would seem to violate reasonable expectations for /etc/cron.d/core to
be processed as an intended file. Obviously the system could have an
unusual configuration in which /proc/sys/kernel/core_pattern has an
arbitrary unqualified pathname, not the usual "core" string, but maybe
that needs to be specified in the core_pattern documentation. For
example: "Some applications are designed to recognize core and the
core\..* pattern as stray files. For this reason, it is less safe to
choose arbitrary unqualified core_pattern values."
There hasn't been any final decision by MITRE. There might be multiple
CVEs, e.g.,
- a Linux kernel CVE because unprivileged users can trigger creation
of large files in otherwise-protected directories, leading to (at
least) denial of service - consuming disk space on arbitrary
filesystems without quotas, generating network traffic to
slow/expensive remote filesystems, etc.
- one CVE for each independent cron codebase that does not skip the
/etc/cron.d/core filename and similar filenames, and has a parsing
approach with a risk of executing something
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVMAGSAAoJEKllVAevmvmsHz8IALI7eQ7RLCTbZxtZy+E3ApMW
PIJ95fUQn/66PtCA9D7u85g4wQntEUcKScFSI2NvP0vrdz1LEI+WgEaLzmcuUqKr
4RqsYz5nBXYGyyzrhCp8lMBiBztarSvTzvVk8fUdsSwKvq8FAq5ltXmmukVnTlza
qRvZyXFHnJu4VldO+CGlrb1K19vEMKzrIR8av2UcWwYLl5jaefuGpoKuS4W41m9l
PZrj60N3SnFwtVCNml5fGyYWapcaLZ/MKerZu27ICOD4X71ZSzOWCPQahSWxuQJx
vHO+xSfaKTlSzga6AMOfNMxh/JA1P1Dk8m9hVxlGRIlid2WNlMBwnUQJC2miw20=
=YRoX
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
