| |||||||||||||
What of cron?What of cron?Posted Jul 13, 2006 14:19 UTC (Thu) by lysse (guest, #3190)Parent article: Denial of reality vulnerabilities
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.
(Log in to post comments)
What of cron? Posted Jul 13, 2006 14:39 UTC (Thu) by droundy (subscriber, #4559) [Link] 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? Posted Jul 13, 2006 17:57 UTC (Thu) by spitzak (guest, #4593) [Link] 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? Posted Jul 21, 2006 5:59 UTC (Fri) by Cato (subscriber, #7643) [Link] 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? Posted Jul 20, 2006 8:11 UTC (Thu) by robbe (guest, #16131) [Link] > 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).
What of cron? Posted Jul 13, 2006 14:40 UTC (Thu) by cventers (subscriber, #31465) [Link] Yeah, it's not the kernel's fault that cron trusts any garbage you throwat 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? Posted Jul 13, 2006 17:55 UTC (Thu) by iabervon (subscriber, #722) [Link] 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? Posted Jul 13, 2006 14:54 UTC (Thu) by Thalience (subscriber, #4217) [Link] 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? Posted Jul 13, 2006 15:36 UTC (Thu) by cventers (subscriber, #31465) [Link] Well, the issue is that prctl() can be used to set your program such thatits 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
So the denial of service thing is definitely true. The cron interaction
What of cron? Posted Jul 13, 2006 18:08 UTC (Thu) by hppnq (guest, #14462) [Link] 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? Posted Jul 13, 2006 18:11 UTC (Thu) by corbet (editor, #1) [Link] /etc/cron.d is a very different place, it has nothing to do with per-user crontabs at all.
What of cron? Posted Jul 13, 2006 18:26 UTC (Thu) by hppnq (guest, #14462) [Link] 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!)
What of cron? Posted Jul 13, 2006 19:31 UTC (Thu) by hppnq (guest, #14462) [Link] 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? Posted Jul 14, 2006 5:23 UTC (Fri) by hppnq (guest, #14462) [Link] [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.)
What of cron? Posted Jul 19, 2006 7:25 UTC (Wed) by hein.zelle (guest, #33324) [Link] Has this behaviour of cron led to any separate security advisories / fixes yet?
What of cron? Posted Jul 20, 2006 7:59 UTC (Thu) by michaeljt (subscriber, #39183) [Link] Perhaps part of the problem here is just that too many privileges aregiven 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
I think the same could be applied to a lot of system daemons and would
|
|||||||||||||