Re: [coldsync-hackers] m500: cannot coldsync

["David A. Desrosiers" <hacker@gnu-designs.com>]

> > If you take someone else's 416-byte hash-containing files, and
> > overwrite those on the Palm desktop, and sync with the UserID of that data
> > (spelled right) on a cleanly wiped Palm, you then get the data on your Palm,
> > and the hash is transported as well. Nasty.
>
> 	This aspect doesn't strike me as being quite as bad: the
> assumption here appears to be that it's hard to steal files from someone
> else's desktop (or at least harder than reading the password from the
> Palm). I would guess that Windows is more secure than PalmOS, which
> sounds reasonable.

	Quite the opposite. Let me elaborate:

	Let's say your boss at work uses his Palm to carry his employees
performance reviews. You know his login name, his full name, etc. on his
Palm, or whatever. You take a Palm, wipe it, and use (whatever ColdSync
provides for this, but..) install-user "John Smith" (assuming your boss'
name is John Smith) and set your Palm to that username. Now, you know his NT
machine is passworded and locked, and his Palm desktop data is also
passworded and locked. You then slap your Palm in his cradle and hit sync.
Since your Palm "matches" the UserID, his desktop sends you his data, and
supplies you with the hash of his password for storage on your Palm. What
you can then do is replace the "Saved Preferences.prc" with one that does
not contain this hash, and sync again, thereby removing the password
protection from the desktop itself (assuming your Palm has the later
timestamp on that change).

	You've now snatched the data from his locked, passworded NT
workstation, with nothing more than his UserID and a blank Palm. I'd see
that as a huge hole. However, publishing this fact, would make Palm clamp
down on that so tightly, that we'd never be able to provide a solution for
it without being in CLEAR violation of the DMCA, or using a binary blob of
one of their DLL files to get at the struct.

> 	So far, I'm leaning toward putting the password (or its md5
> hash) in a separate file, and possibly requiring it to have the
> appropriate mode bits unset.

	Ideally, you should create the storage hash as a combination of two
pieces of data, their supplied password, and some other verifyable piece of
data (UserID is a logical one). When the user sets up ColdSync for the first
time (some sort of ./configure wizard needed?) they can be prompted to sync
their Palm, which can get the UserID from it, and if a password is set,
prompt them for the password. md5 these two, store in the .rc file.

> 	Of course, inevitably someone's dumbass sysadmin will chmod
> 775 /, which means that /homes/, /homes/arensb/, /homes/arensb/.palm/,
> and /homes/arensb/.palm/password can be replaced.

	Which is exactly why the combination hash is the best approach. You
don't get the password, or the usable hash of the password, you get a hybrid
hash. I've said that a third piece of information, the LastSyncTime should
be used here also, to make sure that the hash in the local .rc file changes
at every sync, and if someone gets the .rc file, they will not be able to
tell what the password was. In fact, you can't reverse md5 anyway, since
it's something on the order of 340282366920938463463374607431768211456
(1<<128) possible hashes. You can only compare the results from encoding the
given password to what the Palm expects to see.

> It'll be necessary to override the protection check in cases like
> these. Of course, if an attacker can replace ~/.palm/password, he can
> also replace the config file and tell it to ignore the insecure
> permissions, so the Right Thing would appear to be to make this option
> settable only from the command line.

	The triple hash idea solves this. Although, if you've been locally
compromised, your .pdb files are in the clear too. Palm only uses this
password to *AUTHORIZE* the sync, the data is still in the clear on the Palm
(why didn't they store it in zlib on the palm, grr), transferred in the
clear over the wire (and wireless), and stored on the Windows desktop in the
clear. Dumb. If we control both desktop and client components (conduits), we
should be able to encode the stream in transit and store the data on the
desktop in a format which has been obfuscated by the same hash (or similar
hash) as the user-supplied one. Just an idea, though there are problems with
that approach also.

	We have to be careful of a few things though:

	1. Bypassing the existing encryption
	2. Making it hard for a user to retrieve data if they "forgot" their
	   password.
	3. Hardening this to the point where Palm takes our ideas and
	   implements them at the OS level.

	We have to do at least what they do, on our implementation, and
perhaps extend it a bit, but not make it overly complex or impossible to
use.




/d


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.