PAM timestamp internals bypass authentication

2014.03.26
Credit: Sebastian
Risk: Low
Local: Yes
Remote: No
CWE: CWE-22


Ogólna skala CVSS: 5.8/10
Znaczenie: 4.9/10
Łatwość wykorzystania: 8.6/10
Wymagany dostęp: Zdalny
Złożoność ataku: Średnia
Autoryzacja: Nie wymagana
Wpływ na poufność: Częściowy
Wpływ na integralność: Częściowy
Wpływ na dostępność: Brak

Hi When playing with some PAM modules for my own projects, I came across some implications of pam_timestamp (which is part of upstream linux-pam) that should probably be addressed. Most importantly, there seems to be a path traversal issue: static int format_timestamp_name(char *path, size_t len, const char *timestamp_dir, const char *tty, const char *ruser, const char *user) { if (strcmp(ruser, user) == 0) { return snprintf(path, len, "%s/%s/%s", timestamp_dir, ruser, tty); } else { return snprintf(path, len, "%s/%s/%s:%s", timestamp_dir, ruser, tty, user); } } If attacker can control PAM_RUSER or PAM_TTY item and pam_timestamp is "sufficient", (it makes sense to have it sufficient, as it aims to mimic sudo timestamp tickets and is suggested so in the man page) they can bypass authentication. PAM_RUSER is set in vsftpd or sssd for example. PAM_TTY can be set via dbus in gdm's x11-display variable. That has the following impact: 1. For authentication, this can allow to bypass the auth process, depending on interal app logic and the existance of certain root owned files (the file size is checked to match certain value, but chances are that such files exist somewhere under /). For openssh, if accidently included via auth-common, this can be dangerous, as the PAM_TTY is always set to "ssh". However due to PAM_TTY_KLUDGE #ifdef and internal sshd logic this probably is no issue as of today. 2. When a vector is also handling pam sessions (sssd), this bug also allows to create arbitrary files when the timestamp file is created and I guess content can be crafted with so much love to create fake shadow-file entries is possible. One should probably take care to not accidently include pam_timestamp in a config file for a remote service, as chance is high that the RUSER/TTY is used incorrectly, even when the user string is checked via getpwnam(). It should probably be documented in pam_timestamp's manpage. We are not using pam_timestamp in any of our configs, but might be that someone else is. Even if not, I think a lot of admins do. regards, Sebastian -- ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer () suse de - SuSE Security Team

Referencje:

http://seclists.org/oss-sec/2014/q1/645


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top