This is rather crappy QA or the lack of verification of the QA process at Apple. I really hope they pick up the slack they have been forming over the past ~5 years, it's starting to get predictably bad.
Could also be bad hiring. Mistakes do happen, sure, but the only instances in which I personally noticed a dev accidentally slipping personal data into a log file, they tended to have other issues in their work like an unusually high bug count.
There is a well-known "triangle" of [money, quality, time]. You can fix two factors at most, but that means a third factor will suffer. This decision is made by the management, whether or not they realise this triangle exists.
Language can be a contributing factor. In a language that includes a generic dump routine that can convert an arbitrary data structure into a useful string representation, or that makes it easy to write such a routine if one is not built in, people tend to use that facility to convert things for logging.
Then later someone adds a sensitive field to some data structure, and if anything is logging that structure it will pick up the new field.
In a language like C, where I don't think you can write a nice dump_arbitrary(void * data) function, and so if someone wants to log something they have to write a routine specifically to deal with that particular thing, when someone adds a sensitive field to a struct it does not automatically go into logs. It only goes in if someone specifically updates the logging code to know about the new field.
> In a language that includes a generic dump routine that can convert an arbitrary data structure into a useful string representation, or that makes it easy to write such a routine if one is not built in, people tend to use that facility to convert things for logging.
I'm reminded of one such system I did in C#, where I knew ahead of time that some fields passed to the logger may contain user data. I added a [Sensitive] attribute that a property accessor can be tagged with, and the logger reflected upon this and replaced contents with a placeholder if it was there.
So I don't really buy that as too compelling an excuse. People who are mindful, careful about what they are doing, and respectful of the user will engineer, document, and evangelize solutions.
I'm starting to actually believe I'm observing the effect of the loss of one staff member -- Jobs.
Something like this might happen once. Under Steve, it damned well wouldn't happen twice.
Also, most places, even ones with a lot of money, don't really respect and won't pay for QA. It gets outsourced; they try to get the developers to do it; etc.
In today's environment, there's no overriding incentive.
Back to Jobs; there was an incentive. You didn't want to end up on his shit list.
P.S. I never knew Steve Jobs, although he was involved with an institution I was at, back in our younger years. My impression is from what I've read about him, and how I've seen Apple changing since his death.
This Steve Jobs fetishism makes no sense. Are people seriously implying that bugs never happened under his leadership? Am I the only one who remembers the festering dumpster fire that was iTunes under Steve Jobs?
I didn't -- past a certain, limited point, perhaps -- for a number of years subsequent to his passing.
Now, I'm starting to wonder.
The hardware gains have been pretty incredible, with the custom ARM systems. The privacy stance seems (because I don't really know it in depth) to be a welcome turn.
But some other aspects are seeming to slip, repeatedly. For one thing, there seem to be more and more complaints and problems with regard to the software.
And it took Apple too long to take ownership of some hardware problems, until they figured out the magnitude of the negative PR.
Jobs wasn't perfect. But his ability to be critical and call BS and say "fix it", was very useful.
(Even if iTunes never benefited. I've never used it, except to help a friend digitize some personal media, one time, where the results landed in iTunes, IIRC. I wasn't thrilled with it (kind of frustrating and limited interface, as I recall), but we were able to get the job done.)
Well, maybe I've succumbed -- belatedly -- to the reality distortion field.
But damned if I'd let a product ship while it was logging passwords.
Simple QA is to scan log files for anything that shouldn't be there. It requires no more than defining those values, pattern matching, and patience while it churns.
This is actually a testing pattern that fits well into automation. As opposed to a lot of the "how do we hook into the GUI, so we can click stuff" automated QA I've seen.
How would this be caught in typical QA? Unit tests, acceptance tests, and general "usage" would all miss this bug. The only way this will be caught would be code review (is that QA?), or auditing all log files.
What saddens me the most is that there are a lot of "small" issues that are found now (and by small I don't mean that they are not critical or important, just that they are a small feature/% of the whole), and we forget that Apple teams managed to upgrade the whole filesystem to APFS on this version of macOS, which is a huge feat. We haven't heard that many problems with the filesystem itself or with the upgrade, which is truly impressive at that scale and complexity.
Blindly updating a work machine to a brand-new release isn’t a good idea regardless of the OS.
In High Sierra’s case, it took until the .2 release before we were fine with it.
Keep in mind that IT departments (including myself here) like to have important things to say about software updates, especially when it’s about the OS that requires a lot less IT work. :)
I dunno. It's been years since I worried about updating a workstation to the latest Debian stable. Or server for that matter. So it's certainly not a question of resources.
[ed: not that Debian hasn't had issues. Broken openssl/ssh key generation being perhaps one of the worst security issues in recent memory]
Exactly, iOS and Mac developers excepted, very little productivity gain comes from updating to the latest version of the OS right away before all the compatibility kinks have been worked out.
A lot of people have a (completely understandable) weakness for the latest and greatest though.
Exactly what just happened to me: I was planning to stay on 10.12 for some more time, but now I need to do some testing on the new iPad 6, which is provided with iOS 11.3 in the box, which is only supported by the new xcode 9.3, which only works on macOS 10.13... #damnit
> It seems weird that two OS divisions would really be that different.
It’s not weird. The lack of a first class sandbox model on desktop certainly makes its security properties and threat model “different” than those of the iPhone.
Yes both are built around XNU and both use APFS, but the “surface area” of attacks is far different across the platforms. For all we know, APFS bugs like these exist in iOS but haven’t been found because finding them would require rooting the phone to circumvent the sandbox model.
Apple doesn't have a dedicated MacOS development team anymore and laptops are normally harder to steal/gain access than phones. They have had quite a few security vulnerabilities in the past few months that anyone with physical access could exploit.
This is just embarrassing. It's not like Apple is spread so thin because of poor sales or a corporate shake up. There's really no excuse for all of these core bugs.
The iPhone was so successful it ate the company. Everything else is an afterthought to "sell more phones." Security takes a back seat to animojis and better cameras.
The mobile market has plateaued, so this will harm the company long term. Success defines and then limits you.
This is just nonsense. I worked at Apple in the years after the iPhone launch and nothing changed. And companies are comprised of many teams and so they are more than capable of working on more than one thing at once.
Now as I've mentioned before the real blame can be attributed to the switch to Agile. There has been a noticeable increase in the frequency of OSX/iOS point releases since then. But also a subsequent decrease in quality.
Apple has realised this which is why there are focusing more on quality and we have seen already the results of this with the last OSX/iOS update where we've never had a X.6 point release for a while.
Thanks! That's interesting. I've always thought and always heard that Mac had ceased to be important to Apple and was almost EOLed due to the iPhone, but your take is also very plausible.
I have yet to see an Agile/Scrum organization that doesn't have runaway technical debt. The entire Agile/Scrum process discourages the "craft" aspects of development unless they are explicitly included in each sprint, and a very few managers do that because these aspects are hard to tie to a specific customer story.
iPhone security is great, but they had a really embarrassing issue in the backups around iOS 10 - where they were sha hashing the backup password and storing the result in the backup. (This was in addition to the password handling which was a properly designed PBKDF2, etc). I don’t think their security skills are very evenly distributed. Perhaps they are growing the dev team too quickly and the experienced devs are spread too thin.
iOS is probably a larger target, so it's pretty clear that the obvious choice is to put most of your security talent there. That being said, core OS fixes propagate to both systems due to their shared codebase.
Before we just jump on Apple we should probably see if we can recreate the issue.
The article stated that another user could not replicate this issue and the original researcher was also unable to replicate after a possible stealth update.
I already ran shred on the log to erase all traces, so I can't be more specific, but I know I did a fresh install (not an upgrade) of the whatever the latest High Sierra was at the time in mid-November...
There are definitely some issues with files ending up with contents of other files, particularly with sparse files and nearly full disks, presumably due to new allocations not being zeroed. Hard to replicate, but not impossible. We filed a bug and it was closed as a duplicate. Possibly fixed in todays 10.3.4 release, can't confirm yet.
It's hard to tell, but with the application sandboxing in iOS, it is unlikely that any regular app could access log files.
AFAIK, on macOS, sandboxed applications cannot access logs either. But applications are moving out of the app store, because Apple hasn't really accomodated Mac developers.
If the environment variable HISTCONTROL contains the keyword ignorespace, then commands starting with a space won't be saved in the history list; usable in situations like this. (Of course, the command will be visible in the process list, so if you are on a shared system, it is still not a good idea)
Good illustration of why command line utilities should not take passwords as a parameter. They should always be provided as prompted input or via a pipe if it needs to be scripted.
I think it's impossible to talk about "most secure" with out being more clear who you're trying to protect against.
Rogue apps, hackers, law enforcement and state actors are 4 different attack vectors that jump to mind that all have different mitigations.
We'd also have to talk about how usable you expect the phone to be afterwards; for example if to make it secure we have to disable wifi, mobile-data and apps, is there any point in having a smart phone in the first place?
I, personally, am much more comfortable using an iPhone than any other mobile phone. I have very little trust in Android phones, especially one that has > 0 apps from the Play store installed.
(I'd still be using a Blackberry if they had any decent offerings, however.)
