auxio

Xed said:

auxio said:

Xed said:

jdb8167 said:

Everyone talking about how Apple was more generous to developers in the past are forgetting what it used to cost to be in the developer program. If I remember correctly it was $1200 (don’t hold me to that). That gave Apple a lot more leeway to be generous to developers. 

Apple was under no obligation to give developers anything other than the DTK (edit: as a temporary rental) for the $500. It was stated very clearly in the agreement for the Universal Quick Start program. Any expectation of free hardware or anything else was always wishful thinking. 

Edit: I looked up some old invoices and the price for the ADC Select program was $499 in 1999 and for the Premier program was $3499. I think you had to be in at least the Select program to be offered a Intel development kit.

I had forgotten that Apple used to charge a lot more money to be a developer. And this was under Jobs so that Cook statement from someone about how Cook is greedy and Jobs was the altruistic savior of humanity  doesn't seem to hold up.

PS: Correct me if I'm wrong, but I seem to recall when IOS development came on the scene they charged for separately for both iOS and (then) Mac OS X dev kits.

I don't remember there being an iOS dev kit.  Only preview versions of Xcode which contained the iOS SDK which could be used to do development on existing iPhones.  Remember that there were no 3rd party apps and no developer SDK for the first version of the iPhone.  So developers already had access to the hardware when they released the SDK.

And IIRC, it was iOS development which caused the developer membership price to come down.

Edit: Found a live blog from the first iOS SDK announcement.  It was a separate download which went into the existing version of Xcode.  But you had to download a beta version of iOS onto your phone.

I found a couple Wikipedia pages that back up my memory of it being $99 for the iOS Developer Program and $99 for the Mac Developer Program, until they merged into the single program for $99. Before that I recall paying $500 per year for the Mac Developer Program, but it did come with some stickers and a T-shirt. LOL

Yeah, that's what I remember too: when the iOS SDK was released, it became a lot cheaper.  So all the people complaining about how Apple gave free iMacs during the Intel transition (which I'm fairly certain were only for Premier level members) don't realize that developers were also paying a heck of a lot more.

Xed said:

jdb8167 said:

Everyone talking about how Apple was more generous to developers in the past are forgetting what it used to cost to be in the developer program. If I remember correctly it was $1200 (don’t hold me to that). That gave Apple a lot more leeway to be generous to developers. 

Apple was under no obligation to give developers anything other than the DTK (edit: as a temporary rental) for the $500. It was stated very clearly in the agreement for the Universal Quick Start program. Any expectation of free hardware or anything else was always wishful thinking. 

Edit: I looked up some old invoices and the price for the ADC Select program was $499 in 1999 and for the Premier program was $3499. I think you had to be in at least the Select program to be offered a Intel development kit.

I had forgotten that Apple used to charge a lot more money to be a developer. And this was under Jobs so that Cook statement from someone about how Cook is greedy and Jobs was the altruistic savior of humanity  doesn't seem to hold up.

PS: Correct me if I'm wrong, but I seem to recall when IOS development came on the scene they charged for separately for both iOS and (then) Mac OS X dev kits.

I don't remember there being an iOS dev kit.  Only preview versions of Xcode which contained the iOS SDK which could be used to do development on existing iPhones.  Remember that there were no 3rd party apps and no developer SDK for the first version of the iPhone.  So developers already had access to the hardware when they released the SDK.

And IIRC, it was iOS development which caused the developer membership price to come down.

Edit: Found a live blog from the first iOS SDK announcement.  It was a separate download which went into the existing version of Xcode.  But you had to download a beta version of iOS onto your phone.

asdasd said:

dewme said:

JustSomeGuy1 said:

asdasd said:

auxio said:

Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.

They aren’t that simple. That’s the problem. They are written in unsafe languages like C and C++ where memory management was up to the code writer. 

True. Though the problem in sudo is considerably more tricky than just a typical use-after-free or similar. Read the original post about the exploit.

Actually, it looks like this exploit takes advantage of vulnerabilities in C stdin processing. This underlying functionality is traceable all the way back to the earliest version of C that most C programmers learned from their trusty and very thin K&R language reference. Over the decades more and more functionality has been layered on top of these “primitive” functions, including the fundamental operation of web servers. 

The real issue imho is that while a lot of underlying legacy code has a long and time tested verification of proper functionality, the code was not designed and has not been updated with sufficient consideration for the existential security threats that have evolved over time. 

Yes, so something like this: 

 char filename[512];

...
filename = getPath(....)

This works until there is a change in the operating system to allow filenames longer than 512, then it is a vulnerability at worst or a crash. Probably something like this happened for the stdln . I don't think these old codebases can be easily updated to handle reference counting.

No, these old UNIX tools don't use C++ since it was only in its inception when they were created.  Not to mention the extra memory overhead made it a non-starter at that time.

As for your example, that's a buffer overflow attack vector.  It's pretty much the top item on the list for security audits: checking all sources of input for possible buffer overflows (or invalid data which could lead to a buffer overflow when parsing it).

As for memory management and an ownership model, see the system Apple uses in their low level C APIs (Core Foundation).

asdasd said:

auxio said:

Given how long these tools have been around (40+ years in some cases), how relatively simple the code is compared to modern software, and the fact that they're used in server environments, I'm very surprised they haven't been fully security audited by now.

They aren’t that simple. That’s the problem. They are written in unsafe languages like C and C++ where memory management was up to the code writer. 

Yup, and I work with those languages because they're the only way to create native, cross-platform applications (core is C++ code, UI layer is native Swift/Kotlin/language du jour).  Memory management isn't hard once you come up with a model of ownership.  And modern C++ has reference counted pointers as part of the standard library, which is essentially what Objective-C (and, by proxy, Swift) has.

But anyways, strategies for dealing with memory management is a bit of a digression here.  The point is that, for smaller apps, auditing all sources of input data for buffer overflow/invalid data attacks, any external tools used for validity, etc, isn't a massive undertaking.  But yeah, it seems like this was something missed in a recent change/addition to sudo, not a security hole which has been in the tool for ages.

mjtomlin said:

auxio said:

I'm thinking that Apple should add some automated testing around this which helps validate the labels

Not possible unless Apple can install software on the developer's servers to monitor what user data is passed onto 3rd parties from there. Apple can only look at the app code and see what it is doing, and even then it is extremely difficult to follow the path any user data takes thru the app. Monitoring network access and transmission is trivial, but knowing exactly what data is being sent is not, especially with an automated system.

It most certainly is possible.  Any data transmitted over the network from the device on which testing is occurring to the 3rd party can be intercepted and analyzed.  And if it's being encrypted before it's sent over the network, they can simply intercept the encryption APIs which are being used and analyze the data at that level if they need to.  You do realize that Apple is creating the entire platform on which these apps run?