LWN: Comments on "Denial of reality vulnerabilities"

Denial of reality vulnerabilities

csamuel — Mon, 24 Jul 2006 09:19:31 +0000

Hear hear! Well said JC..

What of cron?

Cato — Fri, 21 Jul 2006 05:59:28 +0000

Exactly - the fact that cron can execute strings found in the middle of core files is a security issue and should be fixed at the same time.

What of cron?

robbe — Thu, 20 Jul 2006 08:11:57 +0000

> but there are plenty of programs that execute scripts located in particular
> directories of /etc"

Care to name a few affected programs/services?

Things that execute everything in a directory (e.g. /etc/rcX.d) are not vulnerable, because core files are not executable. I tried feeding one to bash, dash, and zsh all bombed out with errors (bash's being most wise).

There may be programs as stupid as cron, but they should be fixed, if only in the interest of safety (guard against errors).

Denial of reality vulnerabilities

Wol — Thu, 20 Jul 2006 08:08:10 +0000

If the author HADN'T realised, then he clearly hadn't read the initial advisories, and shouldn't have been writing the official advisory.

mjcox said the first announcement on the private security mailing list described it as a privilege escalation problem.

Cheers,
Wol

What of cron?

mjthayer — Thu, 20 Jul 2006 07:59:06 +0000

Perhaps part of the problem here is just that too many privileges are
given to system tasks by default. Capability (as in EROS etc) fans would
certainly say so, but I think that even the possibilities available in a
standard Linux system are not being fully utilised.

For instance: a cron job to process man pages does not have to run as
root. If the ownership of the man pages is set to user "man", that job
can be run setuid man. cron itself can run setuid - to something which
only has the privileges to execute those setuid cron scripts.

I think the same could be applied to a lot of system daemons and would
result in a somewhat safer system. How many processes really need to run
with root privileges? Most just need access to a subset of files.

What of cron?

hein.zelle — Wed, 19 Jul 2006 07:25:54 +0000

Has this behaviour of cron led to any separate security advisories / fixes yet?

What of cron?

hppnq — Fri, 14 Jul 2006 05:23:36 +0000

[Nice, my own thread.]

Well, investigating a bit more turns up that indeed, dumping core in /etc/cron.d is sufficient: cron really doesn't care at all what files are called in /etc/cron.d. OMG. OMG. OMG. Jon, you were right as always.

(But really, cron's security model is *unbelievably* stupid.)

Denial of reality vulnerabilities

giraffedata — Thu, 13 Jul 2006 20:16:34 +0000

This editorial seems to be arguing with somebody, but whom?

I assume the descriptions of the bug as a DOS are just errors. If the author had realized there's a way to exploit it to get privilege escalation, he would have written it up that way. Is someone still claiming the original description is appropriate?

If it's just an editorial against making mistakes, there's not much point -- it's preaching to the converted.

What of cron?

hppnq — Thu, 13 Jul 2006 19:31:51 +0000

I just didn't investigate whether cron works as designed in that case.

Yup, it does. So also in the /etc/cron.d case, a cracker would at least need to be able to manipulate the core dump's filename as well. Which requires root privileges on my system.

Again, this bug is trivially exploitable. But not by just dumping core in /etc/cron.d.

What of cron?

hppnq — Thu, 13 Jul 2006 18:26:36 +0000

Yes, that's what I meant. I just didn't investigate whether cron works as designed in that case. ;-)

(By the way, I did not mean to make the problem look any less serious than it is, though. Patch!)

Exploited

mp — Thu, 13 Jul 2006 18:15:13 +0000

Apparently this very vulnerability was used to gain root access in the recent compromise of gluck.debian.org.
http://lists.debian.org/debian-news/debian-news-2006/msg0...

What of cron?

corbet — Thu, 13 Jul 2006 18:11:15 +0000

/etc/cron.d is a very different place, it has nothing to do with per-user crontabs at all.

What of cron?

hppnq — Thu, 13 Jul 2006 18:08:35 +0000

Cron gets the username from the filename, not the actual ownership of the file. (At least, on a default Dapper, this happens for files in /var/spool/cron/crontabs, where they end up if edited through crontab -e, for instance. Newer incantations seem to expect a username on the cronjob line.)

If the user "core" does not exist, a crontab -- at least, in /var/spool/cron/crontabs, haven't investigated /etc/cron.d and friends -- called "core" will be ignored by crond and an error message indicating the failure will be logged; otherwise, its jobs, if any, are run as the user core.

So if a user without root privileges can cause core files to be called "root", you're in trouble. On my default Dapper, this cannot be easily done -- but YMMV. ;-)

Oh, and yes, my Dapper also checks whether the file owner is actually the user indicated by the crontab filename. Phew. ;-)

What of cron?

spitzak — Thu, 13 Jul 2006 17:57:09 +0000

But most of those programs would get an error on the first "command" it found in the file of garbage and quit at that point, never able to reach the embedded command.

I would think a program that keeps parsing text from the file, ignoring errors no matter how bad they are, is a security hole, as this shows. I would suspect that not just cron is at fault, I would look at every older Unix utility.

What of cron?

iabervon — Thu, 13 Jul 2006 17:55:01 +0000

I'd say it's a privilege escalation kernel exploit to let non-root users write to o+rx o-w directories, generating a root-owned file, even if the filename and much of the contents can't be chosen arbitrarily.

What of cron?

cventers — Thu, 13 Jul 2006 15:36:05 +0000

Well, the issue is that prctl() can be used to set your program such that
its core files will be written by root, regardless of who started it.

The rationale behind that was that you might have a program that you want
to be able to debug but that might be handling sensitive data, so prctl()
lets you say "create a core file that _only_ root can read".

So the denial of service thing is definitely true. The cron interaction
just plain sucks.

What of cron?

Thalience — Thu, 13 Jul 2006 14:54:37 +0000

Furthermore, are the core dump files owned by the user, or by root?

If the core file is still owned by the user who ran the program, it seems like a very bad idea for cron to read files not owned by root from /etc/cron.d/.

What of cron?

cventers — Thu, 13 Jul 2006 14:40:23 +0000

Yeah, it's not the kernel's fault that cron trusts any garbage you throw
at it. So I'd say the _kernel_ problem is a denial of service issue, but
the /distributions/ now have privilege escalation bugs to fix.

What of cron?

droundy — Thu, 13 Jul 2006 14:39:27 +0000

Cron is a trivial example, but there are plenty of programs that execute scripts located in particular directories of /etc (although perhaps not so often), so a bug that allows users to dump files in directories where they have no permissions I would say is inherently a priviledge escalation bug.

Yes, cron could be more careful, but on the other hand, relying on unix permissions to restrict users doesn't seem like an inherent security flaw.

What of cron?

lysse — Thu, 13 Jul 2006 14:19:12 +0000

Perhaps I'm missing something here, but couldn't it be regarded as a bug in cron that it doesn't do a basic sanity check on its configuration files, to ensure that they are actually text files...? In which case, what turns the security problem from a DoS into an easy root-hole is the interaction of two bugs, rather than either bug in isolation... ouch.

Debian

paravoid — Thu, 13 Jul 2006 12:32:39 +0000

Debian's stable is unaffected by this issue (2.6.8 without a backported bug).
testing (etch)/unstable's 2.6.16/17 are both vulnerable, not for long I presume.

Denial of reality vulnerabilities

tres — Thu, 13 Jul 2006 10:28:51 +0000

Actually it appears to have been fixed almost a week ago. Right about the time of disclosure.

Thu Jul 6 23:33:57 2006 UTC (6 days, 10 hours ago) by dsd
Update to Linux 2.6.16.24 for coredump privilege escalation security fix

Fri Jul 7 10:20:12 2006 UTC (5 days, 23 hours ago) by dsd
Update to Linux 2.6.17.4 for coredump privilege escalation security fix

Denial of reality vulnerabilities

tres — Thu, 13 Jul 2006 10:24:05 +0000

Gentoo appears to be fixed. CVS Changelog entries:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/sys-kernel/gent...

Denial of reality vulnerabilities

cjwatson — Thu, 13 Jul 2006 09:30:10 +0000

Martin Pitt's improved the Ubuntu advisory text now at http://www.ubuntu.com/usn/usn-311-1, although it's too late to fix the e-mail.

Timeline

mjcox@redhat.com — Thu, 13 Jul 2006 07:25:14 +0000

To clarify on the article text here is the timeline of discovery

19 June 2006: Red Hat security team first aware of issue.

21 June 2006: Red Hat notified kernel security team and vendor-sec (private list which other Linux vendors security teams take part in) under embargo. We gave our working exploit showing this was a privilege escalation flaw to these groups.

06 July 2006: Embargo lifted

Denial of reality vulnerabilities

dune73 — Thu, 13 Jul 2006 06:49:45 +0000

Good journalism puts the finger where it hurts. This is an example of good journalism. Thanks.

Denial of reality vulnerabilities

mattdm — Thu, 13 Jul 2006 03:32:32 +0000

As of early evening Jul 12, there's 2.6.17.4 kernel updates in the testing area for Fedora Core 4 and 5.