Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A vulnerability with the screensaver password lock System
No one wants other people messing around with their computer when they're away from their desks, but what can you do? It's not practical to log out every time you want to go for a cup of coffee, so many people put a password lock on their screensaver instead.

This is much more convenient, but it has a serious Achilles heel: if you are in an environment where many people have logins on your computer, such as an office with centralized login (NIS, ActiveDirectory/Kerberos, LDAP, OpenDirectory, NetInfo, etc) where everyone has an account on every computer, then anyone can use their own login to disable your locked session. The only record of this will be an entry in /var/log/secure.log, which is only useful after the fact -- provided that the person who logged in didn't know to cover their tracks.

UPDATE: Only Admin users can unlock the screensaver; normal users cannot.

For a lot of people, this probably defeats the purpose of locking the screen to begin with. Until and unless Apple provides a way to change this behavior, it may be wise to avoid the screen saver lock and fully log out of the system whenever you will be away from your computer for a long time (lunch break, overnight, etc).

[robg adds: There was an earlier security issue with the screensaver password as well, which has since been fixed. However, out of that problem came this hint and comments, which offer the best solution, I think, to this problem. Logging out is a pain, especially when you have 20 or so apps running with multiple open documents. The referenced hint explains how to use Fast User Switching to bring up the main OS X login screen, which won't actually log you out. It also won't be susceptible to this hack -- the other user could login, but it would be to their own account, not yours. Of course, there's no screensaver at the login prompt, so you'll probably then want to hit the Sleep button to put your machine to sleep (or at least dim your screen).

If you hate the amount of menubar space used by the FUS menu item, use something like Butler, FUSKey, FUS++, etc. to enable fast user switching without having the menu active.]
    •    
  • Currently 2.00 / 5
  You rated: 4 / 5 (7 votes cast)
 
[23,981 views]  

A vulnerability with the screensaver password lock | 36 comments | Create New Account
Click here to return to the 'A vulnerability with the screensaver password lock' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A vulnerability with the screensaver password lock
Authored by: kianga on Jun 04, '04 11:15:54AM

On my OS X, I can only unlock the screen saver if I enter the login/password of an administrator. It doesn't have to be the currently logged in user, but it has to be an administrator.

Although this is new to me, I don't see it as a security problem. If someone has admin privileges, they should be able to do anything on a computer, possibly even unlock other user's sessions.



[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: babbage on Jun 04, '04 01:13:47PM

Yeah, more testing after submitting the hint confirmed what you say: while any administrator can disable the screen saver, users with normal access levels cannot. I stand amended.

So, the real lesson here may be to be very careful about granting admin access to users, and avoid just having a blanket rule that, for example, every sysadmin in a big company has full access to all Macs.

---
--
DO NOT LEAVE IT IS NOT REAL



[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: GaelicWizard on Jun 04, '04 04:12:52PM

You should never give out admin rights to anybody, except the administrator. This is Multi-user environments 101 (and UNIX 101, and Linux 101, but seems to be missing from Mac OS X 101...)

Most of you out there are quite happy to make admin user after admin user, but this is just BEGGING for trouble. Not from the human being behind that user, necessarily, but because all kinds of unexpected issue arise, like a virus or worm or applescript that a website might provide has admin privs!!! Or users being able to screw something up accidentally, or a list of other reasons that are listed so many times across the web (and even on this site) that I won't keep going.

Nobody should be an administrator except the administrator, and it should be a separate account! On my machine and all the machines I set up for friends or administer at work, whether XP or X or *nix have one administrator account, and ALL other accounts are limited. (on *nix this is a no-brainer since there is root and non-root already, so there is no extra work needed.)

If there is need for more than one administrator, then ask yourself why these two people need *separate* admin accounts, since they both already have non-admin user accounts for all their non-admin activity.

---
Pell



[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: Aristotle on Jun 06, '04 05:30:17PM

Admin users on OSX are not quite the same as XP Administrator users which is analogous too the wheel group. I agree that you should only give out Admin access to trusted users but if you are trusting them with with sensitive data in a corporate environment already, giving them admin access on their own machine is no big deal. Admin on OSX is more like Power user group under XP except you can escalate to root through sudo.



[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: below on Jun 04, '04 05:50:13PM

I agree entirely. And I know what I am talking about from an enterprise environment: An admin should be able to unlock a screensaver.

Alex



[ Reply to This | # ]
use Keychain Access?
Authored by: schaps on Jun 04, '04 11:22:20AM

I read through all this twice, but I am not sure if you are talking about what I use for security, which is Keychain Access-- when it is running, there is a "Show Status in Menu Bar" item in the View menu. When enabled, you have a "Lock Screen" option in the menu bar menu.

Is that also susceptible? My quick test showed it not to be.

T



[ Reply to This | # ]
use Keychain Access?
Authored by: robmorton on Jun 04, '04 03:18:47PM

Same issue. That really seems to just activate the screen saver. Any admin name and password will bypass this. The biggest problem is there is no lock keychain with screen saver.



[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: Harry Tuttle on Jun 04, '04 11:22:44AM

I just tried this out, and discovered that IMHO this isn't actually a vulnerability at all.

Besides my mail user I have two others on my Mac. If I am logged in and have the screensaver password protection enabled then only my user can unlock the Mac from the screensaver or sleep. When I tried to use another user to unlock my Mac I was informed that only Administrators can unlock a screensaver.

If you ask me that's how it should be, but I do understand your concern.

The solution? Make sure that the number of administrators on your system or network is at an absolute minimum.



[ Reply to This | # ]
Another solution
Authored by: ryangreenberg on Jun 04, '04 11:23:04AM

I noticed Ciao!, a new program which was mentioned recently on MacNN. It's a screensaver module that can either logout or do a fast-user switch to the login window after a predefined idle period. I think it's an excellent way to implement reasonable time-out security like a screensaver password would.

Ciao! is free and you can find it at http://lorenb.com/software/ciao/



[ Reply to This | # ]
Another solution
Authored by: rfitz on Jun 04, '04 02:12:16PM
LogOutScreenSaver is another soluation. It has more features then Ciao and is only $9.99.
Goto FitzwaterInc for more information.

[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: pvera on Jun 04, '04 11:56:03AM

All you have to do is use fast user switching to go to the login window. The only problem with doing this is that iChat will disconnect. Once in the login window then nobody can log into your session, not even an administrator.

---
Pedro
-
http://pedrovera.com



[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: babbage on Jun 04, '04 01:09:05PM

You're right that this gets around the problem I raised, but then this brings up other issues. With fast user switching, your session is still active in memory, and there are ways of snooping around in someone else's active login session.

Both OSX and WinXP put in disclaimers telling you to only enable fast user switching in environments where users trust each other, i.e. it's okay to use home with your spouse and kids (or siblings & parents) but probably not okay for a corporate or university desktop machine.

The company I work for explicitly discourages anyone from using Fast User Switching on their desktop for exactly these reasons, and while I don't mind having it turned on at home where it's just me, my wife, and the cat, I agree that it's a good policy to forbid it at work.

---
--
DO NOT LEAVE IT IS NOT REAL



[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: yellow on Jun 04, '04 01:19:42PM

I cannot get this 'vulnerability' to manifest itself no matter how many different ways I try.. what's the deal?



[ Reply to This | # ]
But it's supposed to be multiuser!
Authored by: derrickbass on Jun 05, '04 03:21:30PM
The company I work for explicitly discourages anyone from using Fast User Switching on their desktop for exactly these reasons, and while I don't mind having it turned on at home where it's just me, my wife, and the cat, I agree that it's a good policy to forbid it at work.
That's really amusing to me, considering the origins of UNIX (of which OS X is a descendent). I mean, the whole idea was to try and provide a secure environment where multiple people could work on the same machine without interfering with each other. In fact, it wasn't until about 10 years ago that were a substantial number of companies that could afford to implement such a policy as you describe for their UNIX machines! Until then, there was a mainframe or workstation serving many (sometimes hundreds or even thousands) of users who had dumb terminals. Cheap UNIX boxes are pretty new inventions.

Anyway, you are correct that there are a few covert channels through which to snoop on other users. In addition, local privilege escalation security vulnerabilities sometimes pop up. But really, as long as you only let truly trusted (and careful) users have administrator privileges, I think the sorts of additional threats presented by having multiple users on the same machine are pretty minimal. (You should make sure the default UMASK is set so that new folders & files are not readable by others.)

[ Reply to This | # ]

But it's supposed to be multiuser!
Authored by: osxpounder on Jun 09, '04 02:33:12PM

You wrote, " (You should make sure the default UMASK is set so that new folders & files are not readable by others.)". I'm too much a *nix newbie to know how to do that, or what side effects that might produce. Would anyone please explain how to do it, and offer any warnings or advice about it?

---
--
osxpounder



[ Reply to This | # ]
problem with FUS
Authored by: tetsuotheironman on Jun 04, '04 12:13:30PM

Only problem with the soluion of using fast user switching is that in the context of LDAP or directory based logins can't have more than one network user logged in at a time.



[ Reply to This | # ]
problem with FUS
Authored by: nassy on Jun 05, '04 12:17:01PM

if your network home directory sharepoints are shared via nfs instead of afp you can use fast user switching with LDAP based logins.



[ Reply to This | # ]
Incorrect: multiple AD logins are allowed with FUS
Authored by: Jaharmi on Jun 06, '04 07:56:19AM

I haven't tried this with LDAP logins, but if your directory service is Active Directory, you can have multiple directory logins simultaneously. I haven't stressed the limits, but with FUS, I have personally had about 10 AD users logged into my Mac at the same time.

This is something that I don't believe Windows XP can do with Active Directory, but you can do it on Panther!

You have to make sure, then, that you only grant admin access to those AD groups who really need access to that computer. Why? Because if you grant admin access to a group in AD, they can use this feature -- which I approve of -- to get into a system. This is a godsend in public/shared environments; we need to have the ability to get into a screensaver-locked system on a pretty regular basis.

To do this with LDAP-based logins, you might have to do a lot of scripting at the loginhook. In my experience, the LDAPv3 plugin is a lot less flexible than the AD plugin. The AD plug creates new local home directories (by default) at first login time for each user, based on their short AD username. It also will created a local NetInfo entry for each user if you turn on cached accounts (and that entry stays synchronized to AD, so it's very different than a normal NI local account).

Jaharmi



[ Reply to This | # ]
NOT a vulnerability with the screensaver password lock
Authored by: yellow on Jun 04, '04 12:45:22PM

Yeah, there's a blurb on MacFixIt.com about this too, and it's completely untrue. Only the user who is logged in currently (who 'owns' the screensaver) and admin users can bypass the screen saver. This hint is FUD.



[ Reply to This | # ]
NOT a vulnerability with the screensaver password lock
Authored by: robg on Jun 04, '04 02:43:21PM

Is this true for *networked* user IDs in addition to local? I know it"s not an exposure for local IDs, but this hint is specific to remote IDs.

-rob.



[ Reply to This | # ]
NOT a vulnerability with the screensaver password lock
Authored by: chabig on Jun 04, '04 07:27:00PM

What! You're saying the logged in user, who owns the screensaver can log in with his own password? Why that would mean anyone who knows my password could log in. Eureka! I've found another vulnerability!



[ Reply to This | # ]
NOT a vulnerability with the screensaver password lock
Authored by: yellow on Jun 10, '04 02:27:56PM

<cackle>



[ Reply to This | # ]
Centralized logins
Authored by: yellow on Jun 04, '04 03:06:38PM

I experimented with centralized NIS authentication and could not get any 'standard' user to bypass another 'standard' user's password protected screen saver. Sadly, I have not yet been able to experiment with NetInfo, which is probably the most common centralized authentications of all (centrally authenticated) Macs.



[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: gigsvoo on Jun 04, '04 10:29:59PM

I am using an administrator level account, I locked my OS X session using screensaver password, then went to bath. Later my wife came in, she tried to unlock the screensaver, when she key in her login name and password (non-administrative), OS X does not display my desktop but swithes to her own desktop.

When I finished and come back, I still can switch back to my screensaver desktop and unlock.

I do not see any problems here.



[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: catodysseus on Jun 05, '04 01:07:20AM

I use the Ciao screeensaver!

Dims the screen after a preset time and then again log out to FUS after yet another preset time.

Very nice and clean.

Energy saver can be set to put display and computer to sleep.

http://www.macupdate.com/info.php/id/15090



[ Reply to This | # ]
This is standard behaviour, not a vulnerability
Authored by: cram on Jun 05, '04 05:23:29AM

The only point is that it's not advertised. On Windows NT, 2000, XP, the behaviour is exactly the same, but the password box says : "Only the current user or an administrator can unlock this computer". So everybody knows...



[ Reply to This | # ]
Not a security issue, but I found a bug
Authored by: IndexCOR Steffan on Jun 05, '04 07:11:51AM

From what I see, it doesn't look like a security issue, but I did find a weird bug. Does anyone else seem to get it?

To reproduce the bug:

• Log in as any Admin or non-Admin user - open up 3-4 apps, make sure the screensaver is password-protected, then switch it on.
• After switching it on, move the mouse to bring up the Security Dialogue. Rather than entering your username + password to unlock the screensaver, click "Switch User Account".
• You should be on the login screen. Log in as another user (must be an Admin).
• Open activity monitor on this account and select "Show Other User Processes".
• Locate a process named "ScreenSaverEngin" for the username of the account that has the screensaver active. You may have to wait a few minutes for it to appear.
• When it appears, click the "Quit" button and do a force quit. Enter your administrator username and password.
• If the process does not go away, keep force quitting it (it took me 3 attempts) until the process disappears.
• Use the fast user switching menu to switch to the account with the screensaver active.
• You should get a black box in the middle of the screen. On the keyboard, press "Command + Alt + Esc", then press return. Repeat this action for the same number of applications you opened at the beginning, which should be 3-4 (what you are doing is force quitting the applications of that user).
• Put the computer to sleep.
• Wake the computer from sleep.
• You will now see the Security Dialogue for the screensaver. Enter your username and password to log back in. As you can see, all applications have been force quit.



[ Reply to This | # ]
Not a security issue, but I found a bug
Authored by: rhowell on Jun 05, '04 01:44:19PM

Wouldn't it be faster enter your admin username and password in the other user's screensaver login box, and then quit all of his/her applications? I don't see the difference.



[ Reply to This | # ]
Not a security issue, but I found a bug
Authored by: IndexCOR Steffan on Jun 06, '04 07:49:42AM

oh! I didn't know that was possible. I guess I went the long way round.



[ Reply to This | # ]
Not a security issue, but I found a bug
Authored by: babbage on Jun 06, '04 08:19:09PM
There's a far, far easier way to do this.
  1. Pick a neighbor with a currently locked screen saver on a computer on which you have admin access
  2. ssh into that person's computer.
  3. Execute this command:
    sudo kill -9 \
    `ps ax \
    | grep -i 'scree[n]saver' \
    | awk '{print $1}' \
    | fmt`
    (You could also use killall -9, but I forget what the screensaver process is called and this variant should be more flexible.)
  4. Walk over to your neighbor's computer; the screensaver & the screensaver password should be gone now.

Granted, this is more complex in that it requires having a second computer to log into the target machine (though it doesn't have to be a Mac ) and it depends on the target machine having ssh access (though that's probably not an unreasonable assumption). But otherwise, this seems like a more straightforward variant of the same attack.

Note also that this attack probably works on Linux & other *nix systems as well -- anywhere multiuser system where the locked screensaver is likely to show up as an identifiable running process and admin level users can manipulate those currently running processes.

It's debatable whether or not it counts as a vulnerability though so much as an example of one of the innumerable unpleasant things that can be done with full administrative access to someone's computer, and an object lesson in why it's a good idea to give out admin access carefully.

---
--
DO NOT LEAVE IT IS NOT REAL

[ Reply to This | # ]

A vulnerability with the screensaver password lock
Authored by: risc_abacus on Jun 05, '04 07:45:06AM

I suppose I should jump on the bandwagon as to why this really isn't a vulnerability... I don't think Apple ever advertised or even sanctions using the screen saver as a secure method of locking your screen from peeking eyes. The only correct method of doing this... is to enable Fast User Switching and return to the Login Window. This method gives you the effect of keeping unwanted eyes off your work while keeping your apps open.



[ Reply to This | # ]
Not a bug, a feature for multi-user environments
Authored by: Jaharmi on Jun 06, '04 09:36:26AM

This behavior has existed since Mac OS X could first lock its screen with the screen saver.

When I first encountered, I thought it was a problem. On a second's reflection, I realized it was a boon for multi-user environments like mine. I sometimes have student employees leave the office while they are still logged in, and when the screen saver kicks in, we still need a way to access that computer. Using any admin account to get past the screen saver is a desirable default.

I can understand if you'd like to turn that off, but the existing setup is a good default in my opinion.

This also mirrors the old AppleShare (and AppleShare IP) practice. A server admin could log into any user's account using the admin's password, to simulate a login by that user. It was a good way to test access and confirm problems. It was a little odd, but all told, a helpful feature.

Jaharmi



[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: tjfarrell on Jun 06, '04 06:43:38PM

This is a flaw - in that the design allows an administrator more access then is needed for the required job. It is sensible that an administrator can override a password lock - the logged in user may have gone on leave and forgotten to logout or any number of things - and others need access to the computer.

But - the implementation allows the administrator more access then what is required. They get to see every thing the user was doing. I discovered this problem myself only last week and was rather shocked.

If the screensaver lock detects a administrator who is not the current user - it should offer an option to log out the current user (forceable quitting all their running applications without allowing the administrator to see the details).

You must always remember that the administrator of a multiple user machine may not be the primary user of the machine. The primary user may not have the relevant skills and may prefer not to have administrator privileges. Additionally, many company policies may deny them it anyway - reserving administrator privileges to the IT support group.

But - the normal user should still have the right to privacy of their information. They may be a far more important person then the person who has administrator access.

(Yes an the administrator can always look at all the user's files - but the user can use other techniques to get privacy at that level - fileVault for example.)

---
--
T. Farrell



[ Reply to This | # ]
Dude, where's my vulnerability?
Authored by: yellow on Jun 10, '04 02:37:35PM

You wrote:
"But - the normal user should still have the right to privacy of their information. They may be a far more important person then the person who has administrator access."

In most multi-user environments, especially those at a company, the end user has NO privacy of information. The computer, and therefore all material on the computer, is owned by the company. If you need to hide what you are doing/what you have on your work computer, then you shouldn't be doing it at work.



[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: mag3966 on Sep 10, '04 12:22:55AM

I believe that there is a vulnerability, but I am not quite sure it is exactly along the same lines as being represented. I am running the latest version of OSX on a G4 desktop. If I go to the login screen while fast user switching, I can type in a password for my account which is similar to my actual password, but changed by a few letters or numbers, and I am able to access my account. For example, if my actual password was "longest345" and I type "longest335", the system will let me in. Has anyone else experienced this problem? Thanks.

mag



[ Reply to This | # ]
A vulnerability with the screensaver password lock
Authored by: digpen on Sep 10, '04 10:37:38AM

This Article has to deal with the Effective Password Length.

http://docs.info.apple.com/article.html?artnum=106765



[ Reply to This | # ]