-
Notifications
You must be signed in to change notification settings - Fork 100
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
⚠️DANGER: Vulnerable by design! (on any system supporting TIOCSTI, such as Linux) #23
Comments
Also, sorry about the clickbaity title. I just wanted to make sure this wouldn't go unnoticed, and hopefully reduce the chance of people continuing to use this without being aware of and considering its limitations. No offense intended. |
I think we should add a big warning in the README. Care to create a PR? |
There is a more detailed discussion and links on the gosu bugreport: tianon/gosu#37 |
`man bwrap` > Create a new terminal session for the sandbox (calls setsid()). https://www.openwall.com/lists/oss-security/2017/06/03/9 ncopa/su-exec#23 tianon/gosu#37 https://ruderich.org/simon/notes/su-sudo-from-root-tty-hijacking Relates-to: #2
Can we just add the solution referred to in the section of the comment quoted above to the warning & consider it done? |
For a subset of users, yes, as the new config ( |
Hello,
I regret to inform you that any program which crosses privilege boundaries in the manner this program does without also restricting access to the parent TTY (which seems to be the main design (mis-)feature of this program), is fundamentally vulnerable by design on any system allowing the TIOCSTI ioctl on said TTY.
See: https://www.openwall.com/lists/oss-security/2017/06/03/9
See also: https://ruderich.org/simon/notes/su-sudo-from-root-tty-hijacking
See also: tianon/gosu#37
Linux still supports TIOCSTI, and refuses to change due to its unfortunate posture of tying its own hands to keep backwards-compatibility with userspace forever. OpenBSD has removed it, but your users are probably mainly Linux people.
One way to address this is to do exactly as you currently complain about other programs doing (parent staying alive to proxy io), which seems to be the entire reason you wrote this. There are non-portable ways of filtering TIOCSTI without proxying io and otherwise breaking parent TTY manipulation (see util-linux/util-linux@8e49250, for example), but this will not necessarily work on all systems, and IMO manipulation of TTYs across privilege boundaries sounds more like a bug than a feature to begin with as it may allow intended-to-be-deprivileged code from triggering undefined behavior in the parent context.
Consider adding an appropriately scary warning to README.md, and notifying any downstream consumers you are aware of.
Sorry to be the bearer of bad news.
The text was updated successfully, but these errors were encountered: