tty hijacking redux

2013.05.21
Credit: mancha
Risk: Medium
Local: Yes
Remote: No
CWE: CWE-20


CVSS Base Score: 7.2/10
Impact Subscore: 10/10
Exploitability Subscore: 3.9/10
Exploit range: Local
Attack complexity: Low
Authentication: No required
Confidentiality impact: Complete
Integrity impact: Complete
Availability impact: Complete

A recent use-case on Slackware made me re-visit CVE-2005-4890 in the context of "su -c". Particularly, shadow's implementation as of shadow 4.1.5. During the discussions of this CVE (see footer links), it was pointed out shadow's fix is partial given interactive su remains vulnerable to tty-hijacking. It was also mentioned this vector is less worrisome given use cases for interactive su are primarily privilege escalation. The CVE was always a bit controversial with many believing using su and sudo to drop privileges is unsafe and more an administration issue than a design flaw. All that said, at the very least would it be reasonable to apply the same threat-assessment criterion to the crippling of "su -c" and not drop the controlling tty for the case when the callee is root? Slackware doesn't use PAM so the fix in shadow relies on a TIOCNOTTY ioctl() request and not a setsid() call. One result of this change is summarized in the table below: shadow 4.1.4.3 4.1.5.1 4.1.5.1+patch* 1. As unpriv user user1: xterm -e su -c $COMM SUCCESS FAIL SUCCESS xterm -e su user2 -c $COMM SUCCESS FAIL FAIL 2. As root: xterm -e su user1 -c $COMM SUCCESS FAIL FAIL ----- * See attached Cheers. --mancha

References:

http://seclists.org/oss-sec/2013/q2/374


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