Slashdot Mirror
MacOS High Sierra Bug Allows Login As Root With No Password (theregister.co.uk)
An anonymous reader quotes a report from The Register: A trivial-to-exploit flaw in macOS High Sierra, aka macOS 10.13, allows users to gain admin rights, or log in as root, without a password. The security bug is triggered via the authentication dialog box in Apple's operating system, which prompts you for an administrator's username and password when you need to do stuff like configure privacy and network settings. If you type in "root" as the username, leave the password box blank, hit "enter" and then click on unlock a few times, the prompt disappears and, congrats, you now have admin rights. You can do this from the user login screen. The vulnerability effectively allows someone with physical access to the machine to log in, cause extra mischief, install malware, and so on. You should not leave your vulnerable Mac unattended until you can fix the problem. And while obviously this situation is not the end of the world -- it's certainly far from a remote hole or a disk decryption technique -- it's just really, really sad to see megabucks Apple drop the ball like this. Developer Lemi Orhan Ergan was the first to alert the world to the flaw. The Register notes: "If you have a root account enabled and a password for it set, the black password trick will not work. So, keep the account enabled and set a root password right now..."
it creates a root account with no password
By default, there's no root account. Attempting to log in as root with no password multiple times creates a root account with no password.
How can you possibly have a root account without a password?
You certainly can, at least on most *nix flavors. Not the greatest idea though.
That makes sense, thanks. Both the story and the linked article weren't really clear.
John C. Randolph (aka jcr), can you please comment on this issue?
Maybe I'm mistaken, but I've heard that you worked at Apple in the past. I've also seen some of your comments here, and I know you're a man of integrity.
Can you please tell us what's actually going on here? Can you help us distill the facts from the stew of information that's surrounding this issue?
Is it as big of an issue as it's being portrayed as?
If it did happen, what factors do you think contributed to a bug like this being introduced and making it past whatever QA processes Apple has?
What could be done to prevent bugs like this?
We need you to help us understand this matter. Any background and information you could give us would be greatly appreciated.
Thank you, sir.
You're missing that it works if there is a disabled root account without a password too. Many people just give their own account admin access or create an admin account that isn't named root and disable the "root" account. You'd think that would be safe. It isn't.
OS X by default disables the root user and doesn't have a password set. This "exploit" takes advantage of that fact.
is "courage" to go beyond the heteronormative system of power and privileges. Why would you require privileges in a progressist society where everybody is equal.
USER LIVES MATTERS !
And no, not my SE/30 that runs NetBSD.
There is no "enter" key on a macOS (unless you include the fine print on later models - disgusting!). One of the identifying marks of a Dark Side Convert is their use of the phrase "hit enter". Cheers
Set the root password to something long and hard to guess (32 chars of mixed-case alphanumeric should do). Do this by running as an administrator:
sudo passwd -u root
This should do until Apple releases a real fix.
Source
Finding God in a Dog
Yes this is obviously the fault of Tim Cook. Forcing the poor programmers to insert security holes is indeed his MO as should be obvious from this article:
http://www.theregister.co.uk/2...
I can understand if it let you in after hitting enter once, because then it's just ignoring something. If it denies entry the first few times and then lets you in, what do the *nix gurus think is happening after the first few denials to have it change its 'mind?
"There is no real right or wrong, just what the majority accepts at the time."
Why the quotes around exploit?
https://forums.developer.apple.com/thread/79235
'course, this post may not have been reported directly to security folks. it was something that they should have found while monitoring the beta forums, though.
From what I can gather, the bug is that a non-admin account can create an enabled root account without a password if there exists a disabled root account, regardless of the existing root account's password. And by default, a High Sierra install's root account is disabled, I think.
So, logging as root without password works on High Sierra if there's a root account without password?
Just works with whatever is the default user configuration. I never modified anything other than creating an OSX user for myself.
What's even better is that if you have remote desktop turned on, anyone can connect and login as root.
Yes this is obviously the fault of Tim Cook. Forcing the poor programmers to insert security holes is indeed his MO as should be obvious from this article: http://www.theregister.co.uk/2...
Or maybe under Tim Cooks leadership the overall quality of Apples software and hardware has noticeably declined.
One can have anything if one has Courage.
Just because you are paranoid does not mean that no-one is out to get you.
You first have to be logged in, presumably as an admin user, then try to do anything like change login settings where the user/password authentication pops up. Log in root / no password. It will let you complete the current task... and subsequently log in.
Someone needs to be fired at Apple.
The correct response, as always, is for people to chime in with Mine Works Fine/I've Never Had A Problem posts.
Seems like a pointless thing to show up and say, but tradition is as tradition does.
This isn't an apple-exclusive phenomenon, but they are the masters of it.
Srsly, dude? Mac OSX is pretty much the slickest thing out there. Which OS, specifically, do you want Tim Cook to give you back? System 7? System 8? Because those were so much better..?
And you never ship bugs? Ever? Shit happens, get over it.
Parent is also incorrect, there is always a root account. I would hazard a guess the issue is with sudo as that is the underlying mechanism for privilege escalation.
My educated guess from 20 years in computer security:
The graphical UI it gives up after a few tries, which is reasonable. Unit tests tested that you can login that way and maybe tested that it gives up.
Separately, on the underlying Unix side they may have tested that part well - if you enter a correct password you get in, an incorrect password doesn't get you in.
In Integration testing UI designers made sure it WORKS - you can log in that way. They didn't test crazy shit like entering a million-character password, entering no password over and over, etc. Who would do that anyway? Besides, "garbage in, garbage out", right?
No! "Garbage in, garbage out" is not okay for anything related to security, or really anything connected to the web. Security stuff has to expect garbage input of all kinds - megabytes of input when only a few bytes are expected, passwords with line feeds, empty input, etc. It has to be "garbage in, denied". Which normally means checking for whitelisted sane input first, and denying if the input is anything other than what you expected. Applications exposed on the internet are similar - you have to expect you'll be attacked a thousand times a day.
Therefore it's not enough to test that it works. You have to think about all the ways it could fail, ways it could not work, and test those.
First of all, when I ship bugs, I fix them if it's within my abilities to do so. Which is usually is. And I will tell you flat out that if I had billions of dollars in the bank, I'd be able to fix every one that was found, because there are people I could hire that are way smarter than me, and I could hire a lot of them without feeling any pain at all.
My problem with Apple isn't that they ship bugs anyway... it's that they leave serious bugs in place even when they know about them.
So I'll get over it when they stop behaving like incompetents, and no sooner.
I've fallen off your lawn, and I can't get up.
Is no root password a requirement for this "bug"? My Macbook has a root password. I followed the directions in the summary, and it did NOT give me root. I tried several variations. Nothing worked. So as far as I can see there is no bug.
This is literally nothing like that issue. To "exploit" that issue you already have to have root access. It is the typical "OMFG, if you are root you can get root privs!" cry of the moron without a clue.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I submitted this a couple hours before it was posted on the front page. Why does it say an anonymous reader posted it? https://slashdot.org/submissio...
I set my root account to /bin/false
Tried it on three different machines, both from admin and non-admin accounts. All running 10.13.2 Beta (17C83a).
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Its like PRISM https://en.wikipedia.org/wiki/... found new ways in.
Domestic spying is now "Benign Information Gathering"
Seriously, any one who knows a bit about unix will enable the root account and set a fairly strong password.
It is only the "Its Apple! Its immune to hacks!! Its got the ultimate security!!!" fanbois will be affected.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I really don't get why a company with that much cash in the bank can't manage to field a decent OS test protocol system.
Because OSX doesn't run on an iPhone. They didn't get that much cash in the bank by dumping a bunch of effort into an OS for a platform that really doesn't make them very much money. Despite the MacBook and OSX being a great device, it's now the read-headed stepchild at Apple. And they keep trying to make it more like the iPhone by cramming iTunes and the App store down my throat...
#flamebait #noobs
so it's not exactly "far from a remote hole or a disk decryption technique" as the post suggests. If Screen Sharing is turned on, it allows remote login; if you have access physically or via Screen Sharing, you can use it to turn off FileVault. So it's potentially both a remote hole AND a disk decryption technique. "sudo passwd -u root" now if you hadn't already reset the root passsword!
I've tried to reproduce it on three different machines, all on the latest beta, and it's not happening for me. From what I've seen, it doesn't appear to be remotely exploitable, so it's only an issue if an attacker has physical access to your machine.
So, I'd say it's serious but not catastrophic.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Right.
I got my first computer in Feb, 1978 -- TRS-80.
Discuss.
It little behooves the best of us to comment on the rest of us.
So... Windows' fault?
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
did not enable root and set a hard to guess password?
I mean, come on, a lawyer, designer, doctor, writter or grandma with a mac, I can understand that is actually BETTER for them to have no root account by default. No disrespect, maybe you Lawyer/designer/writter/doctor/gramma are ultra smart in your field (and perhaps many more). And I am sure know you know way more about your field than I'll ever be....
But Slashdot has a big proportion of programmers, computer scientists, and EETREs (Electrical/Electronics/Telecoms/Robotics Engineers) readers.
Who of that slashdotian demographic in their right mind did _not_ enable root and set a strong password for it on their mac?
I know I did. As is the first thing I do everytime I bring a new mac home.
BTW, for those who did not read TFA, the workaround for the problem is to enable root account and set a strong PWD.
*** Suerte a todos y Feliz dia!
"Mac OSX is pretty much the slickest thing out there."
Wet Platinum would disagree with you, there.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Yep.
You can lock down those features, but pretty much nobody does.
Of course, you also cannot reset your account password and regain access if you have turned on FileVault.
I just reproduced it.
I have a MacBook Pro that I upgraded to High Sierra (10.13.1) over Thanksgiving. My login screen is set to only offer the pre-defined user accounts. I logged into a non-privileged account that I keep around for testing purposes. Went to the top-level of the file system; did a "Get Info" on a folder I didn't have access to; asked it to show me "Sharing and Permissions"; clicked the lock icon to unlock them; got a username/password dialog box; entered "root" as the username with a blank password once; the dialog box shook and cleared; entered "root" with a blank password again, and the action completed with the lock unlocked. Now when I go to the login screen, I have an "Other" account showing; if I click "Other" I get a username and password dialog box; if I enter "root" as the username with a blank password Bob's your uncle. Logs right in, shows the username in the upper left of the screen as "System Administrator." The account has root access to the machine.
This is probably exercisable remotely if remote logins are enabled (screen sharing, anyway); I don't think anything I did would not be doable through a remote login (but I have not the means to test at the moment). Seems like there might be some blood on the floor over this one, at least at some organizations. I don't envy sys admins in large academic environments either.
Summaries change? Why the fuck do they never proofread, edit and correct anything, then? Black password? Fuck off BeauHD and you do-nothing editors.
Do it from a dialog of a logged-in user-- something like the preference pane, lock the "no changes" padlock, unlock it, and use user as root hit unlock...
I followed up with a remote test, and the attack works fine over "Screen Sharing" (VNC) to my iMac 27" from circa 2013 that I also just upgraded to High Sierra (10.13.1) over Thanksgiving. Merry Christmas.
Needless to say, I now have a root password set on my Mac-in-trashes. I didn't before because the root account isn't normally enabled and I was not being sufficiently paranoid; sigh.
With it not being in the subsequent beta release and no other previous releases, I'm guessing it's a back door intended for Q/A purposes that was accidentally left in the code.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
Who doesn't set a root password on a new computer?
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Why the quotes around exploit?
The quotes allow for de-escalation synonym transposition that helps to stabilize the reality distortion field that protects the mac psyche... without it Apple would surely implode.
From what I gather so far, you're missing software freedom. Whether this is creation of an unprivileged account named "root" or granting admin privileges to anyone patient enough to "click on unlock a few times" (as the story intro claims), something is wrong. Are MacOS users still being denied the permission to inspect what's really going on in the source code, fix the problem, and distribute fixed code to others?
In the referenced twitter.com thread, Apple wants to "take a closer look at what's happening together" in an unpublished discussion ("Send us a DM that includes your Mac model along with your macOS version. We'll meet up with you there."). There are plenty of skilled programmers willing to help but without software freedom, this makes Apple look even worse than their lame attempt at seeing the problem which it's entirely possible only they have the privilege to really study, understand, and fix.
Digital Citizen
Are you retarded? What the fuck do you think an exploit is?
.....It 'Just works!"
The technique described exploits the bug to give somebody administrative access. I'm not sure you understand what you are talking about when you use a phrase like "it is a bug that will be used like an exploit".
No, by default the root account is disabled, but it's there.
This smells like a misconfigured PAM. Apple does a lot of weird and non-standard stuff with the *nix user land, so they probably introduced the vulnerability that way. An improperly configured PAM stack can, for example, try a particular auth mechanism a preconfigured number of times before moving to the next auth mechanism. That fallback mechanism could be the Apple directory service, which doesn't handle the root user and leaves it to the system, but ignores the *nix convention that a passwordless entry in /etc/passwd is a disabled account. Not sure exactly what is happening and don't have a system to test on.
Best workaround is to set the shell of the root user to /bin/false. That will block any attempt to get an interactive login.
macos uses launchd.
https://wiki.gentoo.org/wiki/C...
Doesn't work on mine (have 10.13.1)
Slashdot, fix the reply notifications... You won't get away with it...
October 1979, spend half an hour trying to figure out how to answer "Memory Size?", as it was (IIRC) not in the instruction manual(s). Went Mac in 1985, after a short side-trip through CoCo land to play with 6809 code.
I smugly know that I'm not vulnerable to this because I normally run 10.9. The highest I have is a Mac Mini that came with 10.12 installed, and once I "jail broke" that one, there was no reason to downgrade. I wish companies would quit trying to "re-imagine" operating systems all the time. And quit trying to make "pro" hardware "thin" (or round) for no good reason.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
So, I just tried it on a completely fresh install, and I was able to reproduce the bug. No idea why it didn't manifest on any of my existing installations.
I would expect that the relevant teams at Apple will push an update to fix this in a day or two at the most. In the meantime, you can work around this from any administrator account by setting a password on the root account ( open a terminal window, enter "sudo passwd root", and follow the prompts.)
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
As it turns out, I did just reproduce it on a fresh install that I updated to today's beta.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
From the GUI go to Command-Space > Directory Utility, click the lock and check the Edit menu for "Enable Root User" or "Disable Root User" options.
From a Terminal use the dsenableroot command.
Doesn't work on mine (have 10.13.1)
Having an enabled root account with a non-blank password disables this vulnerability. Does that match your situation?
Christ just give me back the samaba implementation from 10.6.8 when it acutally worked
Srsly, dude? Mac OSX is pretty much the slickest thing out there. Which OS, specifically, do you want Tim Cook to give you back? System 7? System 8? Because those were so much better..?
System 7.0.1 was awesome -- I don't know what you're talking about. And Mac OS 8.6 (with the NuKernel and a few cherry-picked Copland features) was damn stable for me too. Much better that MacOS 9, which was only useful for giving FileVault and VoicePrint login demos...
But try to stick 8.6 on Rhapsody and you kind of had a halfway decent OS, ya know?
Hire a Linux system administrator, systems engineer,
They are not an enterprise company.
and they will tell you this, ad nauseam...any time you have an issue they cant fix.
It was shit under Steve Jobs as well. Apple iPhone power button anyone that was still defective suffering the same failure four releases later? The only difference between Jobs and Cook is Tim Cook doesn't have people who think of him as the second coming of Christ so they're not as blinded by faith as they were before.
I only please one person per day. Today is not your day. Tomorrow isn't looking good either. - Scott Adams
It doesn't work now because anyone with an ounce of common sense is turning off SMB1.0 on Windows.
I only please one person per day. Today is not your day. Tomorrow isn't looking good either. - Scott Adams
Indeed, that's the case
Slashdot, fix the reply notifications... You won't get away with it...
I believe the problem here stems from the fact that some time ago, Apple decided it would be a peachy idea, (pun definitely intended) to do away with a root user, and just let the regular user do privileged things by sudo-ing them, locking the high-privilege stuff with the user password. The sad part is that that makes it so they could have the root account HAVE no password. BAD PROGRAMMING, Apple. BAD. SUCKY. PATHETIC.
Also, on another note... COME ON, APPLE! JESUS HOLY M.F.'ing CHRIST! Don't you even test the beta software you're pushing out as if it were production-ready?!? You guys are getting to be as bad as MICROSOFT!!! This is amatrurish, Microsoftish crap, shipping something with this big of a hole in it. This is worse than Kryptonite's 'open-with-a-BIC-pen' locks. At least with THEM, you needed to have a BIC PEN!
Just because you don't call it beta does NOT mean it's not beta quality. Or sub-beta quality.
I swear one of these days I'm going to put GNU/LINUX on all my Macs and wash my hands of iMac-OS-X (or whatever they're calling their buggy, un-secure garbage OSes this week,) once and for all!
TIRED of Apple's CRAP! TIRED of it!
Our reign has gone on long enough. Indeed. Summon the meteors.
Discuss. OK. Well, I know that you old timers have trouble keeping up with the lingo "the youth" use these days and all their newfangled technology, but, clearly, this is flamebait and you are trolling. As it turns out, The Oxford English Dictionary places the origin of the term "Troll" in 1990 on Usenet in which veteran users would "Troll for newbies", or "noobs" and yank their chains a bit. So, I think you may have misunderstood my second hashtag (and hashtags in general). One clue was the pluralization of "noobs" - as you would (hypothetically) be a singlenoob this would not apply to you. Secondly, hashtags go at the end of a twitter post, and this was meant as a comical appendix to your comment, implying it would be you (the self-proclaimed old-timer) calling everyone else "noobs" for responding your flamebait comment. In this way, I use sarcasm to call out and shame you for your flamebaiting. Clearly, all Operating systems have bugs and always will. Claiming one is better than another is just trying to start a flame-war. Frankly all OSes suck. Just differently.
Exactly
By default, there's no root account.
Are you sure of that?
The root user is disabled by default. If you can log in to your Mac with an administrator account, you can enable the root user, then log in as the root user to complete your task.
Slashdot, fix the reply notifications... You won't get away with it...
If you enabled the root account and set a password, like you did, there is no problem. However, if you never set up the root account (like the vast majority of users), the dialog first rejects but then accepts the login after a few attempts. That's definitely a bug, and a very serious one because many people just put their laptop to sleep instead of shutting it down, which makes the login box the only remaining protection even if you have disk encryption enabled. Any thief can now open the lid, log in as root, and read your files.
By default, there's no root account. Attempting to log in as root with no password multiple times creates a root account with no password.
Wow... they'll give anything a "5: Informative" won't they?
Yes, you're missing something. There IS a root account, it's just configured not to let you log into it. If you'd like to see, open a terminal on a Mac, type "sudo su" followed when prompted by your user password, then type the command, "whoami" and press enter. It'll respond "root". This is true for all Macs, as far as I know, at least, as they come from Apple. Maybe there's a way to change the root account, so you can make this be, not true, as it were, for YOUR specific Mac... but yeah. When you're done marveling at how you have a "#" prompt now, (indicating super-user access, as opposed to the normal unprivileged "$" prompt, you might want to type "exit" and get out of super-user mode, before you go and rm -rf something important.
Our reign has gone on long enough. Indeed. Summon the meteors.
SCP won't work if the default shell is set to /bin/false, and current versions of sshd don't allow root logons by default unless you install an ssh key. Although giving the root account an invalid shell will also break single user mode and various system functions, possibly even preventing the system from booting.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I wonder if it works when logged in via the guest account (if enabled)?
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
No, by default the root account is disabled, but it's there.
This smells like a misconfigured PAM. Apple does a lot of weird and non-standard stuff with the *nix user land, so they probably introduced the vulnerability that way. An improperly configured PAM stack can, for example, try a particular auth mechanism a preconfigured number of times before moving to the next auth mechanism. That fallback mechanism could be the Apple directory service, which doesn't handle the root user and leaves it to the system, but ignores the *nix convention that a passwordless entry in /etc/passwd is a disabled account. Not sure exactly what is happening and don't have a system to test on.
Best workaround is to set the shell of the root user to /bin/false. That will block any attempt to get an interactive login.
This is incorrect. LOGGING IN AS ROOT is disabled. You can still trivially get to be root from a user account in terminal by typing "sudo su" and pressing enter then entering the USER password when prompted. To verify, once you do this, (and have a "#" prompt,) type "whoami" and see if it doesn't respond, "root". To fix this, while logged in as root, just type "passwd" and set the super-user (root account) password. Make sure you will be able to remember it, as if you ever DID want to do anything AS root, you might need that. (You could change it, forget, and still be able to access root through the same means, using "sudo su," as it will still only ask for the USER password to get there, but if you ever did alter... /etc/... something, I forget what, to make it possible to log in AS root, properly, (rather than backwards through sudo su,) which I believe IS possible though can't recall how exactly, you WILL need the root password you just set to log in as root.).
BEAR IN MIND: you can also, once a root password is set, type "su root" and become root THAT way. Going THAT route, you WILL be prompted for the ROOT password, NOT THE USER one. (It won't tell you which it wants, it's just that going 'sudo su' and typing the root password fails, typing the user password succeeds, while going 'su root,' typing the user password fails, but the root password (once one exists,) succeeds.). I don't know if you can "su root" with no root password set, in fact, I think it's designed NOT to let you do that, since by HAVING no root password, there'd be no way to log in. "/bin/sh" would check for the /etc/passwords file, or whatever, wherever it's kept on a Mac..., and finding no entry for root, would fail the login attempt, and reply "su: Sorry" or something like that. (I can't now test how that works on a Mac, having recently added a root password to my machine, but I vaguely recall it went something like that.)
Or something like all that. It's late enough that I could be a little fuzzy on the details. I think actually that once "su root" works, that just using "su" would work too, as it defaults to root...
Our reign has gone on long enough. Indeed. Summon the meteors.
It's pretty common to do on BSD systems, because there are a bunch of things that add extra checks for blank passwords and so effectively disable use of the root account. For example, SSH won't allow root login if the root password is blank. Only members of the wheel group can su to root and if you put users in a sudo-enabled group but not in wheel then no one can su to root. If you can mark consoles as insecure then root login is disabled by default on them. This basically leaves you with booting to single user mode as the only way of logging in as root. This is basically the setup that macOS uses: the root account is effectively disabled by setting the password to blank (modulo bugs like this).
I am TheRaven on Soylent News
If you want to be technical, this is a vulnerability. An exploit is something that (as its name implies) exploits a vulnerability (which is a category of bug that can be used by exploits).
I am TheRaven on Soylent News
If it created a new $random (here: "root") account, it quite certainly wouldn't have userid/groupid 0, thus no access to all of the system. I'd rather hazard a guess (haven't read up all the gritty details, in true /.-fashion) that in fact, it enables the pre-existing root account (with userid/groupid 0) with an empty password. It would be illuminating to check the MacOS equivalent (or have they kept them? Don't have a Mac, won't get one) of /etc/passwd and /etc/shadow files before and after this hack.
you're correct about the behavior of su; i tested it last night after hearing about this.
"They were pure niggers." – Noam Chomsky
I propose we give this bug a name: Superuser Login Absent Password, or SLAP for short.
A disabled account in unix has as password a * (but it still allows SSH login, provided the keys are distributed)
Having an empty password field is completely allowed.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Why so complicated :D
Just do "sudo bash"
But well, obviously I simply do a "su -"
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Or maybe under Tim Cooks leadership the overall quality of Apples software and hardware has noticeably declined.
Under Jobs we got Apple Maps, so bad it could actually kill you. We had numerous testing and quality issues from Apple, like the MacBook 1/4 gallon of thermal paste issue or the classic iPhone 4 antenna "holding it wrong" design flaw.
Even going back to the CRT iMac you had CD-ROM drives with no emergency eject hole, meaning if the disc got trapped you had to disassemble the whole thing (complete with high voltages from the CRT floating around).
Don't mistake the shiny veneer they put on stuff for competence. 16 years later and iTunes is still a turd.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
What you want to have as prompt you usually configure in your .bashrc file or what ever shell you use.
While # is traditionally used for root and $ for user accounts, you can set it to anything you want.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Of course it works via screen sharing.
How should the log on system know that you are doing it via a shared screen and not via the console?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Your license to use capitals is hereby revoked. Please surrender your shift and caps lock keys immediately.
This is incorrect. LOGGING IN AS ROOT is disabled. You can still trivially get to be root from a user account in terminal by typing "sudo su" and pressing enter then entering the USER password when prompted.
Yes, you are correct. What I meant was any login (invoking the standard pam_unix module) to the root account is disabled, which includes "su root". Sudo works because it uses the setuid bit to elevate your permissions without first authenticating the root account. It is a convenient method to allow people to run programs as root without logging in as root, and linux distributions such as Ubuntu have been setting up the userland that way by default for many years. It works pretty well as long as you have a properly configured /etc/sudoers file.
Although giving the root account an invalid shell will also break single user mode and various system functions, possibly even preventing the system from booting.
Are you sure about that? I admit I haven't tried it, but I don't see why it wouldn't work. The only reason to consult /etc/passwd would be to authenticate the root account, which pam_unix treats as disabled if the password is blank. Su and login require a valid shell entry, but AFAIK nothing else does. Sudo doesn't require the root user to have a shell, and neither does init. So it seems like pretty good insurance to me. If, for example, somebody sets nullok in pam.conf allowing the root user to login with a blank password, the invalid shell entry will block it.
You are right that it would break single-user mode, but you can probably fix that by editing your init script.
Really? Something to back that up would be nice...
There are (at least in history) operating systems that use the source of a login to determine whether the login is allowed. Some of these can be configured to block root logins from any source other than the local console. I'm not directly familiar with how MacOS "screen sharing" is tied into the OS (i.e., did a login coming through the "screen sharing" mechanism show a different login source that was used to limit certain behaviors), so it was worth it (to me) to validate that the technique worked via "screen sharing" rather than just assume it did (and have someone else point out my stupidity later). Words to live by: "There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy."
Unhappily, and perhaps/hopefully entirely coincidentally, the Open Directory database on my MacOS server got borked during my testing, and had to be manually recovered to restore the network accounts on my machine. I'm wary, because this is the first time in 3 years that this Open Directory database has failed on me, but I really don't want to spend hours determining whether their is a relationship if i don't have to. Please Apple, deliver an OS patch today. This low-level stuff is supposed to "just work" so that I can spend time dealing with "higher level" problems.
A root account with no password is a fantastic idea to increase user friendliness. Everything should be easy to use. Remember the UI principles. Point and click rather than Remember and Type. Why should a Mac user have to be burdened with remembering a password?
I'll see your senator, and I'll raise you two judges.
current versions of sshd don't allow root logons by default unless you install an ssh key.
Bullshit. That is a configurable option in /etc/ssh/sshd.conf
PermitRootLogin yes
or
PermitRootLogin without-password
I'm not a complete idiot... Some parts are missing.
By default the account "root" is disabled, however, if you use this exploit, you enable the root account with no password. The workaround is literally enabling the account and setting the password. I almost freaked out when I found this exploit.
sudo mod me up
The fix was just posted.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Details here.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
<account name> is not in the sudoers file. This incident will be reported.
Now I'm scared!! THANKS a LOT!!
slashdot: A failed experiment.
The default settings are a root account that is disabled for logins, with no password, because it is (duh) disabled for logins.
It seems it's the "disabled for logins" part that got broken under this bug, at least for some path in the code that deals with multiple failed login attempts.
Someone had to do it.
Exactly what did i say that was bullshit?
The default configuration on modern versions (since 7.0) is to only allow root logins with keys, see:
https://www.openssh.com/txt/re...
I never said it wasn't configurable, i said password root login is not enabled by default.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
technically it belongs to my employer.
"They were pure niggers." – Noam Chomsky
Whistler? Vail? Your attempt at funny needed to include the funny.
You forgot the class actions for things like defective batteries and capacitors.
He provided zero proof. Therefore, what the fuck did it add? Nothing.
Oh i get the need to get off the old samba, I don't get the ineptitude in writing a version that works correctly. everything from 10.6.8 onward has been broken horribly
Or we could just call it the "I Am Root" bug.
Yeah, I hadn't heard that "convention" before. Casts doubt on the rest of the comment.
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"