"OS X Lion security flaw allows anyone to change your password"
... locally.
^ That word is quite important as it requires that you actually have local access to the machine i.e you can reboot holding command-s and get root access anyway, which btw is easier than reverse-engineering password hashes.
According to the original source, there are scenarios where there's no need for physical access to your computer to still gain root access. A nefarious java-applet via Safari was offered as an example.
According to the original source, there are scenarios where there's no need for physical access to your computer to still gain root access. A nefarious java-applet via Safari was offered as an example.
That might allow for a remote exploit but Apple doesn't include Java with Lion any more so you first have to install it manually. Unsigned applets are also sand-boxed so they have no access to the filesystem. Signed applets pop up a warning to ask if you trust the source and if you click ok, it executes outside the regular sandbox but still according to a security policy, which depends on Java version and platform. I highly doubt it allows you the ability to execute arbitrary system commands or grant read access to the user password file. If you got so far as to read the password file, you only get hash values that you have to reverse-engineer.
They should fix it to be more secure of course but it's far from a usable exploit beyond the typical MacDefender 'please can I run malicious code yes/no' exploits.
That might allow for a remote exploit but Apple doesn't include Java with Lion any more so you first have to install it manually. Unsigned applets are also sand-boxed so they have no access to the filesystem. Signed applets pop up a warning to ask if you trust the source and if you click ok, it executes outside the regular sandbox but still according to a security policy, which depends on Java version and platform. I highly doubt it allows you the ability to execute arbitrary system commands or grant read access to the user password file. If you got so far as to read the password file, you only get hash values that you have to reverse-engineer.
They should fix it to be more secure of course but it's far from a usable exploit beyond the typical MacDefender 'please can I run malicious code yes/no' exploits.
"OS X Lion security flaw allows anyone to change your password"
... locally.
OK but should it be possible for a simple user to change passwords, even with physical access to the machine? I say no, for such operations always an admin password should be required, at the very least.
OK but should it be possible for a simple user to change passwords, even with physical access to the machine? I say no, for such operations always an admin password should be required, at the very least.
I am curious to see what Apple will do about it.
Yes: Any user should be able to change their own password.
No: It should be impossible for anyone else to change a users password without the original users permission. This is usually done by requiring the old password when changing to a new password. And this should be the case even with physical access and the user being logged in. (An exception is for an admin to reset a users password as needed.)
Nor should a user be required to get an admins' permission to change their own password.
OK but should it be possible for a simple user to change passwords, even with physical access to the machine? I say no, for such operations always an admin password should be required, at the very least.
It certainly should be fixed to how it was before but it doesn't matter all that much because you can simply reboot, hold command-s and you are the root user (higher than admin) and you can do whatever you want. This has always been the case.
It's far more likely that a user will need to gain control over their machine than protect against a local user abusing accounts. If you don't trust someone on a shared machine, you wouldn't give them access at all. If you need to secure your data, you have to use encryption.
Comments
... locally.
^ That word is quite important as it requires that you actually have local access to the machine i.e you can reboot holding command-s and get root access anyway, which btw is easier than reverse-engineering password hashes.
http://www.defenceindepth.net/2011/0...passwords.html
According to the original source, there are scenarios where there's no need for physical access to your computer to still gain root access. A nefarious java-applet via Safari was offered as an example.
That might allow for a remote exploit but Apple doesn't include Java with Lion any more so you first have to install it manually. Unsigned applets are also sand-boxed so they have no access to the filesystem. Signed applets pop up a warning to ask if you trust the source and if you click ok, it executes outside the regular sandbox but still according to a security policy, which depends on Java version and platform. I highly doubt it allows you the ability to execute arbitrary system commands or grant read access to the user password file. If you got so far as to read the password file, you only get hash values that you have to reverse-engineer.
They should fix it to be more secure of course but it's far from a usable exploit beyond the typical MacDefender 'please can I run malicious code yes/no' exploits.
That might allow for a remote exploit but Apple doesn't include Java with Lion any more so you first have to install it manually. Unsigned applets are also sand-boxed so they have no access to the filesystem. Signed applets pop up a warning to ask if you trust the source and if you click ok, it executes outside the regular sandbox but still according to a security policy, which depends on Java version and platform. I highly doubt it allows you the ability to execute arbitrary system commands or grant read access to the user password file. If you got so far as to read the password file, you only get hash values that you have to reverse-engineer.
They should fix it to be more secure of course but it's far from a usable exploit beyond the typical MacDefender 'please can I run malicious code yes/no' exploits.
Thanks for the clarification Marvin.
"OS X Lion security flaw allows anyone to change your password"
... locally.
OK but should it be possible for a simple user to change passwords, even with physical access to the machine? I say no, for such operations always an admin password should be required, at the very least.
I am curious to see what Apple will do about it.
OK but should it be possible for a simple user to change passwords, even with physical access to the machine? I say no, for such operations always an admin password should be required, at the very least.
I am curious to see what Apple will do about it.
Yes: Any user should be able to change their own password.
No: It should be impossible for anyone else to change a users password without the original users permission. This is usually done by requiring the old password when changing to a new password. And this should be the case even with physical access and the user being logged in. (An exception is for an admin to reset a users password as needed.)
Nor should a user be required to get an admins' permission to change their own password.
OK but should it be possible for a simple user to change passwords, even with physical access to the machine? I say no, for such operations always an admin password should be required, at the very least.
It certainly should be fixed to how it was before but it doesn't matter all that much because you can simply reboot, hold command-s and you are the root user (higher than admin) and you can do whatever you want. This has always been the case.
It's far more likely that a user will need to gain control over their machine than protect against a local user abusing accounts. If you don't trust someone on a shared machine, you wouldn't give them access at all. If you need to secure your data, you have to use encryption.