Date: Wed, 22 Jun 2011 15:41:09 +0200 From: Ludwig Nussel <ludwig.nussel@...e.de> To: oss-security@...ts.openwall.com Cc: "Steven M. Christey" <coley@...us.mitre.org>, "Todd C. Miller" <Todd.Miller@...rtesan.com> Subject: Re: CVE request -- coreutils -- tty hijacking possible in "su" via TIOCSTI ioctl Josh Bressers wrote: >----- Original Message ----- >> Jan Lieskovsky wrote: >> > Hello Josh, Steve, vendors, >> > >> > based on Debian BTS report: >> >  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628843 >> > (first CVE-2011-XXYY required for Debian case) >> > >> > looked more into original report: >> >  https://bugzilla.redhat.com/show_bug.cgi?id=173008 >> > >> > and the first paragraph of  suggests: >> > "When starting a program via "su - user -c program" the user session >> > can escape to the parent session by using the TIOCSTI ioctl to push >> > characters into the input buffer. This allows for example a non-root >> > session to push "chmod 666 /etc/shadow" or similarly bad commands >> > into >> > the input buffer such that after the end of the session they are >> > executed." >> > >> > this should get a CVE-2005-YYZZ CVE id. >> > >> > Could you allocate these? >> >> ping! :-) >> > >I'm not sure if this should get two IDs. It's really one issue, which isn't >actually fixed in su. > >The fundamental issue is that tools like su and sudo keep the tty open. >The patch in question closes the tty for the case of su -c, but not for >just running su by itself. It is incomplete. I'm not worried too much about the interactive su case really. The usual direction there is user->root, not the other way around I suppose. "su -c" might be used by (%post) scripts though as seen with ikiwiki. Wrt non-interactive sudo I'm not sure. It's less likely to be used by sane packages at least as it's behavior is rather unpredictable due to it's many configuration options. >It should get a 2005 ID at the very least, MITRE will have to do that. >Perhaps two 2005 IDs? One for the issue, the second for the incomplete fix >(which is still not fixed)? > >I think the bigger issue is it needs to be decided what is proper behavior >and document that. I'm not smart enough to know if this can be fixed >properly without crippling these tools. Newer sudo actually have a use_pty option that fixes the problem. It's not enabled by default though. As I just found out there's also code missing to make sudo actually honor the option in the config (patch attached, CC'd upstream). Introducing similar code in su would be possible but requires some programming effort. sudo has a liberal licence though so the code could probably be reused. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Index: sudo-1.8.1p2/plugins/sudoers/sudoers.c =================================================================== --- sudo-1.8.1p2.orig/plugins/sudoers/sudoers.c +++ sudo-1.8.1p2/plugins/sudoers/sudoers.c @@ -649,6 +649,8 @@ sudoers_policy_main(int argc, char * con command_info[info_len++] = fmt_string("noexec_file", def_noexec_file); if (def_set_utmp) command_info[info_len++] = estrdup("set_utmp=true"); + if (def_use_pty) + command_info[info_len++] = estrdup("use_pty=true"); if (def_utmp_runas) command_info[info_len++] = fmt_string("utmp_user", runas_pw->pw_name); #ifdef HAVE_LOGIN_CAP_H
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ