Date: Thu, 12 Apr 2018 19:13:27 +0200 From: Jakub Wilk <jwilk@...lk.net> To: oss-security@...ts.openwall.com Subject: Re: Terminal Control Chars * Gordo Lowrey <gordo@...eval.com>, 2018-04-10, 03:53: >>The correct solution would be to disallow the pasting of certain >>control characters. > >I'm just gonna go out on a limb here, and say this is an unfounded >assertion. > >Perhaps the correct solution would be to prevent the browser from >copying invisible characters. Do you mean control characters, or something else? >If you're going to break some basic mechanic of human computer >interaction, Huh? Most users don't interact with their terminal-based software by pasting control characters. I bet most people don't even realize that it's even possible to do that. I've been using terminal emulators for 15 years, and the only time I willingly did such pastes was to test exploits for this very problem. If you have a practical use case for such interaction, please tell us what is. I, for one, have no idea what this might be. >Instead of worrying about sanitizing what is pasted, why not worry >about sanitizing what is copied instead? Why? Is it the browser fault that terminal emulators interpret some characters in a funny way? Besides, paste consumers have much better idea what needs to be sanitized than paste producers. * For software that access the clipboard directly, no sanitization is needed. Yay! * On some systems, if terminal is a cooked mode, control characters can be escaped, usually with ^V. (But a paste producer can't possibly know what the terminal mode or the escape character is going to be!) * In bracketed paste mode, the only sequence that needs to be neutralized is the one that leaves the mode. From egoistical point of view, I'd also prefer if this was fixed in my terminal. On my system, I have multiple paste producers potentially affected by this (web browser, two PDF readers, office suite, ...), but only one terminal emulator installed. It's much easier for me to verify that the terminal emulator behaves (it doesn't) than to check the rest of the software involved in this mess. BTW, a recent LWN article about terminal emulators briefly mentioned the problem of pasting security: https://lwn.net/Articles/749992/ (The article incorrectly states that urxvt's confirm-paste plugin protects against this attack. Read the article comments to see why this is not the case.) -- Jakub Wilk
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