Unix的TTY機制的明文輸入密碼的安全問題

問題的提出

**:

ssh [email protected] mysqldump abcd emp > emptoeee -u root -p
[email protected] password:
enter password:

第乙個系統密碼是看不見的,而第二個mysql的密碼竟明文顯示了...

第乙個密碼顯然是ssh密碼驗證所需要的密碼，第二個密碼應該是遠端mysqldump所需要的密碼，但是為什麼第二個密碼就顯示明文的了呢？

問題的分析

在unix程式設計中，獲取密碼一般使用getpass(3)函式。他的定義是這樣的：

**:

#include 
char *getpass( const char * prompt );

其中prompt就是輸入密碼前面的提示語如「password：」之類類的短語，在getpass的手冊冊頁中說：

**:

for glibc2, if /dev/tty cannot be opened, the prompt is written to

stderr and the password is read from stdin. there is no limit on the

length of the password. line editing is not disabled.

也就是說，通常情況下getpass的都是使用stdin來獲取密碼的，而且《advanced unix programming》一書中我們知道，一般stdin,stdout和stderr是有tty資訊的。在這種情況下，glibc的getpass使用如下的方法：

**:

if (__tcgetattr (fileno (in), &t) == 0)

在stdin具有終端屬性的時候，這段**會成功的遮蔽掉終端的回顯功能。我們的輸入就不會被顯示出來。

但是，當我們使用netcat等工具，使用管道從網路另一端**輸入輸出資訊時，遠端程式一般會將程式的stdin和stdout,stderr重定向到網路。此時，stdin和stdout等的檔案描述符已經被替換：

**:

/* duplicate the socket for the child program */
dup2(ncsock->fd, stdin_fileno);
close(ncsock->fd);
dup2(stdin_fileno, stdout_fileno);
dup2(stdin_fileno, stderr_fileno);

上面是netcat的**，此時的stdin等的描述符已經是乙個套接字。getpass的終端操作無法進行，輸入的密碼會直接的顯示在遠端的終端上。對於一次性執行的遠端ssh命令，同樣僅僅是stdin等被賦值為網路套接字。而且，從ssh的輸出來看：

**:

[gnap@osiris ~]$ ssh ftp bash -i
[gnap@ftp ~]$ su
standard in must be a tty
[gnap@ftp ~]$ exit
exit
[gnap@osiris ~]$

遠端的bash沒有提示"no job control",估計stderr沒有被重定向。所以，建議不要使用這種方式執行需要操作終端的程式。

解決方法：

出於安全的考慮，建議盡量避免使用glibc的getpass來獲取密碼。建議自己實現密碼的獲取，並且在無法獲取tty是提示並退出程式(su)或者編寫callback程式向x索取輸入密碼(ssh)。另外，作為安全的建議，任何呼叫getpass的程式都建議放到擁有終端的環境中去執行，以避免密碼明文顯示的安全隱患。

Unix的TTY機制的明文輸入密碼的安全問題

VBS Runas 自動明文的輸入密碼

VBS Runas 自動明文的輸入密碼

unix的輸入輸出操作

Unix的TTY機制的明文輸入密碼的安全問題

VBS Runas 自動明文的輸入密碼

VBS Runas 自動明文的輸入密碼

unix的輸入輸出操作

相關推薦