[Thinkfinger-devel] [resubmit PATCH] Patch to pretend remote users

[W***@gmx.de]

Hello,

This is a second try.

Perhaps last time, i dont explain it correctly.

This patch pretends a remote user from using the pam_libthinkfinger
mechanism.

Scenario:

User logined with ssh to your machine with a normal user account.
(here we can pretend it by removing it from the SSH PAM queue)

Than the remote User call "su -"
And he asked to type password or swipe Finger.
(now, he can get root rights, if the local user swipe finger, without
knowing that this authentication is for another user)

This isnt pretenend by PAM in any version.


Hope this patch helps someone.
It's against SVN Revision 73.

In best regards,

Gabor Janak

[Timo Hoenig]

Hi Gabor,

Post by W***@gmx.de
This is a second try.
Perhaps last time, i dont explain it correctly.

Sorry, you did not miss anything. I just forgot about the patch -- I am
aware of the issue. Your patch looks basically fine, but I wanted to
talk to a colleague of our security team first, as he did something
similar in the past.

Post by W***@gmx.de
This patch pretends a remote user from using the pam_libthinkfinger
mechanism.
User logined with ssh to your machine with a normal user account.
(here we can pretend it by removing it from the SSH PAM queue)
Than the remote User call "su -"
And he asked to type password or swipe Finger.
(now, he can get root rights, if the local user swipe finger, without
knowing that this authentication is for another user)

Hm, no, I don't think that it gets that far.

Calling 'su -' within a ssh session will cause pam_thinkfinger to wait
for a swipe matching root's biometric identification record. Hence, the
finger being swiped by the local user has to be root's finger, not just
any arbitrary finger. If this is true, your scenario as described above
works.

It is a similar issue as when dealing with a multi-seat workstation.

The latest development version (which is not yet in SVN, check the
mailing list archive for the link to a preliminary tar ball) makes this
attack harder as it sends a carriage return (using uinput) after a
swipe. This will only be received by the active VT/X window which has
focus.

In your scenario the 'su -' of the ssh session would not receive the
carriage return and thus would not be authenticated. Still, if the
remote user knows when the swipe happened, (s)he could simply hit return
and the attack would still succeed.

Post by W***@gmx.de
Hope this patch helps someone.

It sure does, thanks a lot for bringing this up.

I'll get back once I have talked to the security guy.

Thanks,

Timo

[W***@gmx.de]

Ok,

by the way: i think sending a CR by uevent isn't a very good solution.

The old way by starting 2 threads, and killing the another is a little
bit better.

With this old method there is a change to get it working with
pam-conform login Managers. (like xdm snapshot).

I dont see the Problem with this old "logic".
Can you explain why you want to change this ?



Am Sat, 17 Feb 2007 12:43:19 +0100 schrieb Timo Hoenig

Post by Timo Hoenig
Hi Gabor,

Post by W***@gmx.de
This is a second try.
Perhaps last time, i dont explain it correctly.

Sorry, you did not miss anything. I just forgot about the patch -- I am
aware of the issue. Your patch looks basically fine, but I wanted to
talk to a colleague of our security team first, as he did something
similar in the past.

Post by W***@gmx.de
This patch pretends a remote user from using the pam_libthinkfinger
mechanism.
User logined with ssh to your machine with a normal user account.
(here we can pretend it by removing it from the SSH PAM queue)
Than the remote User call "su -"
And he asked to type password or swipe Finger.
(now, he can get root rights, if the local user swipe finger, without
knowing that this authentication is for another user)

Hm, no, I don't think that it gets that far.
Calling 'su -' within a ssh session will cause pam_thinkfinger to wait
for a swipe matching root's biometric identification record. Hence, the
finger being swiped by the local user has to be root's finger, not just
any arbitrary finger. If this is true, your scenario as described above
works.
It is a similar issue as when dealing with a multi-seat workstation.
The latest development version (which is not yet in SVN, check the
mailing list archive for the link to a preliminary tar ball) makes this
attack harder as it sends a carriage return (using uinput) after a
swipe. This will only be received by the active VT/X window which has
focus.
In your scenario the 'su -' of the ssh session would not receive the
carriage return and thus would not be authenticated. Still, if the
remote user knows when the swipe happened, (s)he could simply hit return
and the attack would still succeed.

Post by W***@gmx.de
Hope this patch helps someone.

It sure does, thanks a lot for bringing this up.
I'll get back once I have talked to the security guy.
Thanks,
Timo

[Timo Hoenig]

Post by W***@gmx.de
by the way: i think sending a CR by uevent isn't a very good solution.

I disagree.

Post by W***@gmx.de
The old way by starting 2 threads, and killing the another is a little
bit better.

Killing the other thread is bad, as it is leaving the PAM module and
then is running within the conversation function of the application.

Using uinput is basically the same as when using regular authentication:
The user enters its credentials and then hits return.

Post by W***@gmx.de
With this old method there is a change to get it working with
pam-conform login Managers. (like xdm snapshot).

Are you saying that the uinput broke xdm and it was working before? If
so, did you investigate why that is?

Post by W***@gmx.de
I dont see the Problem with this old "logic".
Can you explain why you want to change this ?

In my opinion it is not acceptable to kill a thread which runs within
the context of the application which uses PAM.

Timo

[Gabor Janak]

Bad News, i have a error in the Patch,
a local suer can have an empty rhost entry.
Attached the corrected version.


Good news:
With xdm-1.1.4 the xdm Team has build xdm 100% pam conversation
compatible. it works without patching with pam_fingerprint.

Post by W***@gmx.de
Hello,
This is a second try.
Perhaps last time, i dont explain it correctly.
This patch pretends a remote user from using the pam_libthinkfinger
mechanism.
User logined with ssh to your machine with a normal user account.
(here we can pretend it by removing it from the SSH PAM queue)
Than the remote User call "su -"
And he asked to type password or swipe Finger.
(now, he can get root rights, if the local user swipe finger, without
knowing that this authentication is for another user)
This isnt pretenend by PAM in any version.
Hope this patch helps someone.
It's against SVN Revision 73.
In best regards,
Gabor Janak

[Ludwig Nussel]

Post by W***@gmx.de
User logined with ssh to your machine with a normal user account.
(here we can pretend it by removing it from the SSH PAM queue)
Than the remote User call "su -"
And he asked to type password or swipe Finger.
(now, he can get root rights, if the local user swipe finger, without
knowing that this authentication is for another user)

Unfortunately your patch doesn't fix the problem. Checking for a
host name set in utmp is not reliable. You can easily fool such a
check with e.g. screen.

Something like this might work:
- when called from gdm or login pam_thinkfinger touches a defined
file and changes ownership to the to be logged in user. It should
do that even if the user doesn't authenticate via fingerprint.
- when called from su or sudo pam_thinkfinger checks whether the
calling user is the one owning said file. If users don't match or
the file doesn't exist then it also won't use the fingerprint
reader.
- upon logout pam_tinkfinger removes the file

cu
Ludwig

[W***@gmx.de]

Hello,

I checked with screen, the wmtp host is set correctly.
Only root can fool this record.

Touching a file: Do you realy mean this is a solution ?
I don't think so.

soory, if you use a mis patched Version of screen, but why should
screen remove
the host entry ?
The User hasn't write access to the [wu]tmp file.

and how would you decide that pam_thinkfinger is called from login,
instead from su ?

And second, if a user loged in, everybody else can use su.

Please give me an example how to fool all tests without root access.

Am Mon, 26 Feb 2007 16:09:39 +0100 schrieb Ludwig Nussel

Post by Ludwig Nussel

Post by W***@gmx.de
User logined with ssh to your machine with a normal user account.
(here we can pretend it by removing it from the SSH PAM queue)
Than the remote User call "su -"
And he asked to type password or swipe Finger.
(now, he can get root rights, if the local user swipe finger, without
knowing that this authentication is for another user)

Unfortunately your patch doesn't fix the problem. Checking for a
host name set in utmp is not reliable. You can easily fool such a
check with e.g. screen.
- when called from gdm or login pam_thinkfinger touches a defined
file and changes ownership to the to be logged in user. It should
do that even if the user doesn't authenticate via fingerprint.
- when called from su or sudo pam_thinkfinger checks whether the
calling user is the one owning said file. If users don't match or
the file doesn't exist then it also won't use the fingerprint
reader.
- upon logout pam_tinkfinger removes the file
cu
Ludwig
--
(o_ Ludwig Nussel
//\ SUSE Labs
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Thinkfinger-devel mailing list
https://lists.sourceforge.net/lists/listinfo/thinkfinger-devel

[Ludwig Nussel]

Post by W***@gmx.de
I checked with screen, the wmtp host is set correctly.
Only root can fool this record.
Touching a file: Do you realy mean this is a solution ?
I don't think so.
soory, if you use a mis patched Version of screen, but why should
screen remove
the host entry ?

Start screen when logged in locally, detach it and log out. Then log
in via ssh and re-attach screen. screen will restore the previous
(local) entries.

Post by W***@gmx.de
The User hasn't write access to the [wu]tmp file.

Well, via utempter he has. It's probably possible to manually call
utempter and forge the host string. I'm not sure though. Doesn't
matter anyways as screen already proves that utmp is unreliable.

Post by W***@gmx.de
and how would you decide that pam_thinkfinger is called from login,
instead from su ?

You could pass a parameter that tells pam_thinkfinger that a
particular call is the initial login. pam_thinkfinger could probably
also just check whether it's running setuid root (getuid() !=
geteuid()) as that is usually not the case with login or display
managers AFAIK.

Post by W***@gmx.de
And second, if a user loged in, everybody else can use su.

That's why you need to check ownership of the file in order to only allow the
'primary' user to use the fingerprint reader.

cu
Ludwig