[coldsync-hackers] Re: Security considerations

[Andrew Arensburger <arensb+CShackers@ooblick.com>]

On 25 Feb 2001, Erik Forsberg wrote:
> I hope nobody gets offended by this message, but.. Has anyone thought
> about the security implications of this? 

	No offense. Please do think about the security applications. I'd
rather fix problems before they're actively exploited.

> I haven't checked the code, so it might very well be the perfect
> example of a setuid() application, but I've seen far to many reports
> of applications using setuid() with security holes not to
> react. Especially since coldsync is a network-enabled daemon.

	The 'coldsync' binary itself is not installed with the setuid (or
setgid) bit set.

	I think that ColdSync is no more dangerous than procmail, or
'talkd', or many other services in /etc/inetd.conf . That is, there is a
risk, but it's not unreasonable.
	The setuid() is there not to increase privileges, but to reduce
them. The only reason ColdSync has to run as root is to be able to
setuid() to an unprivileged user later on.
	What goes on is this: ColdSync starts as root. It establishes a
connection to the Palm and reads the username and userid (which may have
been forged, if the Palm is hostile). It then looks up the Palm username
and userid in /usr/local/etc/palms. This file is created and maintained
on the desktop machine, so it is assumed to be trusted.
	From /usr/local/etc/palms, ColdSync reads the name of a Unix user
(e.g., "arensb"), and setuid()s to that user. The intent is that from this
moment on, ColdSync should no longer be able to do anything that arensb
can't do.

	I see four potential threats:
	1) While ColdSync is still running as root, what can it be tricked
into doing?
	2) Can the 'coldsync' binary be tricked into setuid()ing back to
root? (I think this might be possible, given the semantics of setuid()).
	3) What can the built-in conduit do?
	4) What can other conduits do?

	Threats (1), (2), (3) can be evaluated by reading the code. The
main things to look for are buffer overflows, improper handling of files
with weird characters, and so forth. There may be a few potential buffer
overflows, but all of the ones I've noticed are marked with an XXX comment
in the source.
	Since the "[generic]" conduit is built in to the code, it deserves
special attention. I think the way to try to attack it would be to smash
the stack with a buffer overflow.
	Threat (4) is the one that's potentially most serious. But I don't
think things are too bad: once 'coldsync' fork()s and exec()s the conduit,
its real and effective UIDs are both "arensb", so the conduit can't do
anything that "arensb" can't do. This is a lot like allowing users to run
procmail.
	If the sysadmin wants to disallow all user-defined conduits, ve
can add
	conduit Install, Fetch, Sync, Dump {
		type: */*;
		final;
	}
to /usr/local/etc/coldsync.conf

> Perhaps one could run the coldsync daemon as a special user that's
> member of a special group, and then the individual .palm-directories
> of coldsync-using users could be write enabled for the special
> group. Or something like that. Of course this adds complexity.

	Yup. Just set the Unix user in /usr/local/etc/palms to that user,
and list an appropriate config file for each Palm.

> Something else that would be nice to have is a one-user daemon
> mode where coldsync runs as a daemon for one user on one
> computer. Useful for a standalone workstation. Or is that
> perhaps possible with the current daemon code?

	If you're running 'coldsync' from inetd.conf, you can set the
user that it runs as.
	If you're running it from /etc/ttys, I think you have to let it
run as root, though you can use
	/dev/cuaa0 "su arensb -c coldsync -md" unknown on
which may or may not work.

> I emulate this with coldsync 1.4.6 with a shell script that looks like
> this:
> 
> while coldsync ; do ; done
> 
> Works quite OK, but a daemon would look better :-).

	You're thinking of a standalone daemon. For the longest time, I
wanted to do this, but eventually decided that it was too similar to
'getty' to reinvent the wheel.

	Comments? Questions?

-- 
Andrew Arensburger                      Actually, these _do_ represent the
arensb@ooblick.com                      opinions of ooblick.com!
                        Generic Tagline V 6.01


-- 
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.