GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-11-28) - page 1 of 10
 
___________________________________________________________________
macOS High Sierra: Anyone can login as "root" with empty password
1205 points by vladikoff
https://twitter.com/lemiorhan/status/935578694541770752
___________________________________________________________________
 
cm2187 - 1 hours ago
It really feels like the only thing that made Apple to be less
prone to hacking and malware (and therefore more secure) than other
OS is the lack of scrutiny by hackers and malware authors. This is
a front door open kind of problem.
 
kylehotchkiss - 2 hours ago
Does this bypass filesystem encryption?
 
  satysin - 2 hours ago
  If it does then it means Apple's encryption implementation is
  fucked.
 
  tempay - 2 hours ago
  Only if the laptop is locked (as the encryption key is already in
  memory).
 
    kylehotchkiss - 2 hours ago
    Any chance that self clears after an interval?Might be a bad
    day to leave the laptop at the table at the coffeeshop when
    ordering.
 
      tempay - 2 hours ago
      By default no as most people expect things to keep running
      when they lock their laptop.There is a setting to immediately
      destroy the key when the laptop sleeps. It might be outdated
      but [1] should give you a starting point for setting it
      up.[1] http://mattwashchuk.com/articles/2016/01/08
      /maximizing-filev...
 
  Someone1234 - 2 hours ago
  You have a valid user as far as the OS is concerned, so you'd be
  able to access encrypted files and copy them off of the machine.
 
  ams6110 - 2 hours ago
  It might, if you added "root" as a user able to unlock the disk.
  But you'd probably have needed to set a password for the root
  account to do that.
 
Stephen-E - 1 hours ago
While reading this, my mac just prompted me to Upgrade to High
Sierra. I think I'll hold off...
 
VeejayRampay - 13 minutes ago
Doesn't matter, Apple gets an automatic pass.
 
thought_alarm - 1 hours ago
This will be a fun fix.They'll not only have to patch the
vulnerability but they'll also have to disable all of the root
accounts that were inadvertently enabled.  What a mess.
 
sizzzzlerz - 1 hours ago
Fortunately, I'm OK. The latest OS upgrade failed to install and
bricked my computer so that no one could log in, let alone root. I
was able to restore it using Time Machine but I don't think I'll go
through that exercise again for a while yet.
 
  anon1253 - 27 minutes ago
  you might be able to fix that. I had that too, had to manually
  update the preboot. Details are somewhere in here
  https://forums.developer.apple.com/thread/80174
 
Welytech - 1 hours ago
Dope
 
adambull - 2 hours ago
Confirmed on 10.13.1. As a workaround, once you login as "root",
you can change the password to something else, and the empty
password will stop working.
 
mholt - 2 hours ago
The HN title is wrong. This reportedly affects High Sierra, not
Sierra.
 
  jtokoph - 1 hours ago
  That explains why I couldn't get it to work on my machines that
  are still on Sierra. I'm glad I've put off the update.
 
  sctb - 1 hours ago
  Updated. Thanks!
 
symlinkk - 1 hours ago
How can one of the most wealthy companies on the planet, that every
single software engineer would kill to work for, manage to have a
bug like this?Maybe they need to re-think their hiring process,
because clearly something is not working as it should.
 
equivocates - 2 hours ago
So ? if you log out and log in as root without a password (EEK!),
you can set your own password as root. Once you do, Mac os will no
longer bypass the password.
 
mcintyre1994 - 1 hours ago
I'm sure many of us can often see how some kinds of bugs managed to
slip through testing/QA, but this is crazy to me given it works on
the login screen if it's happening for everyone on whatever
version: is "user cannot log in as root when root account is
disabled" not a test case? That seems.. insane?
 
  Xeoncross - 1 hours ago
  There are thousands of ways you could test this. Like most tests,
  having them isn't the same as having good ones.
 
DonHopkins - 12 minutes ago
I wonder if you can also defeat Face ID by wearing a white face
mask?https://images-na.ssl-images-
amazon.com/images/I/51I4nsyt9AL...
 
brucepucci - 2 hours ago
To fix this with a workaround open Terminal.app and run the command
"sudo passwd" to set a password. Can't believe this is happening.
 
mofino - 43 minutes ago
Not a remote vuln, who gives a shit.  Physical security >
 
dyavuz - 2 hours ago
In the meantime, if you'd like to protect your mac, you can set a
password for root by going to:System Preferences > Users & Groups >
Login Options > Join > Open Directory Utility > Edit > Change Root
Password
 
  fredsted - 1 hours ago
  Alternatively, there's `sudo passwd`.
 
  cyberferret - 2 hours ago
  Standalone iMac here - the 'Join' button is disabled.  So is this
  vulnerability only for Macs on a network?EDIT: My bad - editing
  was locked on that screen. Got it now...EDIT2: Root user is
  disabled on mine.  Is that enough, given that this bug seems to
  create a new root user each time?  Should I enable root user and
  set a password rather than leave it disabled?
 
    mikeash - 2 hours ago
    The bug enables the root user, so leaving it disabled won't
    save you. Set a password for root, then you should be good to
    go.
 
    dyavuz - 2 hours ago
    Mine is currently enabled and since i've set a password, the
    bug seems to be gone. I can't authenticate by just typing root
    anymore.
 
mirekrusin - 2 hours ago
Maybe NSA asked for an easy access. Apple is generally good at
making things simple for users.
 
ianmcgowan - 2 hours ago
Confirming this works, both from preferences, as well as from the
main login screenIt seems like root has no password by default.
Setting one is enough to close the hole.  This is
unbelievable!Curious to see what's in
/var/db/dslocal/nodes/Default/users/root.plist before trying this.
 
  shoghicp - 2 hours ago
  These are the contents of the file, after converting them from
  binary plist to plain xml:
  https://gist.github.com/shoghicp/2b529b54b9d70daf192b68e3564...
 
    ianmcgowan - 39 minutes ago
    Ah, there's no ShadowHashData or KerberosKeys nodes.
    Presumably the code creating that plist is not aware that later
    on it's going to be accessed thru layers of other software and
    end up as a usable login.  To quote Shrek:  "Software is like
    an onion".
 
[deleted]
 
nerflad - 1 hours ago
I didn't think the BSD's allowed a blank root password.
 
  zeveb - 1 hours ago
  Well, if they don't then this is a clear indication of the
  improvements possible with closed-source software.At least if
  it'd been open, maybe someone could have diffed it ?
 
hartator - 2 hours ago
I guess they were more focused in introducing bugs and less
performant filesystem than security in High Sierra.
 
  Twirrim - 2 hours ago
  Those teams are extremely unlikely to be the same ones.
 
[deleted]
 
nkkollaw - 1 hours ago
The new Apple is the old Microsoft, and the new Microsoft is the
old Apple.After 8 months of living hell using their overpriced
MacBook Pro, I'm moving to Surface Pro (running Xubuntu, though).
 
cortesoft - 2 hours ago
Does this effect people who already have a root user with a
password set up?
 
  samwillis - 2 hours ago
  No
 
  yxhuvud - 2 hours ago
  No.
 
dasil003 - 2 hours ago
Why is this so far down the front page?  Are people flagging it for
some reason?
 
  donarb - 1 hours ago
  No, there are two threads about this.
 
  mholt - 1 hours ago
  The title is wrong: it affects High Sierra, not Sierra. Edit:
  they've fixed the title
 
buryat - 1 hours ago
AWS ReInvent 2017 is going right now in Las Vegas, the number of
attendees is about 40000, and I'm wondering how many laptops can be
attacked using this technique. The `root` user stays in the system,
so one just need to create it and open SSH quickly, and later they
can do whatever they please.
 
  joshuaturner - 45 minutes ago
  This reminds me of the jailbreaking scene a few years back. I was
  at an event centered around jailbreaking, and you were able to
  ssh into 80% of users iOS devices by using the default root
  password, alpine.
 
  the_duke - 1 hours ago
  I really hope there's an extra zero in your 40000.
 
    buryat - 1 hours ago
    Maybe closer to 35000, but yeah, that's the scale of ReInvent,
    last year AWS reported 24000 attendees. I was there last year,
    that's a lot of peoplehttps://aws.amazon.com/blogs/apn/why-
    sponsor-aws-reinvent-20...
 
  Washuu - 1 hours ago
  Unlikely any AWS imaged employee MacBooks at least.  AWS IT back
  in the beginning of October forbade employees to not upgrade to
  High Sierra.
 
    buryat - 1 hours ago
    There're a lot of attendees from a lot of companies, they can
    be vulnerable.
 
jeffisabelle - 2 hours ago
I still can't believe more people complain about this being
publicly disclosed than this being possible in the first place. No
one is obligated to know the procedures on InfoSec 0-days and
follow those steps.
 
  zokier - 1 hours ago
  Most likely another from of bikeshedding; people don't have real
  input on the main matter, so they comment on circumstantial
  matters just so they can throw in their 2c
 
  [deleted]
 
  legohead - 1 hours ago
  I wouldn't bash the guy.  Someone already let him know about his
  technical faux pas in a professional manner on his twitter.My
  guess is he found this vulnerability on accident, freaked out,
  and tweeted about it.  Probably has limited infosec experience.
 
    5ilv3r - 5 minutes ago
    Or he cares more about doing the right thing than about
    following best practices designed to protect the guilty under
    the guise of helping users.
 
    mcbridematt - moments ago
    Definitely. How many people outside the infosec industry know
    that responsible disclosure channels exist?
 
  zeveb - 1 hours ago
  > I still can't believe more people complain about this being
  publicly disclosed than this being possible in the first place.I
  think the problem is due to the fact that they are fans.  In this
  case, it's Apple, but there's no reason it couldn't be Linux or
  Go or whatever.  Regardless, any bad news about their hero is
  irresponsible to disseminate.  We see this same phenomenon in
  politics, in sports and elsewhere ? I daresay it's regrettable
  human nature.
 
    saagarjha - 19 minutes ago
    > I think the problem is due to the fact that they are fans.I
    think this is an unfair characterization. Sure, it's hard to
    hear that their "hero is irresponsible", but the real reason is
    that this kind of behavior puts everyone at risk while Apple
    tries to fix it.
 
    eric_h - 49 minutes ago
    I've not commented either way on the subject in this thread,
    but personally I would much rather have read this as a writeup
    2 or 3 months from now after the discoverer had responsibly
    disclosed the vulnerability and Apple had a chance to patch
    it.On the other hand, I'm glad that I have this information so
    I know not to install High Sierra on my work iMac (sitting on a
    desk in a WeWork behind a door whose lock would be very easy to
    force open) until this is fixed.[Edit: I now see that there's a
    simple workaround (change the root password and keep root
    enabled), so I'm all for "irresponsible disclosure" in this
    case]
 
Asmod4n - 2 hours ago
Works with "su - root" too in a Terminal.
 
Shank - 2 hours ago
With user switching enabled as a username + password combo, I was
able to login to the root account from the login screen with no
password on 10.13.1. It's not just a UI bug, it's a full on
authentication bypass.
 
  coreymayo - 2 hours ago
  I'm able to do this as well, login as root with no password from
  the login screen.
 
k4ch0w - 1 hours ago
I just have no words, it seems intentional. They may want to review
their build pipeline to check someone didn't manipulate the source
code before it was signed. I haven't seen an easy root priv-esc
like this in a long while.
 
donatj - 2 hours ago
I can't seem to reproduce it locally. 10.13.1? Anyone else having
issues?I've upgraded a through a couple versions of OS X on this
machine - maybe that makes a difference?
 
  hrrsn - 2 hours ago
  Worked fine for me on 10.13.1.
 
  drunken-serval - 2 hours ago
  It took 3 tries for me and then it worked.
 
  yxhuvud - 2 hours ago
  Perhaps you have a root password set?
 
lolc - 1 hours ago
Reminds me of the time Mac OS X would trust any NIS server in the
local net to authenticate local root. Can't find the story though.
Did that even happen?
 
notanai - 2 hours ago
Can this be used remotely? Edit: Yes, after turning on Remote
Management on my second mac I was able to log into it using Remote
Desktop, account root and no pw.  It only works after getting
physical access once.
 
  [deleted]
 
  djrogers - 1 hours ago
  I tested this by logging in as root at a preference pane then
  attempting to connect via ssh and screen sharing (both enabled)
  using root with no password.  It did not work.Not sure if you'd
  get different results after logging in as root at the login
  screen...
 
  rcruzeiro - 2 hours ago
  Been wondering that myself since it seems that this also happens
  with the login screen.
 
  pilif - 2 hours ago
  It only works after getting physical access once to enable the
  root user by gibing any password UI the root user with no
  password (which will enable the local root account, which is also
  why it fails the first time around)
 
  swozey - 2 hours ago
  Yes, I just had a coworker test it after I enabled remote
  management and they used screensharing.app. I didn't even get
  notified a user remoted in.. never used screen share, that seems
  awful. Had to look over and ask if he was in.edit: I should say,
  I did test this locally first so I don't know if a fresh machine
  that hasn't done it will do the same thing and let a remote
  account enable root.. Would like to hear if anyone tested it
  remotely WITHOUT doing it locally first.
 
zaro - 2 hours ago
Classical click and bait title. First promises that you'll become a
hacker, and then when you actually click the tweet is deleted.
 
  Murrawhip - 2 hours ago
  Isn't deleted for me.
 
TrueSelfDao - 1 hours ago
Serious 0-day on Twitter. How exciting!
 
rderewianko - 4 minutes ago
Myself and others blogged about solutions:
https://www.rderewianko.com/10-13-root-password-oh-my/
https://derflounder.wordpress.com/2017/11/28/blocking-logins...
 
DonHopkins - 35 minutes ago
They could have at least used "rms" instead of a blank password.htt
ps://www.reddit.com/r/linux/comments/7hj6v/i_use_my_login...
 
tribune - 1 hours ago
I would say I'm surprised such a serious bug made it out, but after
the A ? thing who knows what's going on at Apple
 
mratzloff - 2 hours ago
Wow. As if I needed another reason to never "upgrade" to High
Sierra...
 
  MentallyRetired - 2 hours ago
  Apparently El Capitan is vulnerable too.
 
    LeoPanthera - 1 hours ago
    Can't reproduce on El Cap.
 
mfrw - 1 hours ago
I may not be an apple fanboy, but I admit, I really miss Jobs, and
his commitment to quality. Apple has just been minting money and
forgot all about its core values.
 
tombrossman - 2 hours ago
Fellow Linux users, please keep the snark in this thread to a
minimum. Here's just one recent example why, there are more:
http://www.omgubuntu.co.uk/2017/05/ubuntu-guest-sessions-log...
 
  MentallyRetired - 2 hours ago
  Hypocrisy is a reason to keep snark at a minimum?
 
  trumpRektYou - 5 minutes ago
  spotted the applefag.
 
  zeveb - 1 hours ago
  I'm a Linux desktop (and laptop!) user, and I agree (I haven't
  even used macOS in almost twenty years).  Anyone remember the
  Debian OSPRNG issue?These sorts of bugs can happen anywhere.  We
  all need to bear that in mind.One notable difference, though, is
  that macOS is proprietary software.  Apple have sold their users
  a product and haven't respected their users' right to use, modify
  & distribute that product; their users have never had the ability
  to inspect the macOS source for this kind of problem.  Thus,
  responsibility for this disaster rests solely on Apple's
  shoulders.
 
  igetspam - 2 hours ago
  Linux != UbuntuLinux didn't have that problem, a single vendor
  did.  You could say the same for Apple except they are the single
  vendor.  That stupid security trick in Ubuntu only impacts subset
  of a subset of Linux _desktop_ users which is a pretty small
  subset of computer users as a whole.  When Apple does something
  like this, it impacts a much larger share of the world
  population.So how about we keep the snark to an appropriate level
  based on the impact to the world population?  ;)
 
    arghwhat - 2 hours ago
    As Linux user who does kernel-mode development for a living,
    root escalation bugs come a dime a dozen. And, well, Linux runs
    everything but the average persons laptop, so the impact, while
    different, is much greater.So lets keep the snark to an
    appropriate level, shall we?
 
      igetspam - 57 minutes ago
      Are you arguing that privilege escalation is the equivalent
      to passwordless root login?  I mean, I guess you squint just
      right you could say that a logged out user having zero
      privileges being able to login as a user with all privileges
      is an "escalation" but that's one hell of a stretch.  We
      haven't even gotten to snark yet though.We can point to
      avenues for remote root all day but I don't recall any that
      are/were as simple as "just hit [enter] to get root" that
      impacts the shared attack surface that impacts all Linux
      systems.NOTE: I did not go and search NVD before writing this
      reply but I did stay at a Holiday Inn Express once.
 
  dsp1234 - 2 hours ago
  Number of mentions of "Linux" outside of your thread comment
  chain: 0
 
thanatropism - 1 hours ago
Anyone in a position to short AAPL? It's apparently 6bps up in
after hours trading but that's very low
liquidity.https://finance.yahoo.com/quote/AAPL?p=AAPLA higher risk,
higher leverage bet: buy some put options the milisecond markets
open:http://www.nasdaq.com/symbol/aapl/option-chain
 
bennyg - 1 hours ago
Reminds me of an exploit back in 10.7 where you could create a new
admin privileged user from a non-admin account using some bash
commands. Used that to add Xcode to my work computer at college so
I could fool around with learning how to code when I was at work.
 
taurath - 1 hours ago
This is near Windows-95 levels of bad - at the very least you need
to already be logged in
 
myth_buster - 2 hours ago
Is social media the goto for reporting security vulnerabilities in
2017?If I remember correctly, one is supposed to make it public
once patched or in event of no response, no?Edit: What is
"Responsible Disclosure"[0]?[0]
https://en.wikipedia.org/wiki/Responsible_disclosure
 
  FireBeyond - 2 hours ago
  Where is Joe Random's obligation to responsibly disclose?To whom
  does he owe that obligation? Apple? The public? Both? Why?
 
    TallGuyShort - 51 minutes ago
    In my opinion they don't "owe" anyone that obligation, unless
    it's a contractual obligation associated with using a Mac. But
    just because it's not owed to anyone, doesn't mean there isn't
    a nicer way to handle it just to be nice.That said, I don't
    immediately see evidence that this gentleman is in the security
    field, and perhaps isn't aware of responsible disclosure. Full
    disclosure isn't the worst thing in the world.
 
  cotillion - 2 hours ago
  This is one of those cases where responsible disclosure just
  means you're doing the job one of apples automated tests should
  be doing.
 
  DonHopkins - 6 minutes ago
  Twitter's also the goto for banning trans people from military
  service, attacking freedom of the press, threatening to declare
  nuclear war, and all kinds of other things too.
 
  ams6110 - 2 hours ago
  Someone notices that they can log in as root with no password. In
  2017, reflexively tweeting about it seems pretty unsurprising.
 
    fredsted - 2 hours ago
    Seems like the guy just discovered this by accident. It's not
    like you'd have to be a security engineer to stumble upon this.
 
  donatj - 2 hours ago
  I think the difference is if the problem is discovered by Joe
  Schmoe or a security researcher.
 
  testvox - 1 hours ago
  Full disclosure is also a form of responsible disclosure.
 
manwe150 - 2 hours ago
I'm on Sierra and haven't been able to reproduce. But does anyone
know if it respects pam.d "nullok" and I could just delete that
option?    /etc/pam.d$ grep -RI nullok /etc/pam.d
/etc/pam.d/authorization:auth       required
pam_opendirectory.so use_first_pass nullok
/etc/pam.d/checkpw:auth       required       pam_opendirectory.so
use_first_pass nullok     /etc/pam.d/screensaver:auth
required       pam_opendirectory.so use_first_pass nullok
 
  Asmod4n - 2 hours ago
  Tested it in the terminal with "su - root". Doesn't help. Or does
  one need to reboot after it? UPDATE: No effect after rebooting.
 
realworldstuff - 1 hours ago
People going on about responsible disclosure when this is such a
gross violation of CUSSE:
https://web.archive.org/web/20170712120031/http://www.cusse....
 
lostgame - 1 hours ago
#whyidontupgradeUntil Apple forces me to with a required xCode
update for the newest iOS SDK...>.>
 
pmoriarty - 2 hours ago
Has no one been running password crackers against OSX this whole
time?
 
  fixermark - 2 hours ago
  "OSX the more secure OS because nobody tries to hack it,
  CONFIRMED."
 ;)
 
pilif - 2 hours ago
A quick mitigation workaround: If you follow the steps here
https://support.apple.com/en-us/HT204012 to disable the root
account until the point where you open and authenticate the
Directory Utility, in the Edit menu there's a "Change Root
Password" option.Set a good password there and disable the root
account again.Now people making use of this vulnerability will
still be able to re-enable the root account (that's why it fail the
first time - root is default off, but this bug enables it), but now
there will at least be a useful password set.
 
  Asmod4n - 2 hours ago
  if you disable the root account you can log in again without a
  password, even when you set one.
 
aezell - 1 hours ago
Should I leave my Mac unattended until this is resolved?
 
  oneeyedpigeon - 1 hours ago
  Enable the root account and set a (obviously, strong) password
  for it. Keep calm and carry on.
 
  fulafel - 1 hours ago
  You can keep using it.
 
tomduncalf - 1 hours ago
I wonder what is going on with software quality and testing at
Apple. It feels like recently there have been quite a few issues
like this (the FileVault password bug, numerous issues with iOS 11,
the issue that totally broke iOS Safari a couple of years ago)
which should have been fairly easily caught, especially given the
limited range of devices their software runs on.I know testing is
hard, but a company with Apple?s resources shouldn?t be making slip
ups like this. It suggests some real issues such as lack of
unit/automated tests and/or sufficient release testing, which
pretty urgently need addressing.Anyone got any inside scoop?
 
  cm2187 - 1 hours ago
  iTunes had QA problems for more than 10 years, only the early
  versions were really solid. I am not sure that it is a recent
  problem.
 
    tomc1985 - 1 hours ago
    Subjectively it feels like Apple bugs have become larger and
    more prevalent, over the last few years. That and IMO clean
    OSX/iOS installs don't quite feel as polished as they used to.
    (I stopped using Apple products, except for a MBP, for a few
    years and recently started using them again, and the MBP still
    runs 10.10 for precisely this reason) The last solid OSX
    release was Snow Leopard
 
  mholt - 1 hours ago
  > Anyone got any inside scoop?I have a feeling that anyone who
  does would get fired for commenting here about it.
 
    ianmcgowan - 1 hours ago
    You have to think that whoever was responsible for testing this
    is going to get fired.  This is egregiously bad...
 
      fmihaila - 1 hours ago
      This is a management issue. It shouldn't be possible for such
      a mistake to slip into production code. It has happened more
      than once in recent times.
 
  adamio - 1 hours ago
  Repressive collusion to fix salaries and restrict industry
  movement, doesn't really inspire your employees to try their best
 
  [deleted]
 
  rogaha - 1 hours ago
  I've experienced lots of issues wiht IOS and High Sierra as well.
  Apple definitely reduced their software quality since IOS 11.
 
  2trill2spill - 1 hours ago
  It seems apple's software has been trending down in quality since
  Snow Leopard.
 
    thanatropism - 1 hours ago
    I'll agree that Snow Leopard is the high water-mark.
 
      e5an - 13 minutes ago
      It can't be a coincidence that this was the last major
      release before Steve Jobs died.
 
      sanityUnbounded - 44 minutes ago
      I have been in the apple ecosystem for about 10 years. For a
      company that has been priding itself on end user security,
      the bugs that have been creeping their way into the OS are
      just... disappointing. What is the point of paying a premium
      for a well polished hardware/software bundle if the OS is
      malfunctioning in a non trivial manner. Design? Right now
      when I use my calculator app on my iPhone and do 2+2+2 I get
      24. That's a pretty awful design. Actually, it's a lie.
 
      mikeokner - 32 minutes ago
      3rded.  I wish time stopped at 10.6.8.
 
  zaidf - 1 hours ago
  Unrelated to Mac OS but I used to wonder all the time why iTunes
  connect was so shoddy. I got my answer when I learned Apple had
  outsourced a ton of backend work including iTunes Connect, App
  Store backend to Infosys in India.They?re now retreating from
  that strategy: https://factordaily.com/apple-to-pull-back-
  development-work-...
 
  umanwizard - 1 hours ago
  Anecdotal but I started noticing a decline in quality after Steve
  Jobs died.
 
  mikestew - 1 hours ago
  Take this for the anecdata that it is. I interviewed at Apple,
  referred by old Microsoft friends that worked there. As I was
  trying to get a feel for things before the interview, I asked
  about the software testing. I was told, "don't expect what you're
  used to at Microsoft". The reference there is from when Microsoft
  often had more testers on a team than devs (ah, the good ol'
  days). The summary of what I was told by friends, and the
  questions I asked during the interview, is that testers at Apple
  aren't the testers that Microsoft used to have. Microsoft had
  testers working in MS Research, researching ways to better test
  software. Apple, from the impressions I got, is doing good to
  have testers than can write "hello, world". This was from the app
  side of things, not OS; I don't know if it's any different on the
  OS side.But since I don't work there, I have no good inside info.
  But just from gut feel, I don't think my anecdata is too far off
  the mark. Based just on the bugs made public, I just don't get
  the impression that there are testers at Apple whose sole reason
  for being there is to tear into a piece of software and break it.
  There was a bug a few weeks ago posted to HN that I commented on.
  I don't have a link without digging through my comments, but it
  was something along the lines of "how could a tester not find
  this in five minutes of exploratory testing?" This bug is
  similar. It would take more than five minutes, but were this my
  area to test I'd pick at it once in a while when I had a few
  minutes. As I pick at it, I wouldn't expect to find anything, but
  I've got a minute between builds, so instead of randomly clicking
  Facebook I'll randomly click this dialog. What did the dev
  forget? What weird state was not accounted for? Some kind of
  state overflow if I click the button enough times? Shove some
  Unicode in there, that didn't find anything; meh, maybe I ought
  to move o...hey, wait a minute. Did that thing just log me in as
  root?But my gut says that Apple doesn't employ a lot of testers
  like that.
 
    yodsanklai - 1 hours ago
    > But since I don't work there, I have no good inside
    infoActually, I've been wondering why I hear less about people
    working at Apple than at other big tech companies. It seems
    everyone and their mother work at Google or Facebook, but no so
    much at Apple. Do they have less software engineers, or their
    employees are required to be more discrete?
 
      OJFord - 1 hours ago
      >  or their employees are required to be more discrete?Yes, I
      believe so. I've heard there are strict requirements on even
      internal discussion. (Who you can talk to; about what;
      where.)
 
        jsmthrowaway - 7 minutes ago
        Yes, but social media training is more at play here.
        Employees are instructed from day 1 not to discuss Apple
        business on social media, and the constitution of "Apple
        business" is left intentionally vague. There are people who
        actively report seeing it, and people do get walked.General
        sentiment is that even saying the word Apple online is a
        bad idea. Recently, they've acknowledged that there are
        federally protected things you can say, like your salary
        sucks or your manager is an asshole, but they don't go out
        of their way to explain that to you.
 
      skc - 1 hours ago
      Apple probably doesn't take too kindly to their employees
      talking about their work. I'd imagine it's a fire-able
      offense.
 
        chris_7 - 57 minutes ago
        it is everywhere else too, but people do quit...
 
      wil421 - 1 hours ago
      Could it be the level of secrecy around Apple? I see
      responses for Google and Facebook devs on HN a lot but never
      Apple.The only people I know locally that work for Apple are
      remote customer support folks.
 
      mikestew - 57 minutes ago
      Do they have less software engineers, or their employees are
      required to be more discrete?I know but a few that work at
      Apple, and of those few they strike me as less forthcoming
      than the multitudes I've worked with and know at Microsoft.
      I've wondered if part of that is because Microsoft previews
      /pre-announces just about everything, whereas Apple (mostly,
      and not so much anymore) announces it when the shipping
      trucks show up at the local Apple store.So the outcome from
      the Microsoftie is, "it'll do this that and the other, but
      that's all I can say right now." From a recent conversation
      with an Apple employee: "they make me go in a special room to
      use the hardware, and I can't work from home. That's all I
      can say."Probably more so, last I looked, Apple has
      considerably fewer software employees than the other big
      companies.
 
        saagarjha - 10 minutes ago
        > Probably more so, last I looked, Apple has considerably
        fewer software employees than the other big companies.I
        don't think this is true. Apple, Google, and Microsoft all
        have on the order of 100K employees.
 
          jsmthrowaway - 7 minutes ago
          Keep in mind that Apple directly employs retail staff.
 
    [deleted]
 
    jenoer - 55 minutes ago
    As a Tester myself, I cannot understand why this is not covered
    by either unit tests or behavioral tests.   Clicking dialog
    buttons in rapid succession is what we (should) do once in a
    while. Especially in core functionalities such as the login
    screen.   It's one of the first screens you see as a tester.
    And you have default usernames, be it enabled or not.For
    example, I do not own an iPhone, but at work, I made a bet with
    my colleague (jokingly) that I could break _something_ on his
    phone in a few minutes.I did not have his finger print or pin-
    code, so I was very limited, I even joked "I don't need that,
    give it here!"Finding out I only had a hand full of options, I
    focused on the emergency dialer.   As any good tester would be
    curious about, I wanted to check the max field length, so I
    entered digits, copy/paste it a few times, copy/paste that
    string, ("wait, no limit? Not even at 1000? why?") and so on,
    until I noticed the interface became laggy, so of course, I
    kept going.Boom, suddenly back at the login screen, tried to
    open the emergency dialer, but got a full blank white screen,
    in the meantime the phone started heating up substantially.
    Since it was a new Phone (iPhone 7 with iOS 10.x I believe) and
    the dev getting nervous, we decided to reboot it. That fixed
    the issue.   (Curious if this is still an issue in iOS
    11.x)TL;DR: As a tester this simple curiosity should be in your
    blood, and especially covered in behavioral tests when your
    software has been around for 5+ years.
 
  [deleted]
 
  spamizbad - 1 hours ago
  The loss of people like Avie Tevanian and Bertrand Serlet took
  its toll.Are there any "(tech) household name" engineers doing
  system-level work on iOS/macOS these days? It seems like Google
  and Facebook have a slew of them.
 
  socalnate1 - 47 minutes ago
  A [?] don't know what you are talking about.
 
  bangonkeyboard - 1 hours ago
  macOS and iOS updates at Apple are now inextricably tied to new
  iPhone releases. There is a strict yearly deadline that the teams
  sprint toward, a timeline imposed by marketing rather than
  readiness. This affects prioritization of which features are
  pursued, where they lie in the stack, and how polished they
  get.Insufficient testing at today's Apple is not limited to
  software. They bragged about their extensive input testing lab
  [0] when the new line of Magic accessories was released, but the
  Magic Keyboard with Numeric Keypad launched last summer had all
  of its inventory pulled from the channel last month because users
  discovered that the model was so thin that its midsection bowed
  over time.[0]: https://medium.com/backchannel/what-i-saw-inside-
  apple-s-top...
 
    kifleswing - 40 minutes ago
    Where did you hear that the keyboard was pulled from the
    channel? It just seems to be out of stock for me.
 
    komali2 - 37 minutes ago
    Haven't deadlines at Apple always been driven by marketing? I'm
    looking for a source but I remember a story where the product
    director for iPod was told by steve jobs "make it simple, fast,
    beautiful, and have it done by Christmas."
 
    warent - 1 hours ago
    Everything ends in tears when managers mix up targets/estimates
    with commitments
 
    nikofeyn - 1 hours ago
    it is also that they pursue features just for the sake of it.
    things get moved arund in the iPad from release to release for
    no good reason, often going backwards in usability. every
    release i have to relearn simple things like how to manage the
    screen brightness. i really wonder what they are thinking
    internally other than ?we need to shake things up to make it
    appear we?re doing something with stale products?.
 
      maxxxxx - 14 minutes ago
      It seems phones and tablets have reached the stage where
      laptops were maybe 15 years ago. All the major features are
      done and innovation is pretty much over. So they have to make
      a lot of cosmetic changes that look like activity.
 
  wonderous - 1 hours ago
  Apple has always had QA issues, the difference now is that
  they?re increasingly tested by the users, hackers, etc.
 
    ben_w - 1 hours ago
    Difference? MacOS userbase hasn?t changed much since 2011, I
    thought?
 
      eric_h - 55 minutes ago
      I've no information on how good this site's data is, but
      https://www.statista.com/statistics/218089/global-market-
      sha... seems to show that from 2013-2017 global macOS market
      share has increased from 7.95% to 11.3%.
 
notanai - 2 hours ago
You can just type root in the login window to get System
administrator access.
 
sccxy - 2 hours ago
I wouldn't have thought that NSA backdoors are so simple
 
tempodox - 2 hours ago
On my system, the trick doesn't work.  But then, I did explicitly
set a non-empty root password.
 
TonnyGaric - 2 hours ago
Not cool to disclose this kind of bug on Twitter.
 
estevaovix - 2 hours ago
The solution for now is to set a passwd for root... this is
ridiculous
 
mikeash - 2 hours ago
For those who can't make it happen, it requires that the root
account is disabled, which is the default. If you already enabled
the root account for some other reason (which apparently I had on
one of my Macs, although I don't know why) then that prevents it
from working.It seems like the best mitigation for the moment might
be to enable the root user and set a password for it.
 
  Asmod4n - 2 hours ago
  Once you disable the root account you can log in without a
  password again :/
 
    mikeash - 2 hours ago
    Yep. If you keep it enabled and set a good password then you
    should be OK. I think.
 
jmuguy - 2 hours ago
Time to install Afterdark on all the computers in the Apple store.
Confirmed here, 10.13.1.
 
  jrowley - 2 hours ago
  And I just googled afterdark at work... haha thanks!
 
mrkd - 1 hours ago
Title should be changed to 'macOS'I initially saw this thinking it
didn't affect Sierra or High Sierra.
 
  davidkuhta - 1 hours ago
  Now you have me confused, is it just High Sierra or Sierra as
  well?
 
    perryh2 - 1 hours ago
    It does not work for me using Sierra.
 
      davidkuhta - 1 hours ago
      Awesome, thanks.
 
[deleted]
 
arghwhat - 2 hours ago
It seems to activate the root user with an empty password if you
try, as an admin user, to use "root"/"" as credentials in a System
Preferences authentication prompt.It does not work if you are not
admin. It does not work if your root user is enabled and has a
password set. If you tried the vuln, you should set a password for
the root user ("sudo passwd root").
 
michaelmcmillan - 2 hours ago
Are we really ready for self-driving cars?
https://www.youtube.com/watch?v=4G1Boh-URIM
 
  naasking - 1 hours ago
  > Are we really ready for self-driving cars?Firstly, car
  automation is machine learning, not programming. Completely
  incomparable.Finally, we've known how to prove the absence of
  bugs for decades. It's not a matter of not knowing how, it's
  about incentives to do it right.
 
    michaelmcmillan - 1 hours ago
    Is the authentication subsystem in a Tesla machine learning as
    well?
 
  ky738 - 2 hours ago
  I will take malicious improper analogy for 100
 
    michaelmcmillan - 2 hours ago
    Please point out the discrepancy.A Tesla has ~ 100.000.000 [1]
    lines of code. Considering this post, do you think we are
    sufficiently educated in software security to produce secure
    self-driving cars?Elon Musk: "I think one of the biggest risks
    for autonomous vehicles is somebody achieving a fleet wide
    hack" [2].[1] https://bit.ly/KIB_linescode[2]
    https://www.youtube.com/watch?v=4G1Boh-URIM
 
      [deleted]
 
      abestic9 - 2 hours ago
      These companies have completely different operating systems,
      network ACLs, software update policies and subsystems that
      affect certain mechanical features.By your logic, we should
      not fly any modern commercial or military aircraft or
      spacecraft, live within a certain radius of any power or
      hazardous chemical plant, place any dependency on any first
      world country's health care network, including life support,
      or invest in any company or stock.Like most things in life it
      comes down to a security/convenience risk/benefit compromise.
 
        michaelmcmillan - 2 hours ago
        > These companies have completely different operating
        systems, network ACLs, software update policies and
        subsystems that affect certain mechanical features.Are you
        claiming that this could not have happened with Tesla? If
        so, please explain why.> By your logic, we should not fly
        any modern commercial or military aircraft or spacecraft,
        live within a certain radius of any power or hazardous
        chemical plant, place any dependency on any first world
        country's health care network, including life support, or
        invest in any company or stock.Up until now the benefits
        have clearly outweighed the risks, but that does not mean
        it will continue to do so.
 
      jessriedel - 2 hours ago
      This is a much more interesting comment than your initial
      quip.  Next time, consider leading with this rather than
      unnecessarily antagonizing people.
 
      mikeash - 1 hours ago
      How much of that code is safety critical? I occasionally see
      misbehavior from my Tesla's center screen, like the network
      connection failing, or audio glitches, or even the occasional
      spontaneous reboot. This can be mildly annoying but it
      doesn't worry me because I know that the center screen is
      separate from the stuff where bugs can actually get me
      killed.
 
        michaelmcmillan - 1 hours ago
        "On Thursday October 24, 2013, an Oklahoma court ruled
        against Toyota in a case of unintended acceleration that
        lead to the death of one the occupants. Central to the
        trial was the Engine Control Module's (ECM)
        firmware.Embedded software used to be low-level code we'd
        bang together using C or assembler. These days, even a
        relatively straightforward, albeit critical, task like
        throttle control is likely to use a sophisticated RTOS and
        tens of thousands of lines of code. " [1] [2][1] https://ww
        w.edn.com/design/automotive/4423428/Toyota-s-kille...[2]
        https://www.embedded.com/electronics-blogs/barr-
        code/4214602...
 
          mikeash - 1 hours ago
          Sure. My point is just that you can't bring up the total
          number of lines of code here, because most of those lines
          aren't in any way related to any safety-critical system.
          If you want to talk about how much code there is which
          puts you at risk, you need to look at that particular
          subset of code.
 
          michaelmcmillan - 1 hours ago
          I think it is safe to assume that complexity is highly
          correlated with number of lines of code. And with
          complexity grows bugs.On the surface, this particular
          exploit on macOS seems to be caused by a totally
          unrelated subsystem (security vs. GUI).
 
          mikeash - 1 hours ago
          I don't see any evidence that this exploit is related to
          the GUI at all. The GUI just happens to be the easiest
          way to do it. Other commenters have mentioned that you
          can use the exploit with `su`.In any case, in a desktop
          system you shove everything together and then try to
          modularize it with good design and weak tools like UNIX
          processes. In a car, the safety-critical systems are
          literally running on separate hardware with limited
          communication over a specialized data bus. Of course it's
          still possible for them to have bugs or even exploits,
          but the complexity of the infotainment system is
          irrelevant, aside from making it a potential jumping-off
          point for using an exploit in the safety-critical
          systems.Counting the infotainment system here makes about
          as much sense as counting the number of lines in Windows
          when talking about a Mac vulnerability because a Windows
          machine could be used to launch an attack.
 
          michaelmcmillan - 38 minutes ago
          "Apple root bug appears to be triggered only by logins
          coming from http://com.apple .loginwindow.  Running "su"
          with a blank password won't get you a root shell." [1]As
          for your subsystem argument, explain this: https://www.yo
          utube.com/watch?v=OobLb1McxnI&feature=youtu.be...[1]
          https://twitter.com/0xAmit/status/935609423485169664
 
          Dylan16807 - 18 minutes ago
          > I think it is safe to assume that complexity is highly
          correlated with number of lines of code. And with
          complexity grows bugs.But it's still wrong to focus on
          total complexity.  You want to look at the complexity of
          the relevant system.
 
          michaelmcmillan - 14 minutes ago
          Not so sure: "Apple root bug appears to be triggered only
          by logins coming from com.apple.loginwindow. Running "su"
          with a blank password won't get you a root shell."
          https://twitter.com/0xAmit/status/935609423485169664
 
    [deleted]
 
  MentallyRetired - 2 hours ago
  As a programmer, the thought terrifies me.
 
    glhaynes - 2 hours ago
    As someone who tries to do risk analysis, the prospect of
    sticking with human drivers because of fear of software bugs
    (which inevitably will kill, just in much smaller numbers)
    terrifies me.
 
      jtbayly - 2 hours ago
      The fear is not of bugs killing people. The fear is of bugs
      allowing people to kill people.If ISIS was able to hack a
      major fleet through one such bug, do you think for a single
      moment they wouldn't make use of it to kill many people?
 
        ovao - 1 hours ago
        Which is a legitimate fear, and substantial effort should
        go into preventing such bugs, but any sufficiently
        determined person doesn't need to exploit a software bug to
        be able to kill others. ISIS appears to be quite effective
        at simply convincing its members to directly and
        voluntarily engage themselves in such acts.
 
    qrbLPHiKpiux - 2 hours ago
    Could a programmer be held liable for any bad outcomes?
 
  [deleted]
 
  zerostar07 - 2 hours ago
  technically, after they are hacked they are no longer self-
  driving.
 
  crispinb - 2 hours ago
  Possibly not, but the death & maiming stats everywhere show we're
  absolutely not ready for human-driven ones.
 
    carapace - 1 hours ago
    Thank youI imagine a Twilight Zone episode...  Go back in time
    to before cars were invented and imagine some Mephistopheles
    offering the bargain: "You'll fly like the wind over hills and
    mountains, making a journey of days in mere hours!"  What the
    catch?  "For each mile traveled a certain number of people
    chosen at random must be put to death or maimed."He would go on
    about how the chances of someone you love being chosen for
    sacrifice were infinitesimal, and the benefits to all were so
    great and so obvious...("Also, it will poison the air and
    water, and force you to become dependent on fuel sources that
    destroy life and engender wars.")
 
  Oxitendwe - 2 hours ago
  No. I am also skeptical of more modern cars with complex
  computers. The thought of being in one scares me.
 
  ovao - 2 hours ago
  I think the question you're fundamentally asking is "are we ready
  for imperfect systems with potential vulnerabilities?", and the
  answer to that question has been the same since the advent of
  software.
 
  therealdrag0 - 2 hours ago
  They don't need to be perfect. Just better than humans.
 
  [deleted]
 
llamataboot - 28 minutes ago
That twitter thread and lots of the comments are missing the point.
MANY people don't know about what the ethics of reporting
vulnerabilities are, they just want to say something and get it
fixed. yes, it probably would have been better if this person had
gone through proper channels, but there's no evidence they did it
for the lulz/fame.In this case the bug is so bad and egregious,
that publicizing it with the fix might have been the best thing to
do -- no telling how many people have already discovered this or
how long it would take Apple to fix.Yes, let's educate each other
about what responsible disclosure WITH A DEADLINE TO FIX looks
like, but don't assume this person just wanted internet points. And
now that the report and a workaround are out there, at least it can
be mitigated personally.Though I imagine there will be some SERIOUS
hijinks that result from this until Apple fixes it because it is so
easy to do. :(
 
zaro - 2 hours ago
Wow. This is fun. I remember my Windows98 had the same feature. You
just use Administrator with empty password and you're in. Apple is
finally catching up.
 
  ksk - 7 minutes ago
  AFAIK, its not really a security bug. Windows 98 didn't really
  have any concept of user security. With the default install you
  could always cancel out of the login dialog and use the guest
  account. Every account was an 'administrator'. The user name /
  pwd was mainly to store the OS customization settings like UI
  colors and such.
 
  pkaye - 2 hours ago
  Did Windows98 even have administrator role? I mean FAT file
  systems don't even have file ownership right?
 
    lerpa - 1 hours ago
    It did. But didn't have security tied to the fs.
 
  romanovcode - 2 hours ago
  Exactly my thoughts. I remember this, I think even early versions
  of WinXP had this feature.
 
    Grollicus - 2 hours ago
    Exactly early versions of Windows XP had this: They removed the
    Administrator user from their graphical login splash but when
    booted in rescue mode ("Safe mode") you could just type in
    "Administrator" with no password and were in. On Win98, you
    could just cancel the login.
 
  anon1253 - 2 hours ago
  I believe hitting "cancel" was enough.
  https://www.youtube.com/watch?v=DE5PRW-AR7QAlso reminds me of
  https://youtu.be/BVL8_ne4WZo?t=19s
 
    dabernathy89 - 2 hours ago
    from the only top-level comment on that video:> That isn't a
    login screen for Windows 98, it's a login for Microsoft
    Networking (which the box shows). If you had any shared mapped
    drives, network privileges, etc they wouldn't work if you
    cancelled. If you had multiple profiles set up, you wouldn't
    get those either. Win98 wasn't intended to have password
    security.?
 
      anon1253 - 2 hours ago
      Good point. Been a while. Windows 7 also has/had an
      interesting one https://www.youtube.com/watch?v=zwO4YqSc4XE
      but it's much more involved.
 
mrkstu - 2 hours ago
verified on latest build of 10.13.1 (17B48).
 
migueh - 28 minutes ago
If I could just use Mavericks and develop apps for last iOS
release, that will be great. But I should update to High Sierra. I
hate this.High Sierra seems to be focused in Emojis. Urghh
 
quotha - 1 hours ago
I tried it anyway and it does not work!  I'm running version
10.13.1
 
  yborg - 1 hours ago
  Try one more time.
 
  erikdared - 1 hours ago
  I'm using 10.13.1 and it did work for me. You have to first fail
  a login in one of these dialogs (did it with my current user and
  no password) before doing root with no password.
 
thesephist - 2 hours ago
Encouraging users to "try it" is dangerous here. Recreating the bug
enables root user across the system, and most users won't know how
to disable it.TechCrunch, if you're reading this... please
discourage people from reproducing the bug.
 
  sephicr - 1 hours ago
  Yes, but the most secure thing to do at this point _is_ to
  recreate the bug and then set a password for the root
  user.Otherwise the hole is still there for others to exploit.
 
    pilsetnieks - 1 hours ago
    If you set a root password, this bug still works, it seems to
    reset the root password.Edit: I was partly wrong. The bug still
    works if you disable root afterwards, then it reenables and
    resets it.
 
      ukblewis - 13 minutes ago
      Yeah, you?re safe if you keep the foot account alive and you
      set a password for root. At least as far as I can tell...
 
  hw - 1 hours ago
  There?s no need to do this yourself to verify it. Doing so
  creates a ?root? account that others may be able to take
  advantage of if you don?t disable it.That should be much higher
  up in the article.
 
  kreeWall - 1 hours ago
  Can you talk about how to correctly disable the root account if
  someone did try it?
 
    martin-adams - 40 minutes ago
    If you're wondering how to disable it, the menu option can be
    found here: https://support.apple.com/en-gb/HT204012
 
  devindotcom - 2 hours ago
  I was wondering about that. I'm going to change this.
 
    [deleted]
 
    eganist - 1 hours ago
    Thanks :)
 
  AdamJacobMuller - 2 hours ago
  Enables root access in what way?
 
    selectodude - 2 hours ago
    Mac OS X doesn't have a real root account, it uses sudo
    exclusively. This enables a true root user shell.
 
      AdamJacobMuller - 1 hours ago
      The root account always exists.Playing around with
      disable/enable and the exploit: Root always has a /bin/sh
      shell "Disable root user" removes the ShadowHashData from the
      directory services entry for root The bug sets ShadowHashData
      to the hash of an empty string.Now, ShadowHashData is a
      complex DS entry. I've never seen passwords represented this
      way in other OSX versions. I think this password storage
      format is new.I strongly suspect the bug here is one related
      to OSX attempting to upgrade the password to the new storage
      format and when it does that, it inadvertently stores the
      password with a hash of null.This should be very trivial for
      Apple to fix that (and thus "disable" the root user) by just
      removing any ShadowHashData that is solvable by an empty
      string.
 
        arghwhat - 1 hours ago
        Your comment suggests that it is related to users with
        older, pre-High Sierra directory entries. That is, upgraded
        rather than freshly installed machines that leave older,
        pre-ShadowHashData intact. Is this correct?
 
          jsmthrowaway - 14 minutes ago
          No, I reproduced on freshly-installed High Sierra on two
          machines.
 
          Asmod4n - 1 hours ago
          Works with El Capitan too.
 
    [deleted]
 
  thomastjeffery - 1 hours ago
  It can already be activated remotely:https://gfycat.com/gifs/deta
  il/sentimentalnaiveantelopegroun...
 
  CrendKing - 1 hours ago
  This bug exists regardless of user reproducing it or not. If
  there is anything good, reproducing it actually brings awareness
  to the user (make them change the password maybe). Hacker will
  "enable" the root user anyway.What should be done is that Apple
  releases fix to this problem.
 
    devindotcom - 1 hours ago
    Yeah that was my thought initially too but there may be
    invisible ways to leverage an existing root user that we're not
    aware of. After all, this bug exists...
 
      stingraycharles - 1 hours ago
      The issue is that the bug leaves a password-less root account
      available through other means as well. Once you try to
      reproduce the bug, an attacker could potentially do a remote
      root login without password.As such, it's very dangerous for
      people to try to verify and should be strongly discouraged.
 
        mcintyre1994 - 1 hours ago
        If you have remote login enabled does root/no password not
        work already because of the bug? It apparently does from
        the login screen if you have username/password mode on, so
        I wouldn't be surprised if it worked over remote login by
        default.
 
          djrogers - 1 hours ago
          Does not work via ssh or screen sharing based on my
          testing here.  Seems to require physical access to the
          machine.
 
          pilsetnieks - 1 hours ago
          No, it doesn't work for remote login.
 
        jldugger - 1 hours ago
        On most systems, root without password isn't available
        remotely. Is this not true on OSX?
 
    Jedd - 1 hours ago
    Not the case.Once you enable root access - by 'testing' this -
    others can remotely & silently access the system as root.GP is
    right - don't encourage people to test this, as there's nothing
    to gain from it.  If you're on a shared machine you need to
    mitigate.  If you're on your own dedicated machine you need to
    not share it until this is fixed.
 
      thomastjeffery - 1 hours ago
      > others can remotely & silently access the system as
      root.They already can:https://gfycat.com/gifs/detail/sentimen
      talnaiveantelopegroun...
 
        sitharus - 41 minutes ago
        This does not work if the root user has not been enabled
        locally.Source: Just tried it myself.
 
      biktor_gj - 1 hours ago
      No, root is root and has always been there. It's the super
      user account and cannot be removed, I think, from any modern
      unix like os (well, you can rename it to whatever you want in
      linux but UID 0 will always be there). The difference might
      be that if you do log in for the first time you will have
      lots of stuff on /private/var/root (talking from memory but
      it was something like that in OSX) and lots of preferences
      will be set, maybe even a /Users/root folder I hope that the
      SSH server, which is disabled by default, will also handle
      root login in a sensible way, but given the size of the f*
      up, I'm not so sure.Really bad stuff
 
      tekacs - 1 hours ago
      Even if you're on a dedicated machine, this vulnerability
      enables a local user to bypass the authentication prompt on
      things like System Preferences or other auth checks.I'm
      advising folks (incl. non-tech) to set a root password and
      then re-disable the account (specifically via shell), which
      prevents this from re-occuring:https://www.facebook.com/amar.
      sood/posts/10209545863036116
 
      djrogers - 1 hours ago
      > Once you enable root access - by 'testing' this - others
      can remotely & silently access the system as root.That's not
      accurate.  The user appears to be there either way, but
      attempting to log in to a machine remotely using 'root' and
      no password does not work - even after doing the preference
      pane thing...
 
        Jedd - 1 hours ago
        I don't have access to a vulnerable machine -- just going
        by comments in the other HN thread.root account is 'there'
        all the time, yes.  This process enables the account proper
        (rather than just sudo).  Evidently some remote mechanisms
        using root work after the account is enabled.
 
    arghwhat - 1 hours ago
    This vulnerability lets users activate the root user without
    using their password.Once done, you have opened for root
    without password globally. That's bad.What they should do, as
    responsible disclosure dictates, is report it in secret to
    apple, and at most publicize a workaround (activate root user,
    set password) without reporting the details of the
    vulnerability.EDIT: It does not appear to be limited to admin
    users. It appears to be related to disabled root accounts of
    older origin, such as through upgrades. I cannot reproduce on a
    fresh High Sierra install, but I reproduced on an upgraded
    install.
 
      jmuguy - 1 hours ago
      I run as a standard user and was able to reproduce the bug.
 
        arghwhat - 1 hours ago
        Updated. I was unable to reproduce on another machine as a
        standard user, but it appears to be related to it being a
        fresh install of High Sierra, not an upgraded install with
        old disabled root user entries.
 
      throwaway2048 - 1 hours ago
      "responsible disclosure" isn't some morally unassailable high
      ground, but companies like apple sure want you to believe it
      is.
 
        arghwhat - 1 hours ago
        Care to explain the comment about Apple? I can think of a
        few companies (DJI, for example) that try to screw over
        security researchers, but big IT companies usually don't go
        on the list.
 
          lawnchair_larry - 1 hours ago
          Most of the big companies will take their sweet time to
          fix something if it suits them. Not always, but sometimes
          they just won't feel like getting around to it, and they
          know that as a "responsible" researcher, you will keep
          your mouth shut about it. I'm talking like a year. I've
          seen this with the "researcher friendly" companies.In my
          opinion, there's a point at which it becomes
          irresponsible to let them sit on issues for so long, but
          their newspeak for the disclosure policy tries to pre-
          empt that idea.
 
          saagarjha - 30 minutes ago
          That's when you put a clear timeline for how long you
          will wait before disclosing when you report these bugs.
 
      sounds - 1 hours ago
      I agree that we need more responsible disclosure. But as
      https://www.eff.org/deeplinks/2017/10/drms-dead-canary-
      how-w... explains, blame the DMCA.Somebody in Turkey has no
      expectation that they will be treated with respect. It's much
      more likely they will be attacked as in "shoot the
      messenger." (So, please don't attack the person who brought
      this to our attention.)I think they made a reasonable
      decision, due to the critical nature of this bug, and tweeted
      about it.
 
        arghwhat - 1 hours ago
        But throwing it on twitter doesn't stop you from using the
        DMCA, and having the DMCA used against you doesn't stop you
        from posting it on Twitter as counter-measure (which might
        make the company retract the use of DMCA to avoid publicity
        about suing "messengers"). If you're afraid of DMCA, keep
        your mouth shut and stay away from the US.The DMCA is a
        disgusting and absurd set of laws that can always make me
        angry. Its existence alone proves very much how big
        companies can rule with money, placing capitalism over
        democracy.
 
sugavaneshb - 1 hours ago
*macOS High Sierra
 
anon1253 - 2 hours ago
wat. confirmed on 10.13.1 (17B48). I was even able to add another
super user.Edit: changing the login method to "Name and password"
under login options, then logout and login with "root" with empty
password also works.Fortunately, it doesn't work on cold boot with
FileVault enabled, at least it doesn't appear so. `sudo su root`
also doesn't work with an empty password.
 
  cortesoft - 2 hours ago
  well, `sudo su root` would be using the user password for the
  logged in user, not for root. Does `su root` work, with no
  password at the prompt?
 
    anon1253 - 2 hours ago
    Good point. Force of habit. Unfortunately I can no longer try
    since I set the root password under the Directory Utility,
    which probably changed the state of the system.Apparently
    someone verified that it /does/ also work with `su - root`.
 
AdamJacobMuller - 2 hours ago
Wow, setting a root password seems to fix this...
 
jonny_eh - 2 hours ago
Looks like changing root?s password blocks the exploit but if you
disable the root user, it re-enables the exploit.Protect yourself
by changing root?s password: ? (Command) + Space, Directory
Utility, click the lock and enter your password, Edit -> Change
Root Password?, then do NOT disable Root User.Or open a terminal
and do:    sudo passwd
 
  AdamJacobMuller - 2 hours ago
  > click the lock and enter your passwordor just enter root with
  no password
 
    jonny_eh - 2 hours ago
    Ha, ya. That way you know it's still needed!
 
  thomastjeffery - 1 hours ago
      sudo passwd  Does that change the password for the current
  user without authentication, or does it change the password for
  root without authentication?I think it would be best to recommend
  an unambiguous    sudo passwd root
 
    LeoPanthera - 55 minutes ago
    "sudo foo" with no other arguments runs "foo" as root. "passwd"
    with no other arguments changes the password of the user it is
    running as."sudo passwd" unambiguously changes the password of
    root.
 
josho - 3 hours ago
Confirmed that root with no password unlocks the preferences pane.
But, changing the require password after screen saver setting
doesn't take effect. So, it seems to be a bug in the UI not an
actual vulnerability.edit: I stand corrected. The 'require
password' setting under Security Preferences didn't change, but
other settings do. Yikes
 
  nsnick - 2 hours ago
  10.13.1 can't make it happen
 
  jameskilton - 3 hours ago
  Oh this is a real vulnerability. It's possible to switch your
  user to System Administrator using "root" and no password.
 
  vladikoff - 3 hours ago
  I have "Guest User" disabled normally. This allowed me to switch
  Guest User on, log out, login as `root` into OS X. lol
 
thrusong - 58 minutes ago
There have been some really horrible bugs at Apple lately. I'm
still waiting on them to patch the camera bug in iOS 11 where if
you try to use the camera in a web app pinned to the home screen,
it shows the camera UI on a black screen. This dates back to June.
How can it be that hard to patch such a glaring and embarrassing
problem?
 
  milesokeefe - 47 minutes ago
  How many people are using the camera in pinned web apps? What's
  the app you use? I'd imagine most camera-related functions are
  already best served by native apps.
 
    thrusong - 39 minutes ago
    Does that make it OK? I mean, something as important to the web
    as getUserMedia is broken on websites only if you pin it to the
    home screen. Forcing people into Apple's walled garden doesn't
    seem like an acceptable excuse.
 
[deleted]
 
alpb - 25 minutes ago
[meta] I think this thread is currently being downvoted, or dragged
down by the mods somehow. It should be in the #1 right now. I
suspect people are flagging/downvoting because there is no
responsible disclosure in this case.
 
dwighttk - 2 hours ago
I mean, I only tried 15 times, I don't know if that counts as
"several" but this doesn't work for me.It looks to me like my root
user is disabled.When I type "root" into the username field and
click unlock (in System Preferences > Users & Groups) "root" is
replaced with my username and the dialog shakes... I have to type
root in each time, but it never unlocks. 10.13.1Edit: trying it
after logging out keeps "root" in the username field, but never
logs me in... tried 20+ times
 
DonHopkins - 25 minutes ago
Pyramid's OSx version of Unix (a dual-universe Unix supporting both
4.xBSD and System V) [1] had a bug in the "passwd" program, such
that if somebody edited /etc/passwd with a text editor and
introduced a blank line (say at the end of the file, or anywhere),
the next person who changed their password with the setuid root
passwd program would cause the blank line to be replaced by
"::0:0:::", which then let you get a root shell with 'su ""', and
log in as root by pressing the return key to the Login:
prompt.https://en.wikipedia.org/wiki/Pyramid_TechnologyHere's the
email in which I reported it to the staff mailing list. And the
origin story of Pete's "Gymble Roulette" nick-name is here:
http://art.net/~hopkins/Don/text/gymble-roulette.html    Date: Tue,
30 Sep 86 03:53:12 EDT     From: Don Hopkins 
Message-Id: <8609300753.AA22574@brillig.umd.edu>     To:
chris@mimsy.umd.edu, staff@mimsy.umd.edu,             Pete "Gymble
Roulette" Cottrell      In-Reply-To: Chris
Torek's message of Mon, 29 Sep 86 22:57:57 EDT     Subject:
stranger and stranger and stranger and stranger and stranger
Date: Mon, 29 Sep 86 22:57:57 EDT        From: Chris Torek
         Gymble has been `upgraded'.
Pyramid's new login program requires that every account have a
password.         The remote login system works by having special,
password-less        accounts.         Fun.      Pyramid's has
obviously put a WHOLE lot of thought into their nifty     security
measures in the new release.       Is it only half installed, or
what? I can't find much in the way of     sources. /usr/src (on the
ucb side of the universe at lease) is quite     sparse.       On
gymble, if there is a stray newline at the end of /etc/passwd, the
next time passwd is run, a nasty little "::0:0:::" entry gets added
on     that line! [Ye Olde Standard Unix "passwd" Bug That MUST
Have Been Put     There On Purpose.] So I tacked a newline onto the
end with vipw to see     how much fun I could have with this....
One effect is that I got a root shell by typing:      % su ""
But that's not nearly as bad as the effect of typing:      % rlogin
gymble -l ""      All I typed after that was :      you don't
hasword: New passhoose one new     word:      se a lonNew
passger password.     word:      se a lonNew password:ger
password.          Please use a longer password.     Password:
     Retype new password:      Connection closed      Yes,
it was quite garbled for me, too: you're not seeing things, or on
ttyh4. I tried it several times, and it was still garbled. But I'm
not     EVEN going to complain about it being garbled, though, for
three     reasons: 1) It's the effect of a brand new Pyramid
"feature", and     being used to their software releases, it seems
only trivial cosmetic,     comparitivly.  2) I want to be able to
get to sleep tonight, so I'm     just going to pretend it didn't
happen. 3) There are PLEANTY of things     to complain about that
are much much much worse. [My guess, though,     would be that
something is writing to /dev/tty one way, and something     else
isn't.]  Except for this sentence, I will also completely ignore
the fact that it closed the connection after setting the password,
in     a generous fit of compassion for overworked programmers with
ridiculous deadlines.      So then there was an entry in
/etc/passwd where the ::0:0::: had been:      :7h37OHz9Ww/oY:0:0:::
i.e., it let me insist upon a password it thought was too short by
repeating it. (A somewhat undocumented feature of the passwd
program.)     ("That's not a bug, it's a feature!")      Then
instead of recognizing an empty string as meaning no password,
and clearing out the field like it should, it encrypted the null
string and stuck it there. PRETTY CHEEZY, PYRAMID!!!! That means
grepping for entries in /etc/passwd that have null strings in the
password field will NOT necessarily find all accounts with no
password.       So just because I was enjoying myself so much, I
once again did:      % rlogin gymble -l ""      Password: 
[ message of the day et all ]     #      Wham, bam, thank you man!
Instead of letting me in without prompting     for a password [like
it should, according to everyone but pyramid], or     not allowing
a null password and insisting I change it [like it     shouldn't,
according to everyone but pyramid], it asked for a     password. I
hit return, and sure enough the encrypted null string     matched
what was in the passwd entry. It was quite difficult to resist
the temptation of deleting everyone's files and trashing the root
partition.          -Don      P.S.: First one to forward this to
Pyramid is a turd.
 
MagerValp - 57 minutes ago
To block this, set a random password for root:sudo dscl . -passwd
/Users/root $(uuidgen)
 
nkrisc - 2 hours ago
I don't know much about OS development but isn't this just the sort
of thing you'd automate testing for?
 
  nixpulvis - 1 hours ago
  If they are even a little smart, they'll now have a test for this
  ;)
 
  mikestew - 1 hours ago
  In order to create the test case that you would automate, you
  first must create the repro scenario. IOW, automation has nothing
  to do with this until the bug is found in the first place.
  Arguably, one could create a test model that might have found
  this but raise your hand if you even know what I'm talking about
  when I say "test model".The only mitigation that automation would
  bring is if the bug was found in earlier versions, and test case
  was subsequently written. IOW, and very much a generalization,
  automation is to find regressions. But if the bug is new...(To be
  clear, this bug still should have been found. But automation is
  unlikely to have found it.)
 
    couchand - 1 hours ago
    Respectfully disagree.  "User cannot log in as root if root
    user is disabled" is absolutely a test case that should be
    written regardless of previously seeing the bug.
 
      mikestew - 1 hours ago
      Meh, you're probably right. If nothing else, I'd want to
      verify the result of trying to use a disabled account (text
      in the dialog is localized, et. al.) Run through the scenario
      before I formally write the case and...WTF? Yeah, I could see
      that.
 
  olalonde - 1 hours ago
  I guess not. I recall reading somewhere that the Linux kernel
  doesn't even have automated tests. (edit: found the link:
  https://stackoverflow.com/a/3177643/96855)
 
  dandr01d - 2 hours ago
  Have you seen iOS11? Apple doesn't seem to value testing too much
 
[deleted]
 
tbarbugli - 23 minutes ago
So far the best mitigation I could find out is to enable the root
account and set a strong password for it. Hopefully we'll get a
security update quickly so that I disable root access again. While
checking on this I also realized I was running 10.13 instead of
10.13.1 which fixes another major security flaw (key chain saves in
plain text)
 
FiveSquared - 1 hours ago
Oh my goodness. I have a High Sierra MBP. I am scared right now
BADLY
 
  LeoPanthera - 1 hours ago
  It can't be exploited remotely. Only by someone sitting at your
  computer.
 
valine - 2 hours ago
This is deeply troubling. How does this even happen?
 
  andrewstuart2 - 2 hours ago
  All too easily. There's so much to keep track of in modern
  systems engineering. We should all have a healthy dose of
  awareness that we could be/create that weakest link even on our
  best days.
 
    kowdermeister - 1 hours ago
    Errr... umm... unit tests? Tests?
 
lanius - 2 hours ago
Good thing I haven't updated yet. I wonder how many machines are
vulnerable?
 
_jomo - 2 hours ago
Current workaround / fix:1) open Directory Utility app (via
Spotlight or other) 2) Click lock to make changes, log in with
admin account 2) Click Edit -> Enable Root User 3) Click Edit ->
Change Root Password? 4) Set a password 5) Do NOT disable root
user!If you disable the root user, the admin prompt will create it
again with an empty password.
 
  saagarjha - 12 minutes ago
  Once the fix for this issue is out, you should disable the root
  user.
 
  [deleted]
 
steeleduncan - 2 hours ago
To workaround this before Apple have had a chance to patch
it(thanks @lemiorhan), it seems you can:- Open Directory Utility
(/System/Library/CoreServices/Applications/Directory Utility.app)-
Authenticate with the lock icon- From the Edit menu you can enable
the root user and set a proper password (it would already be
enabled if you had tried out the exploit)Having that root user
enabled isn't great overall, so it would be best to set a reminder
to disable it using the same Directory Utility app once the
security hole is patched.
 
2trill2spill - 21 minutes ago
Besides for APFS what user visible killer features has Apple made
to Mac OS since 10.6.8? I'm sure they have made internal non user
visible improvements to their kernel and userland. But it seems
most of the "changes" to Mac OS is just churning code, or at least
it seems that way from the outside.To me personally 10.6.8 +
Security Updates + APFS is extremely close to the ideal operating
system.
 
  saagarjha - 14 minutes ago
  APFS is not an example of something I would consider "user
  visible"?for the average user there's no difference between HFS+
  and APFS.
 
fredsted - 2 hours ago
This is very, very bad.
 
patcheudor - 2 hours ago
Apple makes it pretty easy to report vulnerabilities to:product-
security@apple.comThey also respond to security@apple.com but
prefer the product-security address.Further, there are any number
of legit bug bounty programs out there like ZDI that would pay for
a bug like this then immediately disclose to Apple for it to be
fixed.Disclosing an 0Day root authentication bypass vulnerability
on Twitter isn't cool, even if it is local: think of the impact to
shared iMacs on university campuses.
 
  LeoPanthera - 2 hours ago
  It's not local if you have Remote Desktop enabled. Works over
  that too. From there you can enable ssh and all bets are off.
 
    notanai - 1 hours ago
    "It only works after getting physical access once" - quote form
    somewhere else in the thread
 
      thomastjeffery - moments ago
      ...or if you enabled root for some reason, but didn't set a
      password.
 
  kristofferR - 2 hours ago
  I really disagree - this needs to be reported as much as possible
  publicly to create a huge thunderstorm of negative publicity for
  Apple.This isn't the first extremely serious and dumb High Sierra
  password bug this year [1] [2], and unless Apple is severely hurt
  by it, so they're forced to change, it won't be the last. High
  Sierra is full of bugs and seemingly not just annoying bugs, but
  also security bugs.Let's hope Apple gets sued for the damage
  they'll cause by including this bug in High Sierra so they make
  sure that next release of macOS won't be another bug filled
  mess.[1] https://arstechnica.com/information-
  technology/2017/09/passw...[2]
  https://www.macrumors.com/2017/10/05/macos-high-sierra-disk-...
 
    aquova - 45 minutes ago
    I think there's a middle ground to this. Submit your report to
    Apple security, allow them time to develop a patch, and then in
    a week go ahead and tweet at the big media outlets about it.I'm
    a die-hard Apple user myself, but I agree that the long list of
    severe bugs in High Sierra is absurd, and a big public backlash
    might be enough to kick them into gear. On the other hand, I, a
    university student with next to no understanding of computer
    security, can simply walk onto campus, sit down at a Mac, and
    within seconds have complete access to the computer. It's
    ridiculous, it's horrendous that it shipped like this, but it's
    not something that needed to get out, especially something so
    easy to utilize.
 
      kristofferR - 36 minutes ago
      The fact that you as the ordinary student can become root and
      create a lot of damage so easily is the only reason the
      public will care.Us geeks have been complaining about the
      horrible QA in macOS for years, yet nothing has been done.
      The fact that this is so simple to do will probably/hopefully
      get ordinary people to start talking about it too ("Hey, have
      you heard that you can hack Macs without a password? Very
      insecure"), which would force Apple to improve.
 
    openasocket - 1 hours ago
    You could let them know about the vulnerability and wait until
    it's been patched before commenting, with some timeout where if
    they don't patch in a reasonable amount of time you announce it
    anyway.
 
    mozumder - 39 minutes ago
    Zero-day disclosures aren't about negative publicity in order
    to prevent problems further down the road some time in the
    distant future.It's about protecting systems RIGHT NOW from
    immediately causing harm to people's lives.
 
    hw - 1 hours ago
    Why does it need to create a lot of negative publicity for
    Apple? Is there something you don't like about them?
    Responsible disclosure needs to be valued given the number of
    macs out there in the wild that could potentially be
    susceptible to issues like this, and the impact it could have
    on people (including you) not just directly but indirectly.How
    would you feel if someone discovered a 0day at a company that
    exposes credit card and identity info, published the 0day, then
    hackers steal all that info (including yours)? I'm sure
    'creating a thunderstorm of negative publicity' would be the
    last thing you would want.
 
      soneil - 52 minutes ago
      I don?t see it as either/or.  You can disclose responsibly,
      and go for publicity once the fix is in circulation.
      Responsible disclosure is nothing to do with protecting
      Apple, it?s about protecting the users.
 
      [deleted]
 
    CGamesPlay - 1 hours ago
    Don't forget the Disk Utility password disclosure!
    https://www.macrumors.com/2017/10/05/macos-high-sierra-disk-...
 
      kristofferR - 1 hours ago
      Thanks, added!
 
    sounds - 1 hours ago
    I agree.https://www.eff.org/deeplinks/2017/10/drms-dead-canary-
    how-w...Blame the DMCA. This guy is in Turkey - does GP really
    think he can expect fair treatment and equal compensation as a
    "western world" security researcher?
 
      vatueil - 1 hours ago
      There's no reason why the person who discovered the bug would
      be safer publishing the vulnerability on Twitter than
      disclosing it to Apple directly. If nothing else, they could
      always post it on Twitter later. The link to the DMCA is a
      digression.
 
      gnulinux - 4 minutes ago
      How does him being from matter in this case?
 
    bradrydzewski - 1 hours ago
    Responsible disclosure does not prevent negative publicity. It
    provides the vendor with a grace period during which they can
    fix the vulnerability. There can be plenty of negative
    publicity once the vulnerability is patched and publicly
    disclosed.Encouraging irresponsible disclosure because one
    wants to see Apple hurt is a reckless and selfish attitude
    because it puts millions of Apple customers at risk in the
    process.
 
      joe_the_user - 13 minutes ago
      A bug like 'can log in with password "root"/""' just isn't
      going to get you a grace period no matter what security
      researchers might want.I mean, this bugs has been reported
      already - by every cheesy hacking movie ever, by every
      beginners book on social engineering and so-forth. Heck, it
      was "reported" by Richard Feynman talking about cracking
      safes during the Manhattan.
 
        r3bl - 3 minutes ago
        Grub's "backspace 28 times to a rescue shell" was also a
        stupid one, but it first got fixed, and then made it to the
        news.
 
      camus2 - 1 hours ago
      And Full disclosure is about protecting users of a software,
      not letting the vendor off the hook. Here, the hack and the
      fix are so trivial the responsible thing to do is to publicly
      call out Apple for its lack of QA and warn users directly. It
      affects everybody who runs High Sierra.> it puts millions of
      Apple customers at risk in the process.Nah, it's Apple which
      put millions of customers at risk, not the person who
      disclosed the vulnerability. let's not shift away the blame
      from the guilty here.Apple one of the richest company in the
      world is obviously just cutting corners in QA here. This is
      unacceptable.it's seems some people here are more concerned
      about negative publicity than user security. This is a
      pattern that have been seen countless times in big tech
      corporations(such as Yahoo), not disclosing hacks that put
      their users and their data at risk. This is unacceptable for
      a company that claims to be all about their users.
 
        joshuaturner - 52 minutes ago
        I would argue that releasing this vulnerability as
        irresponsibly as he did is showing he cares more about
        negative publicity than user security.Yes, it's Apple's
        fault for poor QA that this was released, but this guy also
        put users at risk by telling the entire world about it
        without giving Apple a chance to fix it.You're right, it's
        about user security before publicity. So make sure users
        are safe first.
 
        SirZimzim - 45 minutes ago
        The defense will stem primarily from users invested in the
        Apple ecosystem. If anything that is very concerning on its
        own.
 
      kristofferR - 1 hours ago
      Closed disclosure does, to a large degree, prevent negative
      publicity. I don't think it is in dispute that this bug would
      receive vastly less media coverage if it were only revealed
      as a bug in outdated/patched versions of the OS.I don't want
      to see Apple hurt (I'm an Apple-guy myself, using Macs,
      iPhone, iPad and Apple Watch), I want to see them improve. I
      doubt they start will start caring about QA unless they're
      forced to.One absurdly serious and stupid password bug like
      this can be a honest mistake, but three (that we know of,
      that were full disclosures) in a few months is negligence
      that should be criminal if it isn't.
 
        ukblewis - 44 minutes ago
        I actually do think it is in dispute. This is a tweet after
        all. This guy could totally tweet about it in much the same
        way after Apple released a patch. The negative publicity
        would still exist because the bug would be equally stupid
        and disastrous, just fewer people would be harmed along the
        way.
 
          mark-r - 27 minutes ago
          It wouldn't be as clear that the bug is widely
          reproducible after the patch is put out. And it certainly
          wouldn't gather as much attention.
 
          freedomben - 2 minutes ago
          Exactly.  Everyone I know on Mac immediately tried
          reproducing this bug the moment they heard about it.  On
          those systems where it didn't reproduce, they immediately
          dismissed it as a false report.
 
      sydney6 - 1 hours ago
      Not the attitude of the people reporting the issue have put
      "millions of apple customers" at risk, but the company which
      allowed to let issues like this one slip through their Q&A
      process.IMO, this behaviour is part of the problem, the
      reason why tech companies take security only on a
      superfiscial level seriously.Don't kill the Messenger.
 
        bradrydzewski - 1 hours ago
        I think this incorrectly interprets my comment. I am not
        defending apple or blaming the individual that disclosed
        the vulnerability on Twitter. I am simply pointing out that
        putting users at additional risk because you want to see
        Apple hurt may be misguided. We have responsible
        disclosures in place for a reason.EDIT: putting users at
        _additional_ risk
 
          sydney6 - 38 minutes ago
          I dont understand the implied correlation between, what
          you call, irresponsible disclosure and "wanting to hurt
          apple". Where did you get this impression from?edit:
          Typo.
 
          xapata - 28 minutes ago
          > Let's hope Apple gets sued ...
 
          threatofrain - 27 minutes ago
          I do get the impression that you do blame the individual,
          as you have attributed unsavory motivations to his
          behavior. Why do you care to make such a loose statement
          about this person having a petty motive of malice?
 
          blowski - 19 minutes ago
          One of the grandparent posts specifically said they
          supported the tweet because it would hurt Apple, and I
          think bradrydzewski is responding to those comments.
 
          philipwhiuk - 52 minutes ago
          They were already at risk.
 
          mark-r - 24 minutes ago
          Making an exploit widely known increases the risk
          dramatically.
 
    jackhack - 1 hours ago
    I'm more concerned that the "exploit" works "after a few tries"
    and not the first-time-every-time, or not at all.One would
    think that something as simple as a login would be
    deterministic.
 
      michaelbuckbee - 1 hours ago
      My understanding is that the first attempt is
      creating/enabling the root account with a blank password and
      that the subsequent login is actually utilizing it (which is
      kind of bizarre and probably why this was missed in testing).
 
        justadudeama - 2 minutes ago
        Does this user have admin privileges? root != admin on
        macOS if I recall correctly.
 
  alexwebb2 - 2 hours ago
  Does anybody have any info on how much Apple would've been likely
  to pay for a responsible disclosure in this case, given the scope
  and severity of the issue?I'm just curious how much of a payday
  this guy missed out on by not disclosing responsibly.
 
    pault - 1 hours ago
    That was my first thought. Based on some bounty reports I've
    seen recently I would assume at least high five figures.
 
      alexwebb2 - 1 hours ago
      Ouch. This guy's going to kick himself pretty hard. The 15
      minutes of infamy seems like a pretty bad tradeoff.
 
        sounds - 1 hours ago
        Do you honestly believe Apple will pay out the same to
        someone located in Turkey?
 
          alexwebb2 - 1 hours ago
          I wouldn't think they'd care about the geography of it -
          a good tip is a good tip, and they want to encourage
          responsible disclosure.
 
          thanatropism - 1 hours ago
          Do they release statistics on bug bounty payouts?
 
          FireBeyond - 46 minutes ago
          They barely acknowledge bugs being submitted to Radar...
 
      lawnchair_larry - 1 hours ago
      For a local root with physical access? Not a chance. Maybe
      low 4 figures.
 
        rcruzeiro - 50 minutes ago
        If the mac has screen sharing enabled, physical access is
        not required
 
    ken - 46 minutes ago
    AFAICT, Apple's security bounty program is officially only for
    their preselected group of security researchers.In the course
    of developing my current application, I've discovered a couple
    security bugs in macOS, which I reported to Apple product
    security in PGP-encrypted emails.  The only thing offered to me
    was to have my name/company listed in the release notes (which
    they are, for the latest 10.13 update, along with a CVE#).
 
  albertTJames - 8 minutes ago
  Yeah, the guy is an attention whore, he just wants to buzz.There
  is no justification for releasing a 0day publicly.
 
    thomastjeffery - 1 minutes ago
    There is a simple workaround. Publicity means security
    here.It's trivial to find. He can't presume he is the only one
    who found it. Telling any individual that doesn't have
    malicious intent is a good thing, therefore telling everyone is
    a good thing.
 
  ig1 - 1 hours ago
  Responsible disclosure is pretty much a security industry
  concept, it's not something that most developers know about,
  complaining on Twitter is probably what an average person would
  do.Although for what it's worth last time I reported a security
  vuln to Apple using their official process they took around 2
  years to fix it (admittedly low priority security vuln, passwords
  being sent over http).
 
    ben_w - 48 minutes ago
    > admittedly low priority security vuln, passwords being sent
    over httpWait, what?
 
      ig1 - 36 minutes ago
      Unfortunately it's still more common than you think.The other
      day I actually ran across some AWS docs which suggest you
      send your AWS root key in the url of http requests:http://doc
      s.aws.amazon.com/AlexaWebInfoService/latest/index....
 
  bangonkeyboard - 2 hours ago
  If you urgently want Apple to fix something, you do not file
  quiet bug reports. Apple only responds reliably to PR storms.This
  vulnerability is ridiculous, unacceptable, and braindead to
  execute.
 
    saagarjha - 39 minutes ago
    You can go about it both ways: file a bug report, put a
    reasonable date that you want them to fix it by. Then you can
    disclose it.
 
    patcheudor - 33 minutes ago
    > Apple only responds reliably to PR stormsThey've been quick
    (within 45 days) to patch every major bug I've reported to them
    and where the bugs were cross platform, impacting Windows,
    Android, etc., they've consistently been amongst the quickest
    to issue a patch so I'm not sure how you qualify that
    statement.
 
    Scoundreller - 1 hours ago
    We need to come up with a witty name to get it fixed faster.
 
      bhhaskin - 1 hours ago
      AppleGate
 
      maephisto - 11 minutes ago
      iRoot. uRoot. Everybody Root.
 
      patcheudor - 5 minutes ago
      rootStorm
 
      neverartful - 52 minutes ago
      i0wned
 
  [deleted]
 
  teamhappy - 2 hours ago
  You can't expect everybody who uses a computer to be aware of
  that.
 
  dsp1234 - 2 hours ago
  think of the impact to shared iMacs on university campuses.I'm
  sure Apple will in the future.
 
  oneeyedpigeon - 1 hours ago
  Let's wait until Apple release their patch so we know just how
  long they left everyone's machines vulnerable for. That will be a
  factor in determining whether this disclosure was irresponsible
  or not. It's been two and a half hours so far.
 
  [deleted]
 
  sillysaurus3 - 2 hours ago
  It's the neighborly thing to do, but people are under no
  obligation to report vulns privately. The blame lies squarely on
  Apple, not on the messenger.The fact that we know about it means
  we can take steps to mitigate the damage.
 
    collinmanderson - 1 hours ago
    Mostly, they're just missing out on an up to $200,000 bug bount
    y.https://www.theregister.co.uk/2016/08/05/apple_joins_the_bug.
    ..
 
      [deleted]
 
    e40 - 2 hours ago
    The blame lies squarely on Apple, not on the messenger.There is
    blame on both.If you leave your key in your front door lock and
    I blast out on twitter your address and tell people about it, I
    think I have some responsibility.
 
      ZenoArrow - 2 hours ago
      You may say so, but really the level of incompetence of not
      setting a password for a root account is pretty high. The
      fact that someone reported it in a way you don't agree with
      shouldn't distract you from the fact that this highlights a
      serious oversight.The main question that should be asked is,
      how did this get overlooked? How is it that your average
      website has better password security than the OS of one of
      the richest tech companies in the world?To be fair to Apple,
      Microsoft had similar issues back in the 1990s. Perhaps it
      takes a string of security blunders for some tech companies
      to take security seriously.
 
      teamhappy - 2 hours ago
      Your analogy makes no sense. He's just as vulnerable as you
      are.
 
      asejfwe8823 - 1 hours ago
      A better analogy would be "if the lending bank left the door
      to your new house open..."Other than buy an Apple product,
      the users did nothing intentional to undermine security.Since
      this is a subjective argument, based more on historical
      instances of "responsible disclosure" and not law, I'm gonna
      lean in this case of it being Apple that failedThey built the
      entire "walled garden" without getting outside help. They
      want the control, they have billions of dollars, can hire
      whatever talent...Failed to spot a password-less root login
      issue.People need to know today to be even more cautious
      about using Apple gear in public places or around plain ol'
      tech jerks that like to fuck with people for a gag.Society
      has no legal or moral obligation to make sure Apple stays in
      business.
 
      [deleted]
 
      interfixus - 2 hours ago
      If you leave keys in other people's doors all over the
      neighbourhood, I damn well have a rigtht, and possibly an
      obligation, to make it publicly known that such a thing is
      taking place. So that everyone may take their own
      precautions.
 
        godelski - 2 hours ago
        Let's say keys were hidden around the neighborhood. Would
        you rather everyone in the whole town know about it or
        quietly and quickly go pick up all the keys before someone
        notices and breaks into one of the houses?Personally I
        think if you report through the proper channels and nothing
        is changed THEN broadcast, but not as an opener.
 
          [deleted]
 
      thanatropism - 1 hours ago
      This very excellent comment lies "dead", so I'll repost
      it:asejfwe8823 24 minutes ago [dead] [-]A better analogy
      would be "if the lending bank left the door to your new house
      open..." Other than buy an Apple product, the users did
      nothing intentional to undermine security. Since this is a
      subjective argument, based more on historical instances of
      "responsible disclosure" and not law, I'm gonna lean in this
      case of it being Apple that failed They built the entire
      "walled garden" without getting outside help. They want the
      control, they have billions of dollars, can hire whatever
      talent... Failed to spot a password-less root login issue.
      People need to know today to be even more cautious about
      using Apple gear in public places or around plain ol' tech
      jerks that like to fuck with people for a gag. Society has no
      legal or moral obligation to make sure Apple stays in
      business.
 
      mholt - 2 hours ago
      Wrong. This is Apple -- not the homeowners -- leaving
      everyone's key in everyone's door without them knowing.
 
        giobox - 2 hours ago
        Responsible Disclosure is widely regarded as a good
        practice in these situations. Blame isn't the key issue -
        fixing the problem quickly and safely is. Widespread
        disclosure before Apple have even a chance to respond in a
        timely fashion is inherently unsafe.You would hope the
        self-described twitter bio "Agile Software Craftsman" might
        have thought about this a little before tweeting.>
        https://en.wikipedia.org/wiki/Responsible_disclosure
 
          lawnchair_larry - 1 hours ago
          "Responsible Disclosure" is a term rejected by the
          industry as a loaded phrase that favors vendors, instead
          preferring the term Coordinated Disclosure. Even so,
          reasonable professionals still disagree that this is the
          best option, in a debate that has existed for decades, so
          it's by no means settled as the "proper" way.
 
          dsp1234 - 2 hours ago
          The poster practiced Full Disclosure, which is also a
          valid disclosure policy.Since we're just making up
          statements, I guarantee that Apple would never
          voluntarily disclose this issue if it was reported
          privately.  So Full Disclosure is the only way to put
          Apple's feet to the fire, as it's the only way in which
          this issue would have had any visibility whatsoever.https
          ://en.wikipedia.org/wiki/Full_disclosure_(computer_secu..
          .
 
          Bud - 1 hours ago
          On what basis do you "guarantee" this?
 
          eyelidlessness - 37 minutes ago
          It's used as an idiom, meaning roughly "I have total
          confidence".
 
          SahAssar - 1 hours ago
          Private Disclosure does not prevent you from publicly
          disclosing it after a grace period.
 
          falcolas - 24 minutes ago
          What grace period is appropriate for a 0 day root login
          vulnerability?This guy is, with all probability, not the
          first one to have found it.
 
      pcwalton - 2 hours ago
      The problem with that analogy is that the probability that
      the "bad guys" already know about this vulnerability is
      vastly higher than the probability that thieves know about
      how well some random house in the neighborhood is secured.
 
        tn_ - 1 hours ago
        How many more people now know about this vulnerability
        cause of this knuckle-head tweeting it?  At least 100k
        impressions?  Now think of how many more "bad guys" have
        access to this hack that are going to abuse it.
 
        godelski - 1 hours ago
        But do they? And what portion of them do? And are they
        using it? There's a lot of speculation here. But surely the
        average person doesn't know and with this being public
        knowledge, AND easy to execute there is a bigger chance for
        crime of opportunity.
 
          ben_w - 52 minutes ago
          It?s always reasonable to assume that black-hats (and?
          what do you call government hackers ? black-suits,
          helicopter-hats, ???) know everything that white-hats
          know, and that they either have or are already in the
          process of selling that exploit to less skilled
          criminals.It?s not like being good morally correlates
          with being good at security.
 
    patcheudor - 2 hours ago
    I get it, I really do, but it's not like he was complaining
    about a bad Uber driver.  Disclosure in this way has real-world
    impacts up to and including harming people and we shouldn't
    ever consider it as something which is remotely acceptable.  Is
    it acceptable to publicly disclose that an airport has a self-
    destruct switch which can be accessed near the NW mens
    bathroom?  No.  You contact someone who can fix the problem,
    then publicly disclose.
 
      testvox - 1 hours ago
      But everyone can fix this problem by setting a root password.
      So telling everyone is the right call. Otherwise people would
      be sitting vulnerable while Apple comes up with a patch.
 
        openasocket - 1 hours ago
        But a tweet isn't really the most effective way to tell
        everyone. Technical people, including those who would use
        this vulnerability for malice, will find out far far sooner
        than my grandmother.It seems to me the right thing to do is
        to tell Apple privately, tell them to either push a fix or
        put out some kind of release letting all their customers
        know how to mitigate this in the next, say, 3 days, or I'll
        just tweet about it. What's the downside? At the worst
        case, you just prolonged the status quo for another 3 days.
 
          thomastjeffery - 5 minutes ago
          It's not the most effective, but that doesn't make it
          bad, or malicious.
 
      sillysaurus3 - 2 hours ago
      It's as remotely acceptable as "root" with no password,
      apparently.The question is large and complicated, and people
      can agree to disagree. There's nothing wrong with tweeting
      vulns: The company is at fault, we can defend ourselves now
      that we know about the vuln, and it's a big PR disaster for
      Apple.A past conversation:
      https://news.ycombinator.com/item?id=14009937No, no it's not
      strictly more ethical. It's not even strictly safer, which
      should be an even easier question to answer. The baked-in
      assumption in your logic is that users have no options other
      than waiting to patch. But, obviously, they do, and keeping
      vulnerabilities secret deprives them of those options.
 
        openasocket - 1 hours ago
        > The question is large and complicated, and people can
        agree to disagree> There's nothing wrong with tweeting
        vulnsThose two statements seem to be contradictory. It
        seems to me there is still quite a lot of debate about
        which disclosure policy is best,
 
    arghwhat - 2 hours ago
    ... And means that others can utilize this to cause damage.The
    idea of responsible disclosure is to minimize harm for you, the
    user. Not to minimize bad publicity.
 
      dolson - 8 minutes ago
      In a case like this, I think it would be best to maximize the
      bad publicity.   Bad publicity is the minimum Apple deserves
      for a bug like this.   In my idea world they'd get a lot of
      bad publicity, and a significant financial penalty.
 
  zerostar07 - 2 hours ago
  People are already fixing their machines because he tweeted. this
  is too much of a huge blunder to wait for the official channels.
 
    jrochkind1 - 1 hours ago
    they are? Where's the fix?
 
      Veen - 1 hours ago
      Create a root password.
 
        saagarjha - 38 minutes ago
        This isn't a fix, it's a hack. A computer with a root
        password is inherently more insecure than one without a
        root account at all.
 
          5ilv3r - 8 minutes ago
          If setting a root password is a hack, I'm Donald Duck.
 
          saagarjha - 3 minutes ago
          I really can't respond to you unless you explain your
          reasoning?
 
          will4274 - 22 minutes ago
          Actually, no. For all computers, running macOS High
          Sierra, a computer with a root password is a whole heck
          of a lot more secure than one without a root account at
          all :)But seriously, a fix is whatever fixes the problem.
 
          saagarjha - 18 minutes ago
          It is now. There's going to be a whole lot of people who
          are going to set a root password because they read an
          article online recommending it, then install the update
          that fixes this issue. Now they're stuck with a root
          password when they could have not had one at all.
 
  yumraj - 31 minutes ago
  I agree in general, but calling it uncool and laying any blame on
  the person reporting is not fair.You may know the protocol,
  security researchers and people in the tech industry may know
  that, but why is an ordinary Joe expected to know, or research,
  that email address and/or the protocol regarding 0-day
  vulnerabilities.
 
  zeveb - 2 hours ago
  > Disclosing an 0Day root authentication bypass vulnerability on
  Twitter isn't cool, even if it is local: think of the impact to
  shared iMacs on university campuses.It gets the word out
  quickly.Releasing proprietary software with such a hilariously
  insecure authentication system isn't cool.  This isn't free
  software, produced by people & corporations out of the goodness
  of their hearts; rather, it's something for which people pay a
  good deal of money and which they have a right to expect is at
  least somewhat secure.Getting the word out, fast that a) there's
  a huge insecurity and b) it's in Apple software provides benefits
  to those running macOS (so they can fix their systems) and to
  those considering running macOS (so they can evaluate whether an
  alternative is more appropriate).
 
  na85 - 24 minutes ago
  This is one of the sillier things I've read today. The only way
  something like this slips through is a culture of complacency, or
  incompetence.And the only way Apple gets motivated to fix either
  of those two things is massive Pr damage.
 
  dhimes - 2 hours ago
  Is this address easily discoverable without needing too much
  insight into tech company workings?  Like, do they have a help
  menu that tells people where to report stuff?  I'm not an apple
  user.
 
  0care - 1 hours ago
  I disagree.  Being unaware of the flaw doesn't make you more
  secure.
 
  fixermark - 2 hours ago
  Is it likely it's just an error due to the discoverer not being
  immersed in the Infosec space? "Don't disclose a 0-day publicly"
  is good 'common' sense, but only among the 'common' of people who
  are steeped in security issues and the ramifications of
  publicizing them.
 
    mikeash - 2 hours ago
    Indeed, discovering this bug wouldn't take any security skill
    (I imagine it could be harmful since you might skip really dumb
    stuff like this) and could easily happen by accident.
    Responsible disclosure is standard for security researchers but
    I don't think this person was one, and it's not very fair to
    blame him for not doing it right.
 
    lawnchair_larry - 1 hours ago
    That is not the case among infosec professionals either. Many
    respected professionals believe that the right thing to do in
    many cases is full public disclosure. Google Project Zero are a
    notable example.
 
      Veen - 1 hours ago
      Project Zero does full disclosure 90 days after informing the
      relevant organization. Full disclosure comes after there has
      been a chance to fix the problem. Otherwise everyone is put
      at risk until a fix is available.
 
      mwfunk - moments ago
      Google Project Zero does not support full public disclosure
      immediately- quite the opposite. They support full public
      disclosure after giving the vendor an opportunity to ship a
      fix to their customers in a reasonable period of time.
      Nobody's debating whether or not security flaws should be
      publicly disclosed- of course they should. The only debate
      is, what is the most responsible way to handle such a
      security issue such that it harms the fewest users.Project
      Zero (and infosec professionals, at least all of the ones
      I've ever worked with) would tell you that this was the most
      irresponsible way to handle the issue, short of not saying
      anything and selling knowledge of the exploit to someone
      other than the vendor who could fix it. Publicizing something
      like this in this way is something people do because they
      want publicity for themselves. It is not something someone
      does if their biggest concern is for the users who might be
      affected by it. It is something someone would do if they
      didn't care about the users, and just wanted public credit
      for pointing it out.
 
  mirekrusin - 2 hours ago
  There must be some kind of scale 1-10 of how serious the issue
  is. This one goes up to 11 as hilarious, not sure if proper
  reporting ethics apply here anymore.
 
  williamscales - 1 hours ago
  This situation is much more akin to a fire rapidly spreading
  through a village at night. I would go outside and start
  hollering in the hopes of saving anyone.
 
    saagarjha - 32 minutes ago
    A better analogy is that there's a fire somewhere in your
    village, but it's mostly contained (it's not spreading, because
    other people don't know about it yet). By hollering about it,
    you've made it possible for anyone to go to the fire, light a
    torch with it, and burn down the village. Instead, you could
    call up the fire department and they could put it out?and then
    you could tell everyone about it.
 
      5ilv3r - 7 minutes ago
      You are comparing an arsonist to a fire department.
 
        saagarjha - 5 minutes ago
        Uhh, no. How are you getting that impression? I'm simply
        saying that arsonists exist, and it's probably a good idea
        to make it harder for them to burn things down than to
        publicly advertise a way for them to do it.
 
callesgg - 2 hours ago
In what version did the issue appear?
 
  devindotcom - 1 hours ago
  we've seen it only in 10.13.1 (17B48) so far
 
    mithr - 1 hours ago
    It also works on 10.13 (17A365)
 
      shavingspiders - 1 hours ago
      I can confirm that, too. Took 2 attempts.
 
overcast - 2 hours ago
Excuse my language, but this was a dick move to post this publicly,
especially on Twitter. Go through private bug channels properly for
something as serious as this. Of course doing it that way doesn't
give you your 15 minutes of interweb fame.
 
  mikeash - 2 hours ago
  Maybe he didn't know about the proper procedures to handle a
  security vulnerability. You wouldn't have to be a security
  researcher to discover this bug, and I don't see any indication
  that he is one.
 
    overcast - 1 hours ago
    I would say it's pretty basic common sense, not to publicly
    announce ANYTHING that could immediately affect millions of
    people. Unless he's just a sociopath.From his Twitter account,
    he's not just some layman stumbling across it.Agile Software
    Craftsman, iyzicoder @ http://www.iyzico.com , Founder of
    Software Craftsmanship Turkey @scturkey, The community guy
    http://bit.ly/lemiorhan
 
      mikeash - 1 hours ago
      If that were true, then the security community wouldn't have
      spent years fighting about whether responsible disclosure was
      the right approach. That's for people who actually understand
      this stuff. It's unreasonable to expect an outsider to derive
      it all on their own from first principles.
 
        overcast - 1 hours ago
        So someone stumbles upon a lost cache of chemical weapons.
        Rather than reporting to the authorities, they post its
        location on Twitter. That's called just using your brain.
 
          testvox - 1 hours ago
          Security though obscurity is no security at all. Don't
          you think the people living around the chemical weapons
          should be informed too so they can take precautions to
          protect themselves?
 
          mikeash - 1 hours ago
          You're coming at this from a position of knowledge and
          assuming everyone else knows as much as you do, or should
          be able to figure it out in short order. That's not how
          it works. It's really hard to see how other people might
          think in situations like this.
 
    always_good - 1 hours ago
    Also, it's reasonable for someone to think that making a public
    stink about it is in the best interest of all the people then
    that can immediately patch it themselves instead of having to
    wait for Apple to push a patch and then for everyone to
    download that patch.I'm not convinced private disclosure is
    without its downsides nor a panacea.
 
    Jedd - 1 hours ago
    Maybe.  Look at his twitter page though:
    https://twitter.com/lemiorhanNot impossible to believe he's
    unaware of the right way of handling this kind of issue, but
    that banner photo (Enthralling My F-ing Audience) [1] and stats
    there suggest he should be aware that there probably are
    sensible and polite procedures for this, even if he didn't
    immediately know what they were.[1]  http
    ://jesuschristsiliconvalley-blog.tumblr.com/post/4653787...
 
      mikeash - 1 hours ago
      How do the banner or stats suggest he should have known about
      this?
 
        Jedd - 52 minutes ago
        He is giving a technical talk to a large audience.   Slides
        refer to development, and bio implies this means software
        development.   Bio uses the phrase 'founder of software
        craftsmanship Turkey'.Following the link to his home page
        we find:"He has worked as software architect, software
        craftsman, technical leader, team leader, technical
        coordinator, Scrum Master and Agile coach in dozens of
        software projects at BYM, GittiGidiyor / eBay and
        Sony."and"Lemi Orhan Ergin is a Software craftsman,
        passionate developer, technical architect, Agile culture
        cultivator, Agile coach, Scrum / Kanban practitioner and
        trainer, Management 3.0 trainer, experienced mentor,
        engineering booster, Git trainer and lover, the TDD guy,
        clean coder, infected with the technical side of Agile,
        presentation and visualization freak, non-stop learner,
        full time apprentice of my masters, the community guy."It's
        possible this guy was oblivious to the idea that there's a
        good way to share this information with Apple / The World
        At Large, and consequently did not attempt to find out the
        preferred way of doing it, but I don't buy it.
 
  zerostar07 - 2 hours ago
  this is too serious to hide. better to tell users how to fix it
  than wait until apple releases something
 
    overcast - 2 hours ago
    Yeh, except for the millions of MacOS users out there, like my
    parents who don't read Twitter, or HN or any of the other sites
    people think that everyone stays up on. They are the targets.
 
      fixermark - 2 hours ago
      Not technically. Exploitation still requires physical access
      to the machine or remote access to have been enabled, right?
      Did your parents who don't read Twitter or HN enable a
      feature that generally only power users want or need?
 
      pkaye - 2 hours ago
      I think it is only a local exploit. The bigger risk are the
      Macs in schools and libraries.
 
    glhaynes - 2 hours ago
    That's not how responsible disclosure works.
 
      testvox - 1 hours ago
      But it's how full disclosure works which is more responsible
      then coordinated disclosure.
 
  giarc - 2 hours ago
  Probably could still get 15 minutes of fame if you disclosed
  privately then blogged about the back and forth and a picture of
  the $10,000 cheque from Apple.
 
    CameronBanga - 2 hours ago
    Apple doesn't pay bounties for this sort of report, even if
    direct to their team. They have a private bounty program, for a
    select few.
 
      bredren - 2 hours ago
      That this would be the prevailing understanding is exactly
      why a bug like this would live in the wild at all. There are
      plenty of other orgs out there who would have paid big money
      for this.
 
      3pt14159 - 2 hours ago
      Source? I've heard of iPhone vulnerabilities getting high six
      figures from Apple (for root access via sms). Why wouldn't
      Apple pay for something like this?
 
  fixermark - 2 hours ago
  When I put it into my personal malice / ignorance balance, it
  weighs out to the likelihood that the discloser isn't plugged in
  enough to the infosec scene to be aware that there are already
  best practices for this kind of disclosure.It's a big world out
  there, especially nowadays. And nothing I've seen in recent
  history suggests to me the average user knows or cares about
  infosec concerns beyond basic hindsight understandings.
 
    overcast - 1 hours ago
    Sure, now look at his Twitter account. He looks pretty plugged
    into the software community.Agile Software Craftsman, iyzicoder
    @ http://www.iyzico.com , Founder of Software Craftsmanship
    Turkey @scturkey, The community guy http://bit.ly/lemiorhan
 
      fixermark - 59 minutes ago
      Yes. And from his personal site
      [http://www.lemiorhanergin.com/]:He's a manager. CSM, PSM1,
      PSD1, Scrum Master, Kanban Practitioner. Code retreat
      facilitator. Translated Agile Manifesto into Turkish. The
      only thing that immediately makes me think he even touches
      code is "git trainer and lover." Notably lacking from his
      r?sum?: references to specific open source projects he's
      worked on or code he's written (though personally, I'd be
      concerned because his r?sum? does list "Restful Services" and
      I'd expect that to have given him a taste of infosec basics,
      but maybe it's a bit of r?sum? padding... shouldn't it be
      spelled "RESTful services?" ;) ).It feels weird to say for
      those of us deeply immersed in the internet / telecoms / web
      app side of software development, but depending on your
      focus, you can do an awful lot of software development
      without ever brushing up against the sharp edge of infosec.
 
    testvox - 1 hours ago
    Isn't the best practice full disclosure? It seems like it was
    followed well.
 
singularity2001 - 2 hours ago
Is http://hckrnews.com/ buckling from the tremendous traffic this
issue generates?
 
spsful - 20 minutes ago
workaround: ENABLE ROOT USER AS FAST AS
POSSIBLEhttps://support.apple.com/en-us/HT204012
 
  saagarjha - 16 minutes ago
  As I had said above, this, in the long run, is actually less
  secure than not having a root account at all. If you do this,
  make sure to revert it once the issue is patched.
 
abritishguy - 1 hours ago
If you have `osquery` deployed to your fleet you can detect
compromise with this query:SELECT * FROM plist WHERE path =
"/private/var/db/dslocal/nodes/Default/users/root.plist" AND key =
"passwd" AND length(value) > 1;
 
  sounds - 1 hours ago
  That only detects enabled root users, which is a start but may
  include innocent people who have set a root password to protect
  their machines.
 
[deleted]
 
[deleted]
 
mrmondo - 1 hours ago
1. Ensure you always have FileVault enabled (you should regardless)
and shutdown after work until the bug is fixed.2. Add a complex
root passphrase and clean this up after the fix is released.3.
Reflect on how irresponsibly this serious security bug was
?reported?, he didn?t just potentially miss out on $200,000, he put
an enormous number of people at risk of local intrusions when
instead if it was properly reported there?s a good chance Apple
would have released a bug fix for this quicker thus reducing the
potential impact and spread of misinformation.https://en.m.wikipedi
a.org/wiki/Responsible_disclosurehttps://support.apple.com/en-
au/HT201220 (See ?Security and privacy researchers?)
 
  thomastjeffery - 1 hours ago
  It's not irresponsible to make a bug public.He did not put people
  at risk, he showed people they are already at risk, so they would
  know to set a root password, and thereby not be at risk.Security
  by obscurity does not work!
 
    sdmadf2834 - 43 minutes ago
    This is the most idiotic thing I've heard in a long time.  Yes,
    they were already at risk, but with the way he disclosed the
    information, the risk increased exponentially.  This guy's
    actions were either stupid or malicious.
 
      thomastjeffery - 35 minutes ago
      Obviously this isn't the best way to disclose a security
      flaw.That does not make it malicious.Sure, there are more
      malicious people aware of this security flaw, but there are
      also more users aware of this security flaw, and the simple
      steps they can take to mitigate it.
 
        sdmadf2834 - 33 minutes ago
        Yep, just saying that if he's not malicious (intending to
        maximize harm to users), then he's an idiot for disclosing
        it this way.
 
          thomastjeffery - 25 minutes ago
          Or just didn't know what the best practice was.Since this
          is a flaw any user can run into, I wouldn't get so mad
          about someone who doesn't know best practice running into
          it.I am much more concerned that such an obvious
          tractable flaw exists in the first place.
 
    mrmondo - 1 hours ago
    It?s not an example of security by obscurity, it?s a straight
    out security flaw and bug.If it?s not publicly known and is a
    security risk it is far more effective to directly contact the
    developers / companies security team so they can immediately
    work on actually protecting people by developing a patch. If
    they don?t respond quickly (subjective, I?d call it within 12
    hours) or fail to issue a fix in a timely manor (subjective,
    I?d say 24 hours) then yes - go public, start by logging a bug
    report and link to that bug report or if you can?t - the bug
    number / reference.
 
      [deleted]
 
      thomastjeffery - 56 minutes ago
      The fact is that the devs certainly do know about it by now,
      yet users do not have a fix yet. Users do, however, have a
      workaround, and knowledge that the security flaw exists in
      the first place.Waiting for a fix before disclosing a
      security flaw is security by obscurity, even if it is to be
      replaced soon.It is best for users to know that their system
      is vulnerable, and how to fix that without waiting for a
      system update.
 
        mrmondo - 47 minutes ago
        > "The fact is that the devs certainly do know about it by
        now, yet users do not have a fix yet."Citation needed.> "It
        is best for users to know that their system is vulnerable,
        and how to fix that without waiting for a system
        update."Stepping outside the 'tech' social bubble, most
        general users likely won't create a root account and
        password from something they see on TV or their local news
        site or at least not before a patch would have been
        released.--Further to previously provided examples:https://
        www.cloudflare.com/disclosure/https://access.redhat.com/sec
        urity/team/contacthttps://www.xenproject.org/security-polic
        y.htmlhttps://about.gitlab.com/disclosure/https://help.gith
        ub.com/articles/responsible-disclosure-
        of-s...https://www.kernel.org/doc/html/v4.10/admin-
        guide/security-b...https://www.drupal.org/drupal-security-
        team/general-informat...https://www.cisco.com/c/en/us/about
        /security-
        center/security...https://www.juniper.net/us/en/security
        /report-vulnerability/
 
          thomastjeffery - 41 minutes ago
          > Citation needed.Has there been an update released yet?
          I wouldn't know, I don't use OS X.Is this the best way to
          report a security flaw? Of course not! Is it a bad way?
          No! The only bad way to report a security flaw is to not
          report it at all.
 
          mrmondo - 32 minutes ago
          >> Citation needed.> Has there been an update released
          yet? I wouldn't know, I don't use OS X.I think you might
          have misunderstood what I meant when when asking for
          citation, it's based on the statement you made in
          relation to citing sources for what something that could
          be opinion stated as
          fact.https://libguides.mit.edu/citing> Is it a bad way?
          No!OK this is where I stop feeding the troll.
 
mk89 - 19 minutes ago
Apple proves they still care about UX: finally, I found a way to
login without typing.
 
rubatuga - 2 hours ago
While this true, please keep in mind that rebooting your Mac into
single user mode also allows anybody to login as root
 
  2trill2spill - 2 hours ago
  You can set a firmware password to prevent this.
 
  mikeash - 2 hours ago
  Not if I use FileVault, surely?
 
danra - 1 hours ago
These bugs are getting ridiculous. With Apple's budget, finding
such bugs in a security architecture review or just in QA should be
as easy as 1+2+3.
 
  symlinkk - 1 hours ago
  > 1 + 2 + 3https://www.macrumors.com/2017/10/24/ios-11
  -calculator-anima...
 
api - 19 minutes ago
But there are new emojis, and emoji karaoke works!
 
abritishguy - 19 minutes ago
Just in case it is relevant for anyone here this is what our
security team have established thus far:- Can be mitigated by
enabling the root user with a strong password- Can be detected with
`osquery` using `SELECT * FROM plist WHERE path =
"/private/var/db/dslocal/nodes/Default/users/root.plist" AND key =
"passwd" AND length(value) > 1;";`- You can see what time the root
account was enabled using `SELECT * FROM plist WHERE path =
"/private/var/db/dslocal/nodes/Default/users/root.plist" WHERE key
= "accountPolicyData";` then base 64 decoding that into a file and
then running `plutil -convert xml1` and looking at the
`passwordLastSetTime` field.Note: osquery needs to be running with
`sudo` but if you have it deployed across a fleet of macs as a
daemon then it will be running with `sudo` anyway.
 
fiatpandas - 1 hours ago
Worked for me on the second try (10.13.1)
 
  LeoPanthera - 1 hours ago
  root is disabled by default. The first try, somehow, enables it
  with no password. The second try will let you in.
 
2trill2spill - 2 hours ago
Apple has a serious software quality problem. Last night I was
helping a friend with their computer. Safari couldn't even render
apples website correctly. Nor could Safari connect to any site with
HTTPS. Installed FireFox and HTTPS sites worked and apples's site
renders. But the submit button on their developer site is
broken[1]. Mail on my Mom's fully updated laptop crashes every time
it's opened. Once I reported a bug in ptrace like 4 years ago and
no response yet. Also the archive utility fails often to extract
tar files that the tar command has no problem extracting at all.
Quicktime can't play most videos, etc, etc. And now shipping an
operating system with a root account with no password by
default.Come on Apple you have a quarter trillion dollars in the
bank why don't you spend some on improving your software.[1]:
https://forums.developer.apple.com/thread/60763
 
  minusSeven - 1 hours ago
  Its not just Apple though. Microsoft had the similar problems in
  the past. Edge did not support silverlight causing people to move
  to other browser. It was strange to see Microsoft's own software
  not supported by Microsoft.
 
    2trill2spill - 1 hours ago
    > Its not just Apple though. Microsoft had the similar problems
    in the past. Edge did not support silverlight causing people to
    move to other browser. It was strange to see Microsoft's own
    software not supported by Microsoft.In my personal experience
    Windows has been much better than MacOS for me. I've been using
    Windows 7 for the last year at work and I'm having
    significantly less problems with Windows then MacOS. But
    Windows and MacOS both give me more problems then a FreeBSD or
    Linux box ever has.
 
      anko - 1 hours ago
      > I'm having significantly less problems with Windows then
      MacOS.I'm interested.. What kind of problems?> But Windows
      and MacOS both give me more problems then a FreeBSD or Linux
      box ever has.I switched from linux on the desktop to MacOs
      precisely because of the problems linux had - driver support,
      even LTS updates breaking functionality, and overall
      clunkiness.  I run linux on all my servers.
 
        kylemuir - 1 hours ago
        Really? What driver support on a desktop were you
        experiencing?I've run Linux mint on my desktop at home for
        a few years now and have had zero problems at all (Intel
        i5, Nvidia gfx, wired connection).The last time I had
        driver issues with Linux was ~10 years ago and it was for a
        laptop running Ubuntu.
 
      snowpalmer - 1 hours ago
      Windows 7 has been on the market since 2009 while High Sierra
      has been out since June of this year. I feel like we're not
      comparing apples to apples here.. I'm sure both companies are
      releasing security fixes consistently and Win7 has clearly
      had more of them in 8 years.
 
    strictnein - 1 hours ago
    Silverlight was EOL'd five years ago.
 
      reaperducer - 1 hours ago
      Tell that to Dish Network.
 
    oefrha - 2 minutes ago
    EdgeHTML sure has advanced a lot from Trident, and I appreciate
    their openness with Platform status, but Edge as a browser is
    still a joke IMO.The other day I had to use vanilla Windows 10,
    and wanted to save a text file from Edge. Nope, there's no such
    functionality. The closest thing to save is print to PDF.
 
    will_hughes - 55 minutes ago
    It was partly a marketing thing, but Edge is not IE, and Edge
    has never supported any plugins (which Silverlight is).
 
    [deleted]
 
  eridius - 58 minutes ago
  > Safari couldn't even render apples website correctly. Nor could
  Safari connect to any site with HTTPS.Sounds like something's
  wrong with your friend's computer, because neither of those
  issues are reasonable to expect no matter what your opinion of
  Apple's software is.> But the submit button on their developer
  site is brokenGiven the number of people who've successfully gone
  through that form, I'm willing to bet it's a content blocker
  extension that's blocking some dependency the form needs.> And
  now shipping an operating system with a root account with no
  password by default.The OS actually ships with root disabled. The
  bug isn't that there's no password (after all, a factory-set
  password isn't any more secure), the bug is that the login form
  is somehow re-enabling the root user when it's not supposed to be
  able to do so.
 
    2trill2spill - 13 minutes ago
    > Sounds like something's wrong with your friend's computer,
    because neither of those issues are reasonable to expect no
    matter what your opinion of Apple's software is.Doubtful
    Firefox and Chrome work just fine.> Given the number of people
    who've successfully gone through that form, I'm willing to bet
    it's a content blocker extension that's blocking some
    dependency the form needs.Brand new install of Mac OS on a new
    SSD. So Safari was clean no extensions, no custom
    configuration.> The OS actually ships with root disabled. The
    bug isn't that there's no password (after all, a factory-set
    password isn't any more secure), the bug is that the login form
    is somehow re-enabling the root user when it's not supposed to
    be able to do so.Mere semantics, It doesn't matter if root is
    being "reenabled" or not. From an attackers point of view High
    Sierra effectively ships with root with no password.
 
Unknoob - 2 hours ago
Confirmed here on 10.13
 
swat535 - 2 hours ago
This is comical at this point. I have no idea how such vulnerable
software makes it to production.It is really ironic that a company,
making billions of dollars and branding itself as the leaders of
quality, stability and so on, to have this kind of vulnerability.I
have truly lost faith in Apple.
 
  gluestic - 48 minutes ago
  Agreed.iOS 11 was the tipping point for me (can't delete photos
  using trash icon, wrong orientation when unlocking phone, random
  lag/freezes etc).Apple just doesn't care any more.
 
mcintyre1994 - 49 minutes ago
I guess Apple aren't the kind of company that would do it, but I'd
love to read a frank post mortem about how this happened.
 
jcoby - 2 hours ago
Be careful testing this! It appears that you're creating a "root"
superuser with no password. Be sure to clean up that user
afterwords.https://twitter.com/a_hailes/status/935601901839806464
 
  mschuster91 - 2 hours ago
  The "root" superuser is always there, I'm not sure if it's
  possible to actually delete it.
 
    tempay - 2 hours ago
    It is disabled by default[1] (meaning you can't login as it),
    this vulnerability appears to enable the root user without
    setting a password. If the root user has already been enabled
    it doesn't work.Anyone who does this should probably set a
    password for now and then disable the root user account once it
    has been patched.[1] https://support.apple.com/en-us/HT204012
 
      srathi - 2 hours ago
      This is the best workaround for now. Enable the root user
      with a strong password till the bug is fixed by Apple.
 
  martinp - 2 hours ago
  This support article explains how to disable the root user:
  https://support.apple.com/en-us/HT204012
 
    jameskilton - 2 hours ago
    Do note that this doesn't fix the problem. The system (at least
    High Sierra) will happily re-enable the user for every attempt
    at logging in.
 
      LolWolf - 1 hours ago
      Just change the root password once the account is enabled;
      this fixes the hole.sudo passwd -u rootIt's sad we have to do
      this, though.
 
      tekacs - 53 minutes ago
      If you disable the root user using `dsenableroot -d` from the
      Terminal, this seems to disable the account in a way that
      leaves its password intact.
 
        pwinnski - 33 minutes ago
        The bug isn't in the disabling, it's in the auto-enabling
        on attempt.
 
          tekacs - 25 minutes ago
          Having tested this by both approaches (disabling through
          GUI & shell), the above (through shell) seems to prevent
          this from re-occurring when you attempt to perform this
          bogus login again. Disabling the account via the GUI
          causes the failure to re-occur.
 
  psychometry - 2 hours ago
  You're not creating it, but rather enabling it. When the bug is
  triggered, the root user is enabled (per Directory Utility).
 
  ringaroundthetx - 1 hours ago
  oh my god
 
  rwc - 2 hours ago
  It's worse than that. You're enabling the root user EVERY time
  you use this vulnerability. Even if you disable the root user in
  Directory Utility, logging in with root and no password will re-
  enable the root user.
 
    mcintyre1994 - 2 hours ago
    I haven't upgraded to High Sierra yet and this doesn't happen
    on my install atm. Does adding a password to the root user stop
    this vulnerability? If it does then that seems way better than
    disabling the account until this is fixed.
 
    LeoPanthera - 2 hours ago
    You can simply set a root password with "sudo passwd" to close
    the hole.
 
      tekacs - 1 hours ago
      And you might want to disable the root account again with
      `dsenableroot -d` as well, so that the root account stays
      disabled after the vulnerability is patched.Unlike doing this
      through the GUI, this seems to retain the root password and
      prevent this vuln from re-occuring.
 
        LeoPanthera - 38 minutes ago
        Don't disable root. The bug re-enables it with a new blank
        password.
 
          tekacs - 26 minutes ago
          It doesn't if you disable it from the shell like this, as
          I note in my comment.I've tested both approaches -
          disabling via the GUI causes this bug to re-occur next
          time you try, disabling via the shell does not.
 
          ukblewis - 4 minutes ago
          Bizarrely though, you can still use the root user (with
          the password that you set) to login to the Directory
          Utility even while it is supposed to be disabled... This
          behaviour seems super weird.
 
      thomastjeffery - 1 hours ago
      Then you better remember the password you set, or be sure
      that you will always have sudo access.
 
    DavideNL - 2 hours ago
    ...unless you set a password, right?
 
  thought_alarm - 2 hours ago
  Until this is fixed it's probably better to use Directory Utility
  to enable root with a strong
  password./System/Library/CoreServices/Applications/Directory
  Utility.appEdit > Change Root Password
 
senko - 1 hours ago
Am I missing something or does this require the attacker to have
access to an unlocked computer? In which case all bets are off
anyways.
 
  valine - 1 hours ago
  It works remotely if remote login is enable.edit: Screen sharing
  is is vulnerable not ssh. Either way its bad.
 
    djrogers - 1 hours ago
    No it does not.  I tested this rather carefully, and both ssh
    and screen sharing do not allow the user root with no password.
 
      ehntoo - 1 hours ago
      I have not been able to trigger this with ssh, but certainly
      have been able to with Screen Sharing, even after explicitly
      re-disabling the root account.
 
  jonny_eh - 1 hours ago
  What if it's a stolen laptop with an encrypted hard drive?
 
  jzwinck - 1 hours ago
  It requires the attacker to be able to type a few characters into
  a logged in session. If the session is not an administrative one,
  it's not fair to say all bets were off.If I give you a Mac logged
  in with an unprivileged account and you can use only the keyboard
  and mouse to gain root access, the security has failed.I think
  you've conflated this with the attacker having (full) physical
  access to the machine, which conventionally means access to its
  ports and perhaps a screwdriver. This is not that.
 
    senko - 1 hours ago
    Fair point, if that works with a guest account.I was thinking
    along the lines of, if I have write access to your .bashrc (or
    a multitude of other config files that you as an unprivileged
    user have write access to, and can be used to trick you later
    into running code of my choosing), all bets are off.
 
  code_duck - 1 hours ago
  The 'attacker' could be someone like your 12 year old son or an
  employee, who already has access to the computer but not
  necessarily everything on it at all times.This would have been a
  pain for me when i was using parental restrictions to lock a 12
  year old out of 18 hour a day Minecraft.
 
  woodrowbarlow - 1 hours ago
  an unlocked computer, or:* a computer with remote login enabled*
  a computer with the main login screen set to "username and
  password" mode* a computer with a guest account
 
  EpicEng - 1 hours ago
  >In which case all bets are off anywaysHow are all bets off if
  they don't have access to a root user? This isn't Windows we're
  talking about.
 
    senko - 1 hours ago
    If they have access to the account that is being used normally,
    they can modify the (user-accessible) settings to trick the
    user into running malicious code and giving them access (or
    causing trouble even without access to the root account).
 
    mholt - 1 hours ago
    If you lose physical control over the machine, all bets are off
    because an attacker can modify the hardware to do nefarious
    things.
 
      apetresc - 1 hours ago
      I know the theory, but practically there's a huge difference
      between that type of physical access and "the victim left the
      room to go to the bathroom for 2 minutes" type of physical
      access
 
      EpicEng - 1 hours ago
      ok, sure, but in practice that is pretty unlikely.
 
  devindotcom - 1 hours ago
  nope. you can log in at the login screen, it creates a new root
  admin user
 
    senko - 1 hours ago
    Missed that part in the text, thanks.Yikes!
 
[deleted]
 
perfectstorm - 1 hours ago
What's going on with Apple's QA team ? Here's another serious bug
that I came across:I've two factor authentication on my Apple
account and now every time I use a new browser (or after clearing
the Cache) and try to log into one of the Apple developer sites it
sends me the authentication code to the same machine that I'm
using. How is that two factor ?I've an iPhone which is connected to
the same account but it's  not my primary phone so it's most likely
not ON when I do this. I guess Apple tries to send the code to my
phone and when it fails sends to the next online device which
happens to be the same machine I'm using to log in. So all I have
to do is click Allow and enter the 6 digit code which is displayed
in a different app.
 
  rgrove - 59 minutes ago
  > I've two factor authentication on my Apple account and now
  every time I use a new browser (or after clearing the Cache) and
  try to log into one of the Apple developer sites it sends me the
  authentication code to the same machine that I'm using. How is
  that two factor?Your password is something you know. Your
  computer (which is associated with your Apple ID) is something
  you have.If someone tries to log in using your password from
  another computer, your account is safe. If someone steals your
  computer but doesn't know your password, your account is safe.
  You're only in trouble if someone steals your computer _and_
  knows your password.
 
sillysaurus3 - 2 hours ago
This is the first time I've felt happy I rarely upgrade.
 
gaius - 2 hours ago
But someone at Apple got their bonus for shipping the animated poop
icon in time for this release.
 
  LeoPanthera - 52 minutes ago
  If you think the team that makes animojis is the same team in
  charge of security or QA, I have news for you.
 
orbitur - 1 hours ago
I've been a developer for a long time. I understand bugs happen,
even bugs with terrible consequences. A lot of bugs seem
understandable, like I can see the chain of ifs/thens required to
end up at some hilarious broken state.But I'm breaking my brain
trying to figure out how in the hell a login attempt for "root"
will enable it if it's disabled. Why is this is a possibility, to
just enable root, no questions asked?
 
  emmelaich - 1 hours ago
  Identity management is complex and boring.Apples user management
  is even more complex than most Unixes.
 
  e12e - 9 minutes ago
  I'm reminded of: "Solaris Telnet 0-day vulnerability", 2007:
  https://m.slashdot.org/story/80056But this does indeed seem to be
  an extra level of user-friendly stupid.
 
  zach43 - 1 hours ago
  Maybe something like this was added to make debugging/testing of
  the OS easier? maybe they just forgot to remove it before
  shipping the new macOS
 
    mk89 - 16 minutes ago
    That could be the case - I can't find any other possible
    logical explanation, because it doesn't make any sense.
 
  martin-adams - 34 minutes ago
  Like an illusionist hiding the truth, this bug too will have a
  logical explanation that will leave us in wonder for as long as
  we aren't told how it happened.
 
  migueh - 33 minutes ago
  Exactly, how can this happens and no one asks.
 
  tylerhou - 1 hours ago
  Another user suggested it may have to do with Apple?s new file
  system: https://news.ycombinator.com/item?id=15801643
 
    LeoPanthera - 57 minutes ago
    You misunderstood. He's talking about a password hash storage
    system, not a filesystem.
 
  OkGoDoIt - 1 minutes ago
  Seems to be something related to a backwards-compatibility code
  path for upgraded systems.  According to multiple posts on this
  thread it only affects systems upgraded to High Sierra, not fresh
  installs.  See https://news.ycombinator.com/item?id=15802622 for
  example.   Adding extra layers for compatibility complicates
  testing and debugging.  With this many eyes on it hopefully
  someone will be able to deduce exactly what's going on.
 
  dec0dedab0de - 1 hours ago
  I'm having a hard time understanding how this could happen too.It
  would have to be that looking up the root account enabled it,
  maybe users go dormant or something, and this was a way to readd
  them?    then once it was enabled it defaulted to a blank
  password, but you would think that it needs sudo to enable root
  in the first place.
 
    inetknght - 7 minutes ago
    Login screen is probably already running as root in the first
    place, so it already had permission to enable shell/GUI access
 
    pishpash - 14 minutes ago
    Not only enabled it but actually set an empty-string password.
    Usually the stored hash for a disabled account is not in the
    hash space, so it was either overwritten, or root account
    password was actually empty string out of the factory. That and
    the enabling of the account both point to debug code
    accidentally left in (or intentional backdoor by the
    disgruntled).
 
quicklime - 2 hours ago
Anyone else think it was a bad idea to disclose this so publicly
over Twitter? I thought that the usual practice was to let the
development team know first.
 
  [deleted]
 
  5ilv3r - 2 minutes ago
  Time and time again we have been shown that the way to a
  company's heart is through it's PR department. This is a dev
  complaining to Apple like a lunchgoer would complain to Mc D's
  about a bad burger. Expect more of it.
 
  [deleted]
 
  SAI_Peregrinus - 1 hours ago
  Letting the development team know first is nice to the
  development team, but not so nice to the users (especially not-
  nice if there's a workaround, which there is in this case.)My
  personal policy: If there's a workaround or mitigation, then full
  disclosure is more responsible. If there isn't then report to
  developers and CERT or similar. Never report only to developers,
  always have a deadline for full disclosure, and always have a
  third-party (CERT, Project Zero, etc) to disclose if you come
  under legal fire.
 
alexwebb2 - 1 hours ago
I asked this in the other thread, but... does anyone know how big
of a bounty the guy missed by not disclosing this responsibly?I'm
guessing it probably would've been a fairly big chunk of change.
 
  silencio - 1 hours ago
  Apparently there is no macOS bug bounty:
  https://twitter.com/i0n1c/status/935608248027303936
 
afiler - 3 hours ago
Even on El Capitan, I was able to unlock with "root" on my first
try. From there, I could add a new admin user. This seems... not
good.
 
  joshvm - 3 hours ago
  I wasn't able to do it on 10.12.6 (Sierra) though, so perhaps
  there's something else odd here?
 
    uuuuuuuuuuuu - 2 hours ago
    Doesn't work for me either on 10.12.6.
 
  jobu - 2 hours ago
  When I tried to make a new user after unlocking as "root" it
  ended up making a group instead. (High Sierra 10.13.1)
 
  cthalupa - 2 hours ago
  I cannot reproduce this on Sierra or El Cap
 
  JustSomeNobody - 2 hours ago
  Especially not good is Apple likely won't fix it in El Cap.
  They'll tell all of us to upgrade. I don't want that buggy HS
  mess.
 
cmurf - 2 hours ago
I can't reproduce this on a clean 10.13.1 (17B48) system, either at
the login window or an authentication dialog.Update: And even after
attempting it, checking Directory Utility the root user is still
disabled. So I wonder if something 3rd party has enabled the root
user and left it passwordless.
 
srathi - 2 hours ago
Confirmed on 10.13. I was even able to add a user as an
administrator after unlocking with root.
 
romanovcode - 2 hours ago
Who needs security when we have animoji!
 
tzakrajs - 2 hours ago
Can't reproduce on multiple High Sierra machines.
 
  mikestew - 2 hours ago
  Can't repro on a 2012 retina MBP running 10.13.1, attempting the
  original repro and others suggested here. Until the wife walks
  away from hers, it's the only machine I have available. I'm
  curious as to the difference, given the high number of repros.
 
    pault - 1 hours ago
    Apparently you have to have the password field focused before
    you submit. Anything in the password field (including nothing)
    will be saved as the root password.
 
      tzakrajs - 1 hours ago
      Does it work if you set the root password and try again?
 
tekacs - 1 hours ago
Now that this is public, it's likely worth passing this message on
to non-technical folks too (e.g. share this or write a similar post
- this is my only public
post):https://www.facebook.com/amar.sood/posts/10209545863036116
 
  jtokoph - 1 hours ago
  Important error in your instructions. They should set a very
  strong password and keep the root account enabled. Disabling the
  root account opens up the vulnerability again.
 
    tekacs - 1 hours ago
    Edit: Okay so it seems that my shell based suggestion of
    `dsenableroot -d` prevents the bug from re-occurring, but not
    the GUI version. :facepalm:I updated the post to include the
    word 'strong', although I would expect most users to simply set
    their own password, which should provide identical security to
    what they currently (should) have.Disabling the root account
    does not open up the vulnerability again.This vulnerability
    doesn't reset the root password, it only enables the root
    account and checks the password against that. The default root
    password out of the box on OSX is blank which is what allows
    this to work as-is.By setting a root password, the next time
    you attempt this (and I tried it), the attempt fails since the
    'root' account now has a password set.Disabling simply puts the
    root account back in a dormant state, where it should be for
    most users, for after this vulnerability is fixed and it can't
    be enabled maliciously.
 
  [deleted]
 
joe_hills - 3 hours ago
I just tested this on a Sierra (10.12.6) machine, and verified this
bug isn't present in that earlier OSX version.
 
  Cshelton - 2 hours ago
  Same, I'm on 10.12.6, could not reproduce anywhere.I think I'll
  hold off on that 10.13.1 "security update" it keeps bugging me
  about. Seems to let anyone use my computer...Edit: After looking
  a little further, it seems staying on Sierra will always be a
  10.12.* version, and High Sierra is 10.13.*?
 
    m11r - 2 hours ago
    Yes, that's correct. Recent macOS (nee OS X) versions:-
    Mavericks (10.9.x)- Yosemite (10.10.x)- El Capitan (10.11.x)-
    Sierra (10.12.x)- High Sierra (10.13.x)
 
nathancahill - 2 hours ago
Fix this by setting a password for root (or disable).Instructions
here: https://support.apple.com/en-us/HT204012
 
  Asmod4n - 2 hours ago
  Doesn't help to disable it, you have to change the password.
  UPDATE: if you disable the account after setting a password, a
  login without a password is possible again ..
 
    3pt14159 - 2 hours ago
    Yeah, confirmed it myself too. Enable root with a strong
    password works though.
 
bsaul - 1 hours ago
I wonder who they're going to ask to write a public letter of
apology this time.This isn't just a snarky comment. They have just
released the most awfull iOS upgrade for a long time, and now this.
Something's messed up, and they better fix it soon.I've think i've
read somewhere they merged the iOS and macOS teams, i suppose the
wrong people were promoted during the operation.
 
  romanovcode - 1 hours ago
  They will use some clever words to make it sound like a trivial
  issue like they did when password was appearing instead of
  password hint couple of months ago.
 
  rimliu - 1 hours ago
    > They have just released the most awfull iOS upgrade for a   >
  long time, and now this. Something's messed up, and they   >
  better fix it soon.  I keep seeing this written after each major
  iOS release sinc at least iOS 7.
 
    bsaul - 58 minutes ago
    For me, the most painful is that this time they managed to
    screw up the damn keyboard while bringing absolutely nothing
    new. I can't even use hangout or chat on my iPad Air , i have
    to wait 3 seconds for my words to appear.That's just wrong.
    There's no excuse for that. We're not talking about fancy
    animation or new features that we think aren't a great idea.
    Just a basic regression on one of the most fundamental things
    you can do with this device (the other being displaying
    things).Another thing is that they usually fix slowdowns and
    stability with the following release soon after. Not this time,
    so my guess is that it'll be a "change your device" kind of
    upgrade.
 
      saagarjha - 13 minutes ago
      > I can't even use hangout or chat on my iPad Air , i have to
      wait 3 seconds for my words to appear.Obviously, something's
      wrong with your keyboard, but how do you know it's iOS's
      fault instead of your app's?
 
  davidkuhta - 1 hours ago
  Cue "incorrect elevation of privileges" joke.  sudo laugh  edit:
  spelling
 
    nolok - 59 minutes ago
    Nah you don't need sudo for that anymore, now you're root
 
    intelliot - 1 hours ago
    Cue
 
      davidkuhta - 1 hours ago
      doh, thanks. Can you tell what abstract data type I've been
      working with lately?
 
butterisgood - 14 minutes ago
Doesn't work for me on a freshly installed MacOS High Sierra, but
does work on an upgraded laptop to High Sierra.Interesting...Also
the UX is different. Typing root on the fresh installed one fails,
then resets the user text box to my name, and if I type root again
it doesn't let me it.On the upgraded laptop, if I type root, it
sticks and clicking unlock twice gets me in.