Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

About the security content of Security Update 2017-001

support.apple.com

Post reply on HN
Print view View original

51–60 of 158 posts

Re: About the security content of Security Update 2017-001

#51

Post by vinceguidry »

blinkingled wrote: post #24
tomduncalf wrote: post #18

See Apple's comment on this, given to BuzzFeed I assume: https://twitter.com/JohnPaczkowski/status/935909264362586112 / https://www.buzzfeed.com/josephbernstein/apple-released-a-pa... "Security is a top priority for every Apple product, and regrettably we stumbled with this release of macOS. When our security engineers became aware of the issue Tuesday afternoon, we immediately began working on an update that closes…

> We are auditing our development processes to help prevent this from happening again. That's great to hear even if it took multiple stumbles for them to finally admit - but surely they should be also audit their QA/testing processes? Or does development in AppleSpeak mean everything?

I don't know how you could expect QA to be able to have a rigorous process to catch security problems of this type. It's one thing to audit the strength of crypto protocols, quite another to rigorously test every conceivable attack surface for privilege escalation. That space is vast.

Re: About the security content of Security Update 2017-001

#53

Post by bsimpson »

sha666sum wrote: post #40
bsimpson wrote: post #34

Earlier quoted context omitted.

Off-topic, but it blows my mind how poorly proofread many articles are nowadays. In this example, there's a 3-word sentence fragment - "That login gave" - hanging out in between two other sentences. If the author even read what he'd written once before posting, he ought to have caught that.

I'm no journalist, but I guess that being first to report is more important than minor errors in the article.

I don't know what timezone the article is in, but it's been at least an hour. Even if "post, then edit" were the strategy, the author clearly didn't read it after hitting publish either.

Re: About the security content of Security Update 2017-001

#54

Post by blinkingled »

vinceguidry wrote: post #51
blinkingled wrote: post #24

Earlier quoted context omitted.

> We are auditing our development processes to help prevent this from happening again. That's great to hear even if it took multiple stumbles for them to finally admit - but surely they should be also audit their QA/testing processes? Or does development in AppleSpeak mean everything?

I don't know how you could expect QA to be able to have a rigorous process to catch security problems of this type. It's one thing to audit the strength of crypto protocols, quite another to rigorously test every conceivable attack surface for privilege escalation. That space is vast.

Actually entering blank passwords and automated password entry should be Test Cases #0 and #1 for any thing that has a login. OS and other critical infrastructure vendors should go beyond that and explore the vast space to make sure nothing like this ever happens.

Re: About the security content of Security Update 2017-001

#56

Post by crankylinuxuser »

jorisw wrote: post #36
eklavya wrote: post #19

Haven't seen this mentioned anywhere so far but this was not a remote vulnerability right? Only from login screen, right !! ??

I read that it worked even with Remote Management and Screen Sharing. https://twitter.com/voretaq7/status/935609138725425153

Yep. We blocked VNC at the border routers. Now you need to use our VPN in order to use VNC.

And we are very glad to know we can triage and log. Yeah internal users could still exploit machines. But that fact is recorded. Fired and criminal charges are not a light thing.

Re: About the security content of Security Update 2017-001

#57

Post by pilsetnieks »

mey wrote: post #32
eklavya wrote: post #19

Haven't seen this mentioned anywhere so far but this was not a remote vulnerability right? Only from login screen, right !! ??

Once the exploit is done (clicking the unlock button w/ the user root on the settings pane), the root account is setup with a blank password. At this point any remote access methods that use the accounts on the system should allow access. Depending on SSH config, root may be disallowed. I've seen rumors otherwise, but until someone with experience verifies those pathways I can only guess.

Not any method. It worked for screen sharing but it did not for SSH, even after the bug was triggered locally.

Re: About the security content of Security Update 2017-001

#58

Post by 0x0 »

tomduncalf wrote: post #18

See Apple's comment on this, given to BuzzFeed I assume: https://twitter.com/JohnPaczkowski/status/935909264362586112 / https://www.buzzfeed.com/josephbernstein/apple-released-a-pa... "Security is a top priority for every Apple product, and regrettably we stumbled with this release of macOS. When our security engineers became aware of the issue Tuesday afternoon, we immediately began working on an update that closes…

Why is all communication from Apple on this case, both yesterday and today, being channeled via screenshots of text appended to random twitter users posts or blogs? It's weird that there's no official page on apple.com for these statements. (Beyond the actual "security update 2017-001" announcement webpage, which wasn't published until the patch was available)

Re: About the security content of Security Update 2017-001

#60

Post by glhaynes »

blinkingled wrote: post #54
vinceguidry wrote: post #51

Earlier quoted context omitted.

I don't know how you could expect QA to be able to have a rigorous process to catch security problems of this type. It's one thing to audit the strength of crypto protocols, quite another to rigorously test every conceivable attack surface for privilege escalation. That space is vast.

Actually entering blank passwords and automated password entry should be Test Cases #0 and #1 for any thing that has a login. OS and other critical infrastructure vendors should go beyond that and explore the vast space to make sure nothing like this ever happens.

They may have even had a test case that entered "root" and no password and hit OK once, but that wouldn't have caught it. What if you'd had to hit "OK" forty-one times to trigger the bug? It's deeply unsatisfying to just say "the problem space is so vast that it's hard to even know what to try beyond the basics that every QA person knows" but I don't personally have a better answer than that. Maybe those that study the space do, though?
Post reply on HN