Mark Grimes
Is this you? Claim Profile »
1 year ago
in Hot Off The Matasano SMS Queue: CanSec Macbook Challenge Won on Matasano Chargen
One little two little, five hundred and thirty five lil webkit heap overflows -- wait that doesn't flow... so being presumptuous, i'm mystified that local user -> local root context in the second hack is still standing hours later. Not having fuzzed webkit in a loooong time, I'm still under the impression that there are more then enough lurking... have things gotten better?
Still under the tone of presumption, what year is Apple going to adopt heap protection? Maybe the media will cover it (again) that Vista continues to be more secure. Oh well you have to spend time working on securing an OS to secure an OS -- we aren't growing sea monkeys
Still under the tone of presumption, what year is Apple going to adopt heap protection? Maybe the media will cover it (again) that Vista continues to be more secure. Oh well you have to spend time working on securing an OS to secure an OS -- we aren't growing sea monkeys
2 years ago
in Five Reasons To Ignore John Gruber’s OS X Security Punditry on Matasano Chargen
I agree. Cocoa is a better programming environment than Java. But it’s less secure.
To ensure we're speaking the same language here, Cocoa is an api / class library that is written in Objective-C. All two people that used the Java Cocoa Bridge will probably really miss it though...
Java has its own set of nightmares that are just as unwieldy. Such as you should not depend on package scope, not allow serialization/deserialization of classes, not allow cloneable, not consistently signing all your code (mix-n-match attacks) if the additional privileges are not needed... there is a long list to be frank, but primarily extensibility is bad when security is an issue, and I often get the same reaction from people when teaching Java developers secure programming -- that noone is going to abide by the rules of secure coding or at least most of them. Just because Java is a language that should be impervious to buffer overflows (JVM aside) doesn't mean it doesn't have considerably high impact implementation constraints in order to produce secure code.
The Underground Hasn’t Ramped Up Yet
The Win32 API is over a decade old and is well understood by attackers. The MacOS X APIs are not. There is a lag between the publication of the OS and security researchers, and a lag between research results and malware authorship.
In all fairness -- what's to ramp up? You have the most dynamic runtime on the planet in front of you (today), with mach_inject+mach_override / MethodSwizzling (available today)-- There are even how-to's to develop SIMBL and InputManager plugins (also accessible today). The information is out there, but I think non-OSX developers are only really paying attention to familiar ground, the BSD subsystem (Darwin). But to say that Mac OS X APIs are not well understood doesn't really paint an accurate picture at all
The public APIs are WELL understood and documented, Objective-C has been around for over 2 decades and you have a long list of tools you can use to reverse the private ones.
It sounds like what you are saying maybe true, but not for the reasons you describe. People are unfamiliar because they just haven't taken the time, no? Maybe it has to do with this "low percentage" of users comparison... But you can't quantify everyday computer users with those that know how to use computers... As was sound countless times in OpenBSD -- just because there are X number of times more Linux developers doesn't mean there's X number of times the people qualified to audit userland let alone the kernel.
Objective-C has some additional elegance being a superset of C though. For instance, in objc you can send a message to nil (aka NULL) and you get back just that nil... you don't need to constantly ensure you're not passing NULL in the traditional sense of C and risk a null pointer dereference.
Objective-C offers dynamic dispatch, dynamic typing, and dynamic loading, which as a whole is a foreign concept to many-other-language programmers. From a security standpoint, mach_inject+mach_override/Method Swizzling introduced a path to being able to inject code into another process/"subclass" any arbitrary method ... again this is both dangerous and useful... tell me that tools like F-Script Anywhere (or the py equiv) are not entirely useful for debugging and RE'ing. And on that note it's worthwhile to point out that a combination of otoole (yes 'e'), otx, class-dump and sometimes code-dump makes pretty much any protection method written in objc at risk.
“Any scheme accessed via Cocoa calls is vulnerable to attack via an InputManager” and Public-key encryption systems may be especially vulnerable to replacement of the public key, unless it is obfuscated throughout the entire app” which are clearly documented in discussion on CocoaDev:MakingSecureRegistrationCodes.
The capabilities of doing stuff with closed source apps is by far more open to RE then I feel the bar is for other systems (no assembly required -- no pun intended) -- at least in Cocoa context. Given this, no amount of secrecy Apple keeps of their private apis is keeping people from getting under the covers with the OS... perhaps there are not enough OSX people in the security space, but this is has nothing to do with the assets not being there to play with. See F-Script Anywhere for examples where debugging tools can be surpass the capabilities of ivar enumeration via gdb. In F-Script's case you can play with object's in memory as they are, and get out of the weeds a bit.
There are quite a few points that are coming in Leopard which may not hit all the security features you bring forth in Vista offer alternative approaches to trust and validity at least to a more increased level then inundate the user with dialog annoyances until he turns them off (to pick on a single instance of a Vista sore point with me). It's not completely fair to compare an OS that has been out for a 1.5 years with an OS that isn't shipping yet (regardless of release candidate), but Apple does have at least a couple mechanisms for raising the bar... I made this the last statement because there are obvious reasons (NDA) I cannot give supporting arguments.
To ensure we're speaking the same language here, Cocoa is an api / class library that is written in Objective-C. All two people that used the Java Cocoa Bridge will probably really miss it though...
Java has its own set of nightmares that are just as unwieldy. Such as you should not depend on package scope, not allow serialization/deserialization of classes, not allow cloneable, not consistently signing all your code (mix-n-match attacks) if the additional privileges are not needed... there is a long list to be frank, but primarily extensibility is bad when security is an issue, and I often get the same reaction from people when teaching Java developers secure programming -- that noone is going to abide by the rules of secure coding or at least most of them. Just because Java is a language that should be impervious to buffer overflows (JVM aside) doesn't mean it doesn't have considerably high impact implementation constraints in order to produce secure code.
The Underground Hasn’t Ramped Up Yet
The Win32 API is over a decade old and is well understood by attackers. The MacOS X APIs are not. There is a lag between the publication of the OS and security researchers, and a lag between research results and malware authorship.
In all fairness -- what's to ramp up? You have the most dynamic runtime on the planet in front of you (today), with mach_inject+mach_override / MethodSwizzling (available today)-- There are even how-to's to develop SIMBL and InputManager plugins (also accessible today). The information is out there, but I think non-OSX developers are only really paying attention to familiar ground, the BSD subsystem (Darwin). But to say that Mac OS X APIs are not well understood doesn't really paint an accurate picture at all
The public APIs are WELL understood and documented, Objective-C has been around for over 2 decades and you have a long list of tools you can use to reverse the private ones.
It sounds like what you are saying maybe true, but not for the reasons you describe. People are unfamiliar because they just haven't taken the time, no? Maybe it has to do with this "low percentage" of users comparison... But you can't quantify everyday computer users with those that know how to use computers... As was sound countless times in OpenBSD -- just because there are X number of times more Linux developers doesn't mean there's X number of times the people qualified to audit userland let alone the kernel.
Objective-C has some additional elegance being a superset of C though. For instance, in objc you can send a message to nil (aka NULL) and you get back just that nil... you don't need to constantly ensure you're not passing NULL in the traditional sense of C and risk a null pointer dereference.
Objective-C offers dynamic dispatch, dynamic typing, and dynamic loading, which as a whole is a foreign concept to many-other-language programmers. From a security standpoint, mach_inject+mach_override/Method Swizzling introduced a path to being able to inject code into another process/"subclass" any arbitrary method ... again this is both dangerous and useful... tell me that tools like F-Script Anywhere (or the py equiv) are not entirely useful for debugging and RE'ing. And on that note it's worthwhile to point out that a combination of otoole (yes 'e'), otx, class-dump and sometimes code-dump makes pretty much any protection method written in objc at risk.
“Any scheme accessed via Cocoa calls is vulnerable to attack via an InputManager” and Public-key encryption systems may be especially vulnerable to replacement of the public key, unless it is obfuscated throughout the entire app” which are clearly documented in discussion on CocoaDev:MakingSecureRegistrationCodes.
The capabilities of doing stuff with closed source apps is by far more open to RE then I feel the bar is for other systems (no assembly required -- no pun intended) -- at least in Cocoa context. Given this, no amount of secrecy Apple keeps of their private apis is keeping people from getting under the covers with the OS... perhaps there are not enough OSX people in the security space, but this is has nothing to do with the assets not being there to play with. See F-Script Anywhere for examples where debugging tools can be surpass the capabilities of ivar enumeration via gdb. In F-Script's case you can play with object's in memory as they are, and get out of the weeds a bit.
There are quite a few points that are coming in Leopard which may not hit all the security features you bring forth in Vista offer alternative approaches to trust and validity at least to a more increased level then inundate the user with dialog annoyances until he turns them off (to pick on a single instance of a Vista sore point with me). It's not completely fair to compare an OS that has been out for a 1.5 years with an OS that isn't shipping yet (regardless of release candidate), but Apple does have at least a couple mechanisms for raising the bar... I made this the last statement because there are obvious reasons (NDA) I cannot give supporting arguments.
2 years ago
in AquaticPrime Aftermath on toxicsoftware.com
"Any scheme accessed via Cocoa calls is vulnerable to attack via an InputManager" and
Public-key encryption systems may be especially vulnerable to replacement of the public key,
unless it is obfuscated throughout the entire app" which are clearly documented in discussion on CocoaDev:MakingSecureRegistrationCodes shouldn't be the first time these guys have heard this.
I'm quite surprised you are getting such a reaction. While you've taking the time to 'prove it'
and point at a specific product, none of this is new. I suppose this is hush flame as we already know
but if you blog about it people will discover these deep dark secrets that already sit on other public
websites :/
I'm not watching your thread, but I'm sure it is the implementors that have banked on this scheme
that are seeing red as it COULD affect their financials. However I'm sure we all know that if someone
is going to go to the trouble to write a SIMBL/InputManager plugin to runtime circumvent your registration
scheme, they probably won't be ponying up for a license anyway. Most pirates take the use it for free
or don't use it at all mentality.
Otherwise MethodSwizzling is cool and fun :)
Public-key encryption systems may be especially vulnerable to replacement of the public key,
unless it is obfuscated throughout the entire app" which are clearly documented in discussion on CocoaDev:MakingSecureRegistrationCodes shouldn't be the first time these guys have heard this.
I'm quite surprised you are getting such a reaction. While you've taking the time to 'prove it'
and point at a specific product, none of this is new. I suppose this is hush flame as we already know
but if you blog about it people will discover these deep dark secrets that already sit on other public
websites :/
I'm not watching your thread, but I'm sure it is the implementors that have banked on this scheme
that are seeing red as it COULD affect their financials. However I'm sure we all know that if someone
is going to go to the trouble to write a SIMBL/InputManager plugin to runtime circumvent your registration
scheme, they probably won't be ponying up for a license anyway. Most pirates take the use it for free
or don't use it at all mentality.
Otherwise MethodSwizzling is cool and fun :)