Re: NSTableView - populating from C procedure
Am 23.07.2009 um 08:55 schrieb Marco S Hyman: On Jul 22, 2009, at 11:38 PM, Graham Cox wrote: My warning was of a very general nature, and may not apply to your app. But every time you declare buffer space as a stack array, you should mentally consider whether a buffer exploit might be possible there. It was a good warning. Since the author can rarely guarantee that some data field will not be filled from an untrusted source *forever* it is always best to check for and not allow overflow. Why is everyone so fixated on security exploits? You could be causing bugs! E.g. in this case, if the C code assumes a different size for the buffer than the ObjC method calling it (and you're hard-coding the array size instead of using a symbolic constant shared by the two), you may be writing off the end of the array. If you're lucky, you're on 64 bit and overwriting the canary, making your app crash. If you're unlucky, there's a function pointer on the stack that you overwrite with data that is equal to ... oh, I don't know ... the address of a function that deletes the Documents folder's contents, and suddenly the user has lost data. In most cases, though, you'll just be slowly and incrementally corrupting some memory in your app, and half an hour later when that memory is next used, your app will unexplainably crash. Graham Cox wrote: If it checks the buffer size and the string size, it should be OK. Not all dialects of C have historically supported sizeof() for stack- based buffers but I think all modern ones do. I don't think you can use sizeof() on a pointer passed as a parameter, though. That only works on variables in the current scope. That pointer could point at anything, so the compiler has no idea whether it points at the stack or the heap. Even if it generated specialized code for the stack case, what code would it generate for the heap case? sizeof() is independent from malloc(), NewPtr() and all the other allocator schemes the OS knows, sizeof() wouldn't know which one to use. Heck, ANSI malloc() doesn't even have a standard way of determining a block's size. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSTableView - populating from C procedure
On 25 Jul 2009, at 03:56, Uli Kusterer wrote: I don't think you can use sizeof() on a pointer passed as a parameter, though. That only works on variables in the current scope. That pointer could point at anything, so the compiler has no idea whether it points at the stack or the heap. Even if it generated specialized code for the stack case, what code would it generate for the heap case? sizeof() is independent from malloc(), NewPtr() and all the other allocator schemes the OS knows, sizeof() wouldn't know which one to use. sizeof() does exactly one thing, which is return the amount of storage allocated *by the compiler* for its argument. Despite appearances, it is not a function: it's a compiler directive, and compiles to a constant value. For example: char charArray[24]; sizeof(charArray) = 24 int intArray[16]; sizeof(intArray) = 64 char *charArrayPointer = charArray; int *intArrayPointer = intArray; sizeof(charArrayPointer) = sizeof(intArrayPointer) = 4 (8 on 64-bit builds) What's happened here? Taking the sizeof() a pointer doesn't tell you anything about the size of the object it's pointing to - all it can tell you is how big *the pointer itself* is. You can dereference a pointer in a sizeof() expression, but only in a limited fashion: sizeof(*charArrayPointer) = 1 sizeof(*intArrayPointer) = 4 Confused? Keep in mind that *charArrayPointer is equivalent to charArrayPointer[0] - it returns the first element, not the whole original array. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSTableView - populating from C procedure
On Jul 22, 2009, at 10:41 PM, Alexander Bokovikov openwo...@uralweb.ru wrote: where it is said, among other, that NSTableView items may be filled out like this: Tables aren't actually filled with anything. Instead, you provide the table with a data source object that fulfills the table's data needs upon request. getString(rowIndex, buf, len); return [NSString stringWithCString:buf length:len encoding:NSUTF8StringEncoding]; Be aware that this method needs to be *fast*. This might mean caching your values as they are generated, if possible. I.e. is it possible to return a NSString without its preliminary retaining? Re-read the Cocoa memory management guide. +stringWithCString:encoding: does not start with allocate or copy, meaning you don't own it. Therefore you must not release it. Likewise, the method you're implementing doesn't start with allocate or copy, so you must not leak ownership of the returned object. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSTableView - populating from C procedure
Assuming your cstring is null-terminated, you can use [NSString
stringWithUTF8String]
On Thu, Jul 23, 2009 at 2:41 PM, Alexander Bokovikov
openwo...@uralweb.ruwrote:
Hi, All,
This is my first attempt to deal with Cocoa container class, so I have some
unclear points. I've found one of many tutorials here:
http://www.cocoadev.com/index.pl?NSTableViewDataSource
where it is said, among other, that NSTableView items may be filled out
like this:
- (id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn
row:(int)rowIndex {
return [[myTableViewArray objectAtIndex: rowIndex]
objectForKey:[aTableColumn identifier]]
}
My specifics is that the data (strings) are delivered by an external
procedure, located out of ObjC stuff, and returning C-style strings. My
table has only one column. My question is, as usual, about memory manager:
May I write something like this:
exern void getString(int row, char *s, int *len);
- (id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn
row:(int)rowIndex {
char buf[255];
int len;
getString(rowIndex, buf, len);
return [NSString stringWithCString:buf length:len
encoding:NSUTF8StringEncoding];
}
I.e. is it possible to return a NSString without its preliminary retaining?
Or should I add [... retain] to the returning string?
All examples operate by some values, stored in retained structures, like
NSArray. Here my question originates from.
Thanks.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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/kthemank%40gmail.com
This email sent to kthem...@gmail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
Re: NSTableView - populating from C procedure
On 23/07/2009, at 4:25 PM, Alexander Bokovikov wrote: I can it understand, when viruses send something illegal to a webserver, which has flaws in the request processing routine, but in my case it's an internal function, which, of course, should check the buffer size, but how it could be accessible for a virus? If it checks the buffer size and the string size, it should be OK. Not all dialects of C have historically supported sizeof() for stack-based buffers but I think all modern ones do. My warning was of a very general nature, and may not apply to your app. But every time you declare buffer space as a stack array, you should mentally consider whether a buffer exploit might be possible there. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSTableView - populating from C procedure
On 23.07.2009, at 11:52, Graham Cox wrote: BTW, watch out for a potential buffer overflow in getString(...), this is the sort of thing viruses readily exploit. OK, thanks, though I'd like to ask, if it's not a big offtopic, how viruses can exploit my internal function? I can it understand, when viruses send something illegal to a webserver, which has flaws in the request processing routine, but in my case it's an internal function, which, of course, should check the buffer size, but how it could be accessible for a virus? Thanks to all others, who replied. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSTableView - populating from C procedure
On Jul 22, 2009, at 11:38 PM, Graham Cox wrote: My warning was of a very general nature, and may not apply to your app. But every time you declare buffer space as a stack array, you should mentally consider whether a buffer exploit might be possible there. It was a good warning. Since the author can rarely guarantee that some data field will not be filled from an untrusted source *forever* it is always best to check for and not allow overflow. The function getString in the sample code might be safe today, but will it be safe after the nth code change in the future? Does it get or generate its code as a result of user action? Will it always be that way? Easier to ensure that an overflow can't cause harm today then to worry about all future failures. Remember, most security problems stem from abuse of simple bugs. /\/\arc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
Re: NSTableView - populating from C procedure
On 23.07.2009, at 12:55, Marco S Hyman wrote: On Jul 22, 2009, at 11:38 PM, Graham Cox wrote: My warning was of a very general nature, and may not apply to your app. But every time you declare buffer space as a stack array, you should mentally consider whether a buffer exploit might be possible there. It was a good warning. Agree completely with all you said below! Indeed, I'm doing a check. Since the author can rarely guarantee that some data field will not be filled from an untrusted source *forever* it is always best to check for and not allow overflow. The function getString in the sample code might be safe today, but will it be safe after the nth code change in the future? Does it get or generate its code as a result of user action? Will it always be that way? Easier to ensure that an overflow can't cause harm today then to worry about all future failures. Remember, most security problems stem from abuse of simple bugs. /\/\arc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
NSTableView - populating from C procedure
Hi, All,
This is my first attempt to deal with Cocoa container class, so I have
some unclear points. I've found one of many tutorials here:
http://www.cocoadev.com/index.pl?NSTableViewDataSource
where it is said, among other, that NSTableView items may be filled
out like this:
- (id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn
row:(int)rowIndex {
return [[myTableViewArray objectAtIndex: rowIndex] objectForKey:
[aTableColumn identifier]]
}
My specifics is that the data (strings) are delivered by an external
procedure, located out of ObjC stuff, and returning C-style strings.
My table has only one column. My question is, as usual, about memory
manager: May I write something like this:
exern void getString(int row, char *s, int *len);
- (id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn
row:(int)rowIndex {
char buf[255];
int len;
getString(rowIndex, buf, len);
return [NSString stringWithCString:buf length:len
encoding:NSUTF8StringEncoding];
}
I.e. is it possible to return a NSString without its preliminary
retaining?
Or should I add [... retain] to the returning string?
All examples operate by some values, stored in retained structures,
like NSArray. Here my question originates from.
Thanks.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
Re: NSTableView - populating from C procedure
On 23/07/2009, at 3:41 PM, Alexander Bokovikov wrote:
My specifics is that the data (strings) are delivered by an
external procedure, located out of ObjC stuff, and returning C-style
strings. My table has only one column. My question is, as usual,
about memory manager: May I write something like this:
exern void getString(int row, char *s, int *len);
- (id)tableView:(NSTableView *)aTableView
objectValueForTableColumn:(NSTableColumn *)aTableColumn
row:(int)rowIndex {
char buf[255];
int len;
getString(rowIndex, buf, len);
return [NSString stringWithCString:buf length:len
encoding:NSUTF8StringEncoding];
}
I.e. is it possible to return a NSString without its preliminary
retaining?
Or should I add [... retain] to the returning string?
Yes, that is the correct thing to do - you don't own the string, so
you shouldn't retain it.
BTW, watch out for a potential buffer overflow in getString(...), this
is the sort of thing viruses readily exploit.
--Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
