With no disrespect to the developers at Apple, et al, each one of these problems that goes viral before reaching “proper” channels is a well-deserved slap in the face of these behemoth organizations.
Perhaps, if the entire tech community regards Apple as a joke, they will start paying attention.
“Responsible disclosure” is great stuff for creating a culture of free outsourcing of tech companies’ most imporant feature (security) to the same people that paid those companies thousands of dollars for that privilege.
Responsible disclosure is about preventing the bug from being exploited before it can be fixed. Knowing about this bug doesn't help me compromise someone else, but it does help me avoid getting compromised.
Only by casual hackers. The pros will probably have been exploiting the flaw for weeks or months against gainful targets.
If there is a reasonable end-user workaround against the vulnerability then I'd argue it's more responsible to publish early and widely than to wait for the vendor.
It becomes greyer if there is no workaround. I'm not sure what I'd support in that case.
The compromise is that I accidentally type my password into Slack and send it out to everyone in the building. There is no hacker involved in this one, and I can fully protect myself by ensuring that my password is going into the password field.
So, security through obscurity. No thanks. I'd rather know about the exploit ASAP so I can implement a workaround, rather than wait months for the vendor to get off their ass while my systems are getting hacked by the hundreds if not thousands of hackers that have 0-day knowledge.
Calling what you describe as "Responsible" is intellectually dishonest.
Perhaps you can write a patch or mitigate effects of (say) an OpenSSL bug. I can't. Certainly not for the myriad of devices that embed well known libraries in firmware images that I don't get to modify myself.
I'd much rather that those things which are remotely exploitable across millions of devices to be kept quite for a small period of time (30-90 days depending on the complexity of the fix required) so that I can get patches from our vendors and schedule an update at the first available opportunity.
You might call it security through obscurity, I call it keeping shit from burning down.
There are numerous potential workarounds besides authoring a patch. And they can be distributed in a user-accessible fashion, like the workaround for the macOS blank root password was.
Not telling the world about it does not keep shit from burning down. Eliminating vulnerable targets is the only thing that does that. And that is more expediently served by full and prompt disclosure.
What do you think it is that I'm calling responsible? I'm in favor of the public disclosure for this particular bug, and that seems to be your position too.
But these bugs the kind that anyone could stumble upon, and if they are not security researches their first instinct is to let everyone know about a crazy thing they found. I can't really blame them.
If companies want more responsible disclosure they should introduce harder to find bugs - sneaky edge cases in memory allocation sequences, stuff you'd have to pore over a disassembler for weeks, or slightly weakened PRNGs that would take some serious knowledge of finite fields to discover :-)
presumably if you had access to someone's locked MBP and you could move focus away from the password field you might be able to trick them into revealing their pw; if the setup requires access to an unlocked device it still allows you to leverage temporary access to unlocked device to get a leaked password.
This stuff is so amateur though I don't think it is being discovered and handled by security guys. It's just some dev that is annoyed that the lock screen doesn't have total focus which is annoying and insecure and the kid of shit you'd see in the 90s
contrary to what you may believe, some people need to work on content and should not be touching security. it's absurd to expect apple to fire all their non-security related staff and replace them with a whole organization of engineers that only work on basic security.
I do agree that apple has had a ton of problems in this area and needs to work on it, but this example is very played out and boring.
You can't just hire arbitrary numbers of security engineers. These positions are difficult to fill. There's a good chance that Tim Cook wanted to hire more security engineers than was possible.
"With no disrespect to the developers at Apple, et. al., each one of these problems that goes viral before reaching "proper" channels..."
s/that goes viral before reaching \"proper\" channels//
The fact that the problems existed to begin with is more troubling than whether they became known outside the company or not. IMO.
With an open source UNIX-like OS (like the ones Apple sourced from for parts of macOS), both the developers and the users can watch the commits as they happen. Developers and users anywhere can choose to watch the commits and may be able to detect a series of poor quality ones. At least they can make informed decisions on the relative merits of changes from one version to the next. (Edit: They might choose not to compile or install certain components. I do not use X11. Nor do I use systemd.)
The fact that development of macOS is hidden from those outside Apple and that problems are protected from "going viral" does not make the problems any less of an issue for macOS users.
The issue is not how fast and secretively they fix problems, it is how many problems their developers are introducing into the existing version to begin with.
If there are problems routinely being introduced then no amount of fixing after the fact and behind the scenes is going to make the OS higher quality. Only due care taken before introducing changes will guard against further deterioration of quality level.
(Edit: The mention of open source is not intended to be interpreted as an argument that open source inherently results in better software. Perhaps skill and attention to detail are at cause. This is a debate worth avoiding.
The relevance of the mention of open source is intended to suggest that detecting and avoiding problematic software may be easier for some users, e.g. yours truly, if they can access the source code. As opposed to hoping that Acme Hardware and Software Corporation will quickly and secretly fix all software problems that slipped through their QC procedures. Too late for the user who has already paid for the software and updated to the new version. That argument should not be too controversial.)
In addition to the many xscreensaver bugs over the years that the sibling post mentioned, last year there was a systemd root escalation exploit that was the same class of programming error as Apple's bug that enabled the root account with an empty password. From my understanding, in both cases they misinterpreted the return code's magic number (-1) as something it wasn't.
Also, Linus' Law has some doubters. Things like Heartbleed show that Open Source isn't immune to long-standing, very impactful bugs.
I completely agree it is an advantage and I'm very happy there are options that are mostly Open Source (I say mostly because I'm not a fan of binary drivers, which are often a necessity for decent performance or features).
> Why all-or-nothin?
The parent was citing the existence of a few specific bugs in macOS and Open Source as an alternative (implying it wasn't vulnerable). I really think the "given enough eyeballs, all bugs are shallow" is something Open Source advocates take too much comfort in. The idea does have merit, but there needs to be more study/context to how it plays out in real life.
Another example where this idea fails; there are credible suspicions that the NSA has influenced encryption standards introducing backdoors or known flaws even though the algorithms themselves are publicly known and freely available as well as the implementations.
I really think you're overstating things because that's not true for a majority of people. A 0-day found in open source code is no different than a 0-day in closed source. In both cases you need to responsibly disclose it to the maintainer and sit and wait for the fix to trickle through support channels. With open source you can attempt to submit a patch.
If I found a bug in ssl, I can't imagine I'd re-compile that and track down every package I use that relies on it and re-compile those. Everyone uses their own build system and managing dependencies suck. I'd try and mitigate the risk against those tools until fixes were distributed through normal channels--just like I would in Windows or macOS.
If I was a large company, with closed source software I would have a vendor agreement to get fixes/changes, with open source I would have the expertise in-house and extra labor (or I'd have an agreement with a support company like Red Hat much like closed source software). A small company likely won't have the expertise in house or the spare bandwidth to mess with those things. For home users it would have to be someone with a serious hobby and specific skills.
Ironically Linux has had so many long standing versions of this exact vulnerability (screensaver issues leading to various forms of terrible disclosure) that it's not even really interesting to talk about them.
I'd send you to the relevant jwz rants but I'd rather spare everyone the goatse-ing...
> “Responsible disclosure” is great stuff for creating a culture of free outsourcing of tech companies’ most imporant feature (security) to the same people that paid those companies thousands of dollars for that privilege.
Also "Responsible disclosure" means absolute nothing to most people who are not security researchers. They don't know about it, even if there is a bounty and they could make a decent profit, they have no idea what those things are. They notice they can get root access or the focus sends their password to Slack and they'll tweet about it.
Yeah. You can do keystroke logging without root but typing into password fields can't be intercepted. This would be a nice complement to that capability.
If you reused the password, yeah, instant pwnage everywhere. If your local account password isn't used anywhere else, meh, random IRC people don't have physical access to your machine :)
No need to reuse your password. If the machine has sshd enabled, the attacker only has to guess the account name, but that's hopefully a lot easier than guessing the password.
Depends how you authenticate with your password. You could use pubkey with or without a password. Even if you reuse the password there, even if they have your password, if they don't have your private key they can't authenticate.
Remote logon with passwords allowed and sshd exposed to the whole internet (not behind ISP's NAT, not behind home NAT, port allowed on home firewall, port allowed on laptop firewall).
we do regard them as a joke, apple is for you non techies that like cool stuff and dont care about being over charged for a metal case .... how many iphone have broken screens.
Apple customers dont care about the tech , they care about cool. This is what Steve Jobs and apple as branded themselves on so thats what you get, cool without good tech. And it wont matter becuase that is not the reason people buy Apple.
Tech community doesnt care about Apple, but the engineers will happily take their money to work on their products. If apple falls programming and computing will go on happily and at least we wont have to build over priced products for a bunch of children to take selfie shots that dont care 2 cents that they have a technical marvel in their hands.
Perhaps, if the entire tech community regards Apple as a joke, they will start paying attention.
“Responsible disclosure” is great stuff for creating a culture of free outsourcing of tech companies’ most imporant feature (security) to the same people that paid those companies thousands of dollars for that privilege.