Answer:
Never trust any data that you did not generate yourself and are 100%
certain it is bug free.
Meaning:
Don't process it at all ever until you run sanity checks against it.
Trust is an entirely different animal.
Thanks,
Barry
On May 29, 2010, at 4:42 PM, Michael Ash <[email protected]> wrote:
On Sat, May 29, 2010 at 3:04 PM, Jens Alfke <[email protected]>
wrote:
This is rapidly heading off-topic, but:
On May 29, 2010, at 4:15 AM, Michael Ash wrote:
Man-in-the-middle: if I execute the attack the first time you talk
to
a given peer, you have no way of detecting me.
This is avoided using an out-of-band exchange of a secret over a
trusted
channel (direct line-of-sight, voice, etc.) The common “enter this
4-digit
number on the other device” task (e.g. pairing your iPhone’s
Remote app with
iTunes) is a type of this. In my Cloudy project the secret was
derived from
a hash of the public key[1]; a MITM would have to find a hash
collision in
real time to spoof it.
Impersonation: I use a legitimate copy to talk to you once. Now we
have two peers which have identified themselves. Afterwards, I
take my
copy of the app and modify it to emit malicious code.
Sure this is a problem, but it’s not a problem of authentication.
If I
decide to trust you, but you’re not trustworthy, that’s a social
problem not
a technical one. Or if your device / account / key is compromised,
you need
a revocation protocol to contain the damage.
If the point you’re making is that you can’t trust the
incorruptibility of
data even if it was received from a trusted source, then we’re in
violent
agreement :) So back to the topic of the thread: passing remote
data to
NSUnarchiver is a security hole. Don’t do it.
I think we both agree overall, but I believe your response above
misses the point. You seem to be concerned with authentication, i.e.
making sure that you're talking to who you think you're talking to.
But authentication is completely orthogonal to trust. Talking about
exchanging PINs and using certificates and such is irrelevant to the
problem at hand.
Mike
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/atri%40me.com
This email sent to [email protected]
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
