On Wed, 25 Oct 2006, Michael Bender wrote:
Jesse I Pollard - CONTRACTOR wrote:
Michael Bender wrote:
Sure, but the user/administrator need to fix whatever configuration
is allowing something like ssh to grab :0 - I don't think that this
is a common use case.
You can't prevent it. If port 6000 is not being used, then any user
application may allocate it.
On Solaris at least, you can mark any port as a privileged port
(both UDP and TCP). Not sure about Linux.
I guess that the issue with 6000 really depends on if the console
X server (that would be the normal X server that uses 6000) starts
up before someone can log in and grab 6000 (by any means). I'm not
sure if there is some code somewhere that sets 6000 as a privileged
port or not.
Anyway, what does this have to do with pcscd?
Nothing. It has to do with telling pcsd to grant access to the smartcard
reader by using the disply number as part of the key.
Since (in my opinion) the key is vulnerable to spoofing, the decision
to grant access is also vulnerable.
This could give the process doing the spoofing remote access to a
smartcard without the users authorization.
Such connections can then be used to generate derived certificates for
unauthorized use elsewhere.
There is also the issue of when the X server strictly uses the named
socket in /tmp/.X11-unix/X0 and doesn't use socket 6000.
How does the issue of which socket the X server uses affect this
discussion concerning pcscd?
It defines the display number used as part of the access key.
It determines what the X display environment value is. If port 6000
isn't being used, then it becomes :0. If it is being used, then :1
is used.
This is an X server thing. I still don't see what this has to do
with pcscd.
Again, only in that the display number is used as part of the checks
to control access to the smartcard.
XDM has some minimal configuration that assignes the X display and
X server. If port 6000 is used, then it will not start an X server.
Well sort of - the X server starts, but cannot open it's designated
socket, so it then terminates, XDM then reports a falure to syslog.
OK. What does XDM have to do with pcscd?
You are assuming the user generating the :0 display would be given that
privilege in the first place. He may be attacking the system via the
smartcard reader.
How is that possible?
There is a race condition between XDM and the X server startup. During
initial login, the X server MUST be local to allow the user to enter
PIN/other security related information. Then XDM aborts the display
and starts a new X server with the credentials of the authorized user.
XDM does not control port 6000, which defines the X display number (port
6000 is used for display 0:0, 6001 for display 1:0...). This window
is only open a short time (depends on the overall system speed) somewhere
around 1 second or less. If, during this window, an external attack
is carried out via the users base credentials, then the X display being
assumed for access checks will NOT be those of a local X server, but
a proxy. I have written such a proxy myself (which is why I'm familar
with the mechanics). It only takes a about 1000 lines of code to make
a proxy.
This is no inherently a problem - It only becomes a problem when you
assume the X display really is on the console.
OK, but what does this have to do with pcscd?
Again, only in that the display number is used as part of the checks
to control access to the smartcard. I was told that the validation
checks to ensure that the display specified is in control of the same
credentials as the X display. This is made under the assumption that
both the smartcard reader and display are local. This is the assumption
I am challenging by trying to present how an attack could be accomplished
by having a "local" display that is a spoofed/proxy X server.
Can it be blocked? Sure - but it requires the pcscd dameon/card
reader session to be reset, forcing the user to input his PIN twice for a
login. The first time to authenticate the local user (via the PAM module),
a second time to gain usable access during the login. This is an awkward
procedure, and I am reasonably sure is not being done. Is it still
"safe"? I'm not sure.
Even doing this, there may be other potential vulerabilities (not sure,
this is speculative, and I have no immediate evidence) there MAY be a way
to insert a man-in-the-middle attack by coercing the application to open a
different socket (to the attacker) which then forwards the connection to
the local pcscd server. This would grant full access to the smartcard
reader (and PIN exposure) to the attacker. I do think this vulnerability
to be most difficult to implement... In the past, I have been able to
capture PIN entry while I was debugging/analyzing local implementation
problems.
There are still a LOT of things I don't yet know about how everything
works. And the documentation available seems to assume some "things"
(and no, I can't quite put my finger on the "things" - it is an intuitive
feeling vagueness about it that is being glossed over...)
I still have heartburn over any remote access to a smartcard anyway. I
personally think it grants too many ways for trojan applications to gain
more credentials than should be available.
mike
--
[EMAIL PROTECTED] Sun Ray Product Engineering
I don't speak for my employer. My opinions are not necessarily those of
Sun Microsystems, Inc. or any of its wholly-owned subsidiaries.
_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [EMAIL PROTECTED]
Any opinions expressed are solely my own.
_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
