I'm new in this group, so I do not know neither if problem mentioned by Tadek was discussed or not, but let me put some explanation: "logon", "workstation locked" and "unlock workstation" (and any other response to Ctrl-Alt-Del) dialogs are displayed by part of system called GINA (Graphical Identification and Authentication DLL). This DLL can be replaced in the system, i.e. by smart card reader, retina scan etc. Original file is named MSGINA.DLL . GINA is loaded by WINLOGON process during system initialization and run in it's context (which makes it super-privileged) and has access to both: secured desktop and user desktop (and any other you can imagine, including services - I believe so). OK, this was just introduction. Now: when user logs on, all information from logon dialog is passed and handled by GINA first, which uses so-called network providers to authenticate user. MSGINA.DLL (original implementation of GINA) saves all this information (username, password etc.) in own structure, and uses it later to validate "unlock workstation" request. That's why you must supply the same password for both: logon and (latter on) unlock workstation, even if (in the meantime) password has been changed using User Manager. It's not the situation if you change the password using Crl-Alt-Del, because this request is handled by GINA - which effectively updates it's internal structure with your new password. I guess that this internal structure is somehow connected to password caching, but it's not the point. It's arguable if described schema is a security hole or not. One thing to remember is that "unlock workstation" dialog originally implemented by Microsoft does not make REAL authentication. Try this: 1) logon on using password A 2) change you password to B using User Manager 3) lock and unlock workstation - you will need password A to unlock 4) change password to C using Ctrl-Alt-Del. You will need password B as "old password" 5) lock and unlock workstation - you will need password C to unlock What in my opinion security leak is: 1) "workstation locked" dialog and following "unlock workstation" shows up current user name. If it is administrator (who locked server) and screen can be seen by ordinary user, he/she will know administer account name. As we know, this particular account will NOT be locked after when someone is trying to guess the password. 2) super-privileged GINA that can be any DLL you put in registry. User (or hacker) can make own GINA and try to register it (a) writing to registry or (b) replacing file MSGINA.DDL. By default ordinary user cannot do that, but ... With regards Bronek Kozicki ---------- From: Tadek Knapik[SMTP:tadekat_private] Sent: wtorek, 2 lutego 1999 11:00 To: BUGTRAQat_private Subject: NT4 Locking (Was: ole objects in a "secured" environment?) David Reed wrote: > background: > > since all of the major security flaws in windows nt 4.0 have been discovered > (who am i kidding? ;-), i'd like to point out a minor one... by way of a > question: "should a secured workstation's 'unlock workstation' dialog be > permitted to interact with the desktop?" Much more interesting thing to me is the way it handles passwords. I log on, change my own password with User Manager, and then give it ctrl-alt-del combination, choosing Lock Workstation. Surprise, it doesn't accept the actual pasword, it needs the old one, used while logging on. Valid with SP3 as well as with SP4. Once upon a time a Microsoft guy (suprised as I was at first:) tried to explain this is the way it has to be as the 'Lock Workstation' cannot interact with the desktop ;) Sorry, if this was already mentioned/discussed here and I'm just taking your time ;) Sincerely, Tadek Knapik -- ---------------------------------------------------------------------- | Tadek Knapik (TxF on #amigapl) // "Be yourself, no matter | | tadekat_private \X/ what they say" - Sting | ---------------------------------------------------------------------- | I use an account provided by my employer; however, my employer in | | no way endorses any action or statement of mine, unless stated so. | ----------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:32:23 PDT