Re: Robustness of CoreData against malicious documents?
Re: Robustness of CoreData against malicious documents?
- Subject: Re: Robustness of CoreData against malicious documents?
- From: Cem Karan <email@hidden>
- Date: Wed, 5 Apr 2006 07:39:15 -0400
Both of these comments are related, so I combined them into one.
Apologies if this messes anyone up...
Date: Tue, 4 Apr 2006 12:25:17 -0700
From: Scott Ellsworth <email@hidden>
Could you stuff a checksum in the metadata, perhaps built with an
appropriate public/private key pair? Assuming that the black hats
have not compromised the framework or the sqlite executables, you
could at least be sure that the file you are reading was written by
your app.
If you want the app to write the files, as well as read them, then
you also need to worry about them attacking the app itself to disable
any such checks.
The problem is that we may (eventually) be passing out the DTD that
describes how the app's data model works, specifically so that anyone
that wants to write a complying application, can. I'll admit, the
public/private key method is VERY tempting, because then I can issue
certificates to trusted people only; anyone that wants to send in
data must sign what they are sending. HOWEVER, this has its own
associated costs in upkeep. By making sure my application can parse
the incoming data stream, regardless of whether or not it was signed,
it won't matter if the black hats have written their own app, stolen
a cert, and signed it; my app won't trust the data stream, and it
will parse it 100%, making sure the format is as expected before
passing the data up to higher levels making bad formats moot (there
is always the possibility of someone writing an application that
fails to meet spec in an unusual way; this protects against those
kinds of accidents too)
From: Jim Correia <email@hidden>
Subject: Re: Robustness of CoreData against malicious documents?
On Apr 4, 2006, at 3:18 PM, Cem Karan wrote:
On Apr 4, 2006, at 2:52 PM, Jim Correia wrote:
How do I set this?
http://gemma.apple.com/documentation/Cocoa/Reference/CoreData_ObjC/
Classes/NSPersistentStoreCoord.html
And that kids, is why you should always listen to other people.
Thanks! I'm not sure if it is 100% what I need, but I'll play with
it and see if I can break it.
And can it handle maliciously malformed data?
I don't know - I didn't write Core Data :-)
(e.g., data that someone hand-crafted and passed to my app in the
hopes of getting it to break and execute code rather than just
parse data)
Is this really a legitimate concern? Are you accepting input for your
coredata app on a publicly accessible server? Or is this just an
"ordinary" desktop application?
If it were just an ordinary desktop application, where I had high
trust of the users, I wouldn't have a problem. The eventual idea is
that this may end up on a server somewhere, exposed to the entire
world. And that is the problem; we're a .mil site, and get hammered
by any idiot that wants to show off. Realistically, breaking this
app won't do anything significant, but politically, there would be
fallout, and none of us needs that.
Of all the possible attack vectors, I'm wondering why you are fixated
on this particular one.
Because the rest of the system treats ANY incoming data as pure
binary data that needs to be buffered and passed along. If it
doesn't have the space for the data, it simply kills the connection,
and passes an error back to the app. This portion is where I parse
'pure binary' data; that makes this portion more complicated, and
requires a lot more careful analysis.
Thanks,
Cem Karan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden