If you have sudo / root access already... Why are you messing with the system clock?
You can already create another admin user or edit the sudoers list and create a user with full root permission. You can even do neat things like create private keys and backdoors for later use, and hide them from even the root user which would allow you later access.
This vulnerability is pretty dumb. And limited in scope. And doesn't even provide short term advantages.
Companies operate under different rules than individuals, and they're more likely to be targeted by evildoers to steal business information or plain money(not that botnets or other types of wrongdoing would pass on non-business, not my point )
Yes, and companies are likely to have admins who can easily prevent this problem.
1. Set the clock so it requires a password to change it.
2. Set a different password for root.
3. Set up user accounts rather than giving users admin accounts (which should probably be the way a business would set it up, anyway).
Any business who cares will use #3 at the very least, so it wouldn't be a problem.
My understanding is that this exploit works if the user is already logged in as Admin; thus the attacker doesn't need the password. And if Sudo was already run once before, it won't ask for a password(?) so again, no need for the attacker to know the password.
That said, if you can do all that, can't Sudo do more than change the clock?
Maybe Sudo should just always require an admin password to launch?
If you have admin access, you have a password that you can use to SUDO, anyway. Very, very, very few people actually have multiple passwords and accounts on their machines. Every single person I know (with one exception) operates with a single password - and all their files are accessible at any time.
I've argued this point before: it is possible for a piece of malicious software to run as a given user without knowing their password!
If you can get a user to open a webpage which exploits a security hole in Safari, or get them to open a malicious email attachment, then you have system access as that user. Once you have that, then you can use this time setting exploit to become root and start modifying system files, install kernel modules, daemons which harvest keystrokes, whatever. All without ever knowing a password.
So yes, there's a big difference between being able to access a system as an admin user, and being able to access it as root. And it's possible to access a system as an admin user without knowing their password. So this time setting exploit is significant.
My understanding is that this exploit works if the user is already logged in as Admin; thus the attacker doesn't need the password. And if Sudo was already run once before, it won't ask for a password(?) so again, no need for the attacker to know the password.
That said, if you can do all that, can't Sudo do more than change the clock?
Maybe Sudo should just always require an admin password to launch?
All of what you said is correct. The big deal here is that you don't actually need to use sudo (or authenticate at all if you're an admin user) to change the clock. And, by setting the clock to the epoch, you can then bypass password authentication for sudo if it's ever been run at any point in the past.
But yes, that would fix the problem (making sudo always require a password). It's mainly an inconvenience for sysadmins to have to keep typing their password all the time, but certainly this exploit outweighs convenience.
I don't think an application can gain root privilege if it was not launched as root, in which case this would not work.
An app isn't *supposed* to be able to gain root privilege if it's not launched as root, but the whole point of this vulnerability is that it bypasses that particular restriction. All a malicious app has to do is to run a few command lines:
1. Change the clock date using the systemsetup command-line tool
2. Relaunch itself, or launch some shell script, or do anything it wants really, as root using sudo
3. There is no step three.
Interesting - that does achieve escalation - although I had to set a date more recent than 1970 otherwise it generates the "sudo timestamp too far in the future" error. That's definitely a vulnerability.
Just how many Mac owners will have ever run sudo in the first place? If it is a company machine then the sys admin is a different user from the nominal user who may have admin privileges but will have never run sudo so the exploit fails. We are then talking about a very small subset of Macs actually open to this exploit at any given time.
So fix it but it doesn't seem to be a really glaring problem.
Surely if they can run sudo once, they can just run:
Code:
sudo passwd
And then reset the root password. That way having root access anyway?
Only root or someone who knows the root password can change the root password, except if you have a boot image in which case you can boot from it and change the root password or on Linux boot under single user mode, but in either case you need physical access to the machine.
Sorry I added this using an old browser and cannot layout this properly.
Fix: add this to /etc/sudoers using the visudo command
"Defaults:ALL timestamp_timeout=0" (without the quotes)
This prevents the login-without-giving-password. It's safer anyway. I think Apple should make it the default anyway.
Note: of all Mac OS X users, how many use the command line (Terminal, probably negligible) and how many of those use sudo (probably the majority of that small group).
Just how many Mac owners will have ever run sudo in the first place? If it is a company machine then the sys admin is a different user from the nominal user who may have admin privileges but will have never run sudo so the exploit fails. We are then talking about a very small subset of Macs actually open to this exploit at any given time.
Most companies don't have a clue about setting up Macs and will just set them up with the default (one user account which is also the admin). However, I do agree about the low percentage of people who actually use sudo.
I mentioned this before. With all the problems they've had with iCloud, and now this, I think maybe they should consider doing more than pushing stock buybacks and maybe doing a little more hiring in key sectors. Even with this "bug is not really a bug and you need sudo access to exploit it."
These incidents do take the shine off the Apple platform.
If you could run sudo, why wouldn't you just use it to get access to the files directly? Why would you even bother going this route? Am I missing something clever here?
If you could run sudo, why wouldn't you just use it to get access to the files directly? Why would you even bother going this route? Am I missing something clever here?
Yes. Getting around the sudo password authentication mechanism by changing the system time.
1. System Preferences -> Security & Privacy -> Require password <interval> after sleep or screen saver begins.
2. System Preferences -> Sharing -> un-check Remote Login.
3. There is no step three.
Neither one of those things does anything at all to protect against malicious applications overstepping their boundaries, which is the issue I was bringing up.
In general, it's a good idea to actually read a post before you write a reply to it.
If you have sudo / root access already... Why are you messing with the system clock?
Because you *don't* have sudo/root access already. The vulnerability is about gaining sudo/root access without knowing the password, since Apple lets you change the system clock without sudo/root access, and this allows you to trick sudo into letting you in without being properly authorized.
It's not 'zero risk'. It's a real bug and should be addressed, even though the risk is quite low.
Yeah, and virtually every one of that 98% already has unlimited access to all their files, anyway. So what does the exploit get them?
Yes, it's a bug. It needs to be fixed. But compared to the alternatives, Mac OS X is still much, much, much safer. No one ever claimed perfection.
And yet a couple of weeks ago when there was the article about Google Chrome storing passwords in plain text which also required physical access to a logged in machine (much like this security flaw), the response around here was, "Holy Hell!!!! How can Google allow such a heinous flaw to exist!!!! Google sux!!!!"
I consider the action of the article's author irresponsible in publicizing this bug. It is not an easily exploitable bug, but the headline creates the impression there is a greater vulnerability. I wonder whether this behavior is covered under the DMCA act.
Seriously, Apple maintains comprehensive bug database, and they have to respond the entire database. Submitting bug reports includes one agreeing to follow Apple's policies. Apple considers bug reports proprietary information, i.e. trade secret. If you are a developer for Apple, Apple can cancel your developer account, if you disclose proprietary information.
2) As local privilege escalations go this one is extremely easy to exploit and made worse by the fact that most users will be running using an account which is 'allowed to administer the computer' therefore allowed to change the clock. This exploit doesn't work if you run as a 'Limited' user however this is not the norm unfortunately.
3) The DMCA is not meant to prevent disclosure of vulnerabilities in software. It is established industry best practice that vulnerabilities are disclosed to vendors first and then fully disclosed after a period of time, usually at least 45 days and maybe longer if vendors are actively working on a difficult fix and need more time. However allowing vendors to block disclosure means that exploitable bugs go unpatched and only the bad guys know what is going on.
4) Even if the DMCA was relevant Apple's bug database has nothing to do with this as the relevant information is available from the CVE database published by no less an authority than the US government itself.
2) As local privilege escalations go this one is extremely easy to exploit and made worse by the fact that most users will be running using an account which is 'allowed to administer the computer' therefore allowed to change the clock. This exploit doesn't work if you run as a 'Limited' user however this is not the norm unfortunately.
But if you always leave yourself logged in as admin, then this exploit doesn't gain anything. You have access to all the files on a default system running as admin, so why bother going through the process?
And yet a couple of weeks ago when there was the article about Google Chrome storing passwords in plain text which also required physical access to a logged in machine (much like this security flaw), the response around here was, "Holy Hell!!!! How can Google allow such a heinous flaw to exist!!!! Google sux!!!!"
Hypocritical much?
No. Because I didn't comment on that thread. Maybe you should learn the meaning of words before you use them.
Not to mention that that flaw doesn't have a workaround. This one has a trivial workaround (not staying logged in as admin).
2) As local privilege escalations go this one is extremely easy to exploit and made worse by the fact that most users will be running using an account which is 'allowed to administer the computer' therefore allowed to change the clock. This exploit doesn't work if you run as a 'Limited' user however this is not the norm unfortunately.
But if you always leave yourself logged in as admin, then this exploit doesn't gain anything. You have access to all the files on a default system running as admin, so why bother going through the process?
It does gain something - it escalates the user or application privileges to root, which then permits unauthenticated changes to the system files, installation of malware etc., and capture of Keychain passwords.
Comments
You can already create another admin user or edit the sudoers list and create a user with full root permission. You can even do neat things like create private keys and backdoors for later use, and hide them from even the root user which would allow you later access.
This vulnerability is pretty dumb. And limited in scope. And doesn't even provide short term advantages.
[CODE]sudo passwd[/CODE]
And then reset the root password. That way having root access anyway?
Yes, and companies are likely to have admins who can easily prevent this problem.
1. Set the clock so it requires a password to change it.
2. Set a different password for root.
3. Set up user accounts rather than giving users admin accounts (which should probably be the way a business would set it up, anyway).
Any business who cares will use #3 at the very least, so it wouldn't be a problem.
Quote:
Originally Posted by hfts
Apple is beginning to sour for me.
The keyboards on the iDevices are simply terrible. Auto correcting when none is needed, and now lag.
Not getting the Apple TV update that was announced a couple of days ago (Australia).
Surely with their pile of cash they can fix these problems.
iOS 7 looks far too android for me from what I have seen, I hope they change it.
And your peevish whinging is relevant to this topic...how?
My understanding is that this exploit works if the user is already logged in as Admin; thus the attacker doesn't need the password. And if Sudo was already run once before, it won't ask for a password(?) so again, no need for the attacker to know the password.
That said, if you can do all that, can't Sudo do more than change the clock?
Maybe Sudo should just always require an admin password to launch?
Quote:
Originally Posted by jragosta
If you have admin access, you have a password that you can use to SUDO, anyway. Very, very, very few people actually have multiple passwords and accounts on their machines. Every single person I know (with one exception) operates with a single password - and all their files are accessible at any time.
I've argued this point before: it is possible for a piece of malicious software to run as a given user without knowing their password!
If you can get a user to open a webpage which exploits a security hole in Safari, or get them to open a malicious email attachment, then you have system access as that user. Once you have that, then you can use this time setting exploit to become root and start modifying system files, install kernel modules, daemons which harvest keystrokes, whatever. All without ever knowing a password.
So yes, there's a big difference between being able to access a system as an admin user, and being able to access it as root. And it's possible to access a system as an admin user without knowing their password. So this time setting exploit is significant.
Quote:
Originally Posted by Pendergast
Does Sudo require an admin password to use?
My understanding is that this exploit works if the user is already logged in as Admin; thus the attacker doesn't need the password. And if Sudo was already run once before, it won't ask for a password(?) so again, no need for the attacker to know the password.
That said, if you can do all that, can't Sudo do more than change the clock?
Maybe Sudo should just always require an admin password to launch?
All of what you said is correct. The big deal here is that you don't actually need to use sudo (or authenticate at all if you're an admin user) to change the clock. And, by setting the clock to the epoch, you can then bypass password authentication for sudo if it's ever been run at any point in the past.
But yes, that would fix the problem (making sudo always require a password). It's mainly an inconvenience for sysadmins to have to keep typing their password all the time, but certainly this exploit outweighs convenience.
Quote:
Originally Posted by Durandal1707
Quote:
Originally Posted by muppetry
I don't think an application can gain root privilege if it was not launched as root, in which case this would not work.
An app isn't *supposed* to be able to gain root privilege if it's not launched as root, but the whole point of this vulnerability is that it bypasses that particular restriction. All a malicious app has to do is to run a few command lines:
1. Change the clock date using the systemsetup command-line tool
2. Relaunch itself, or launch some shell script, or do anything it wants really, as root using sudo
3. There is no step three.
Interesting - that does achieve escalation - although I had to set a date more recent than 1970 otherwise it generates the "sudo timestamp too far in the future" error. That's definitely a vulnerability.
So fix it but it doesn't seem to be a really glaring problem.
Quote:
Originally Posted by OverByThere
Surely if they can run sudo once, they can just run:
Code:
And then reset the root password. That way having root access anyway?
Only root or someone who knows the root password can change the root password, except if you have a boot image in which case you can boot from it and change the root password or on Linux boot under single user mode, but in either case you need physical access to the machine.
Fix: add this to /etc/sudoers using the visudo command
"Defaults:ALL timestamp_timeout=0" (without the quotes)
This prevents the login-without-giving-password. It's safer anyway. I think Apple should make it the default anyway.
Note: of all Mac OS X users, how many use the command line (Terminal, probably negligible) and how many of those use sudo (probably the majority of that small group).
Quote:
Originally Posted by Chick
Just how many Mac owners will have ever run sudo in the first place? If it is a company machine then the sys admin is a different user from the nominal user who may have admin privileges but will have never run sudo so the exploit fails. We are then talking about a very small subset of Macs actually open to this exploit at any given time.
Most companies don't have a clue about setting up Macs and will just set them up with the default (one user account which is also the admin). However, I do agree about the low percentage of people who actually use sudo.
These incidents do take the shine off the Apple platform.
If you could run sudo, why wouldn't you just use it to get access to the files directly? Why would you even bother going this route? Am I missing something clever here?
Quote:
Originally Posted by AppleInsider
A unaddressed bug ....
For some reason, when the article begins "A unaddressed . . ." it seems unsurprising that what follows is overblown and inconsequential.
Quote:
Originally Posted by patrickwalker
If you could run sudo, why wouldn't you just use it to get access to the files directly? Why would you even bother going this route? Am I missing something clever here?
Yes. Getting around the sudo password authentication mechanism by changing the system time.
In general, it's a good idea to actually read a post before you write a reply to it.
Because you *don't* have sudo/root access already. The vulnerability is about gaining sudo/root access without knowing the password, since Apple lets you change the system clock without sudo/root access, and this allows you to trick sudo into letting you in without being properly authorized.
Quote:
Originally Posted by jragosta
It's not 'zero risk'. It's a real bug and should be addressed, even though the risk is quite low.
Yeah, and virtually every one of that 98% already has unlimited access to all their files, anyway. So what does the exploit get them?
Yes, it's a bug. It needs to be fixed. But compared to the alternatives, Mac OS X is still much, much, much safer. No one ever claimed perfection.
And yet a couple of weeks ago when there was the article about Google Chrome storing passwords in plain text which also required physical access to a logged in machine (much like this security flaw), the response around here was, "Holy Hell!!!! How can Google allow such a heinous flaw to exist!!!! Google sux!!!!"
Hypocritical much?
Quote:
Originally Posted by cloudman
I consider the action of the article's author irresponsible in publicizing this bug. It is not an easily exploitable bug, but the headline creates the impression there is a greater vulnerability. I wonder whether this behavior is covered under the DMCA act.
Seriously, Apple maintains comprehensive bug database, and they have to respond the entire database. Submitting bug reports includes one agreeing to follow Apple's policies. Apple considers bug reports proprietary information, i.e. trade secret. If you are a developer for Apple, Apple can cancel your developer account, if you disclose proprietary information.
1) This is a security bug in a piece of open source software which was patched by everyone else in February and disclosed in March see http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1775
2) As local privilege escalations go this one is extremely easy to exploit and made worse by the fact that most users will be running using an account which is 'allowed to administer the computer' therefore allowed to change the clock. This exploit doesn't work if you run as a 'Limited' user however this is not the norm unfortunately.
3) The DMCA is not meant to prevent disclosure of vulnerabilities in software. It is established industry best practice that vulnerabilities are disclosed to vendors first and then fully disclosed after a period of time, usually at least 45 days and maybe longer if vendors are actively working on a difficult fix and need more time. However allowing vendors to block disclosure means that exploitable bugs go unpatched and only the bad guys know what is going on.
4) Even if the DMCA was relevant Apple's bug database has nothing to do with this as the relevant information is available from the CVE database published by no less an authority than the US government itself.
But if you always leave yourself logged in as admin, then this exploit doesn't gain anything. You have access to all the files on a default system running as admin, so why bother going through the process?
No. Because I didn't comment on that thread. Maybe you should learn the meaning of words before you use them.
Not to mention that that flaw doesn't have a workaround. This one has a trivial workaround (not staying logged in as admin).
It does gain something - it escalates the user or application privileges to root, which then permits unauthenticated changes to the system files, installation of malware etc., and capture of Keychain passwords.