Re: [coldsync-hackers] m500: cannot coldsync

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

On Sat, Sep 22, 2001 at 01:23:45PM -0700, David A. Desrosiers wrote:
> > In the past, the system password has been used only to protect the Palm
> 
> 	I've written my results on this discovery back in July.

	Thanks for the pointer. At some point, I should really
resubscribe to the various Palm under Unix mailing lists.

> 	http://hcirisc.cs.binghamton.edu/pipermail/pilot-unix/2001-July/004238.html
> 
> 	..where I describe the reverse engineering of the PalmOS4 password
> and discuss several vulnerabilities in this approach.

	Maybe I'm being stupid, but I think I need things spelled out
for me. In your July message to pilot-unix, you said:

: 	The sixth byte in the packet is different also, from 0x37 to
: 0x27, which probably be a packet sent from the desktop to say "Hey,
: I'm about to send you an MD5 password now, get ready to accept it".
[...]
: 	All we now have to do is move some code into dlp.c so that it
: includes a quick detection for the password being set on the device,
: and then either prompt the user for the password, or just send a
: normal packet without the password.

	This seems to imply that the desktop can bypass the
password-protection simply by not sending a password. Is this correct?

	Or does the Palm say, "Here's the md5 hash of my password.
Please make sure it's correct before you ask me for any data." If so,
then this is tragically wrong.

	Mainly, I think I'm missing the context of the dump that you
sent out. It looks like the first "ritual" packet sent by the desktop
during a network HotSync. Do you know what the structure of these
packets is?

> The problem with this
> is that if we "bypass" this and allow users to sync anyway, we could be
> putting ourselves in a legal tangle, as possibly stated in the DMCA:

#include <dmca/std_grumble.h>

> 	..and of course there is a design approach around this. When a
> password is set on the device, you can require that the user enter their
> password at a shunted password prompt, which will then store an md5 of that
> entered password, compare it to the 16 bytes passed in the frame, and if it
> matches, you're ok, and if not, don't sync.

	This isn't entirely applicable to ColdSync, since it is
supposed to run without user intervention. The obvious solution is to
store the password in a file (preferably not the config file).
	Yes, this violates the "never write down your password" rule,
but there's plenty of precedent. The one that springs to mind is
various PPP daemons that read the user's password from a file in the
user's home directory. Heck, even Kerberos stores its holiest of
holies, the realm administrative password, in plaintext in a file.
Here, you're relying on the underlying OS to prevent unauthorized
users from reading the file, and on physical security to prevent
unauthorized people from getting at the machine. So I'm inclined to
think that if it's good enough for Kerberos, it's good enough for
ColdSync.
	It might also be desirable to check the permissions on the
file containing the password (and the directory it's in, and its
parent directory, and its parent directory, and all the way up to /).

> The approach to storing this, of
> course, is definately not to store the hash itself in a the .rc file, but
> rather store a combination hash of the Palm UserID and DeviceID or
> something, along with the password. To truly be secure, you'd rewrite the
> md5 each time it was sync'd with a combination hash of LastSyncTIme and
> UserID or some such, so it is always changing, and someone who picked up
> your .rc file could not "have" your password.

	I'm not sure how this would work without human intervention.

> 	In any case, you can also ignore the frame, and skip over it, but
> that could get ugly. Passworded Palm devices which could be sync'd anyway,
> despite having a password set. I can see that being a politically ugly
> battle with Palm.

	You make it sound as if even a well-behaved program could
accidentally sync, simply by not being aware of the fact that password
protection exists.
	I'm imagining an open bank vault with a sign saying, "Please
do not enter unless authorized."

> If we come across as
> "white hats" in this, showing that we're trying to help them maintain a
> secure environment, then we're on their good side. Just a tip.

	Agreed. I don't know about anyone else, but I don't want to
break or bypass security; I just want to sync my stuff.

-- 
Andrew Arensburger                      This message *does* represent the
arensb@ooblick.com                      views of ooblick.com
     Coming soon: Mouse support for Turbo-EDLIN under Windows XP!
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.