Initial support for securing tty I/O. #684
Conversation
|
Thanks for the review! I've now addressed all the comments. |
| Descriptor::Stdin => return Err(Error::EBADF), | ||
| Descriptor::Stdout => { | ||
| // lock for the duration of the scope | ||
| let stdout = io::stdout(); | ||
| let mut stdout = stdout.lock(); | ||
| let nwritten = stdout.write_vectored(&iovs)?; | ||
| let nwritten = if isatty { |
There was a problem hiding this comment.
we shouldn't only sanitize TTY output resp. handle terminal output in a different way than other file based output, because malicious control sequences e.g. in log files will do exactly the same harm to the host system, whenever they are viewed by a cat command etc.
There was a problem hiding this comment.
I see the PR here as fixing what we can given the current WASI API. A more complete fix will require changing the WASI spec, which I'm also looking into.
|
On 16.12.19 15:43, Dan Gohman wrote:
I see the PR here as fixing what we can given the current WASI API. A
more complete fix will require changing the WASI spec, which I'm also
looking into.
yes -- i see!
it was just a kind of reminder, but i understand and appreciate your
efforts...
|
|
The Emscripten failure looks like it's hitting a compiler bug: rust-lang/rust#66308. |
I'm happy to either disable the Emscripten job or use nightly to run the check (hopefully 66308 lands there soonish, or is there already?). EDIT: Oh, oops, I mixed rust-lang/rust#66308 with rust-lang/rust#67363. If the latter doesn't fix Emscripten, I think we should disable the job until rust-lang/rust#66308 is resolved. In terms of failing WASI tests, #743 should fix it. |
|
@sunfishcode OK I've now submitted #744 which disables the Emscripten job until rust-lang/rust#66308 is resolved. |
Co-Authored-By: Jakub Konka <[email protected]>
Co-Authored-By: Jakub Konka <[email protected]>
Co-Authored-By: Jakub Konka <[email protected]>
Co-Authored-By: bjorn3 <[email protected]>
| x if x.is_control() => '�', | ||
| x => x, | ||
| } | ||
| .encode_utf8(&mut [0; 4]) // UTF-8 encoding of a `char` is at most 4 bytes. |
There was a problem hiding this comment.
FYI Limit is only 4 if character code follows Unicode std limit 0x10ffff. But ISO std defines limit as 0x7ffffff. Which would require 6 bytes. So depends which limit the implementation ensures. But for simple pass-through encoding 6 bytes would be the safest.
There was a problem hiding this comment.
Rust documents that 4 is enough. If 5-byte or 6-byte UTF-8 encodings should ever be revived, we can expect Rust to add new functions rather than change such an invariant in existing functions.
| Descriptor::Stdin => return Err(Error::EBADF), | ||
| Descriptor::Stdout => { | ||
| // lock for the duration of the scope | ||
| let stdout = io::stdout(); | ||
| let mut stdout = stdout.lock(); | ||
| let nwritten = stdout.write_vectored(&iovs)?; | ||
| let nwritten = if isatty { |
There was a problem hiding this comment.
Maybe this should be an option to wasmtime (security strict mode vs lesser safe mode). Having the asymmetry behavior between stdout/stderr seems weird. stderr could still be used for binary data.
I do see it could be common to pipe raw/binary data into a file from wasmtime - but maybe it could be ok to require the wasmtime caller to explicitly enable this with a command line option.
I just fell security should take precedence over convenience. I guess wasmtime could just fail with nice error message when it sees escape codes to stdout/stderr (maybe also tty) in the output so the caller at least gets an explanation of why it failed.
Also, we do NOT know what the calling process of wasmtime does with the stdout/stderr handed to wasmtime. Could end up forwarding the raw data to its terminal stdout/stderr which is hidden to wasmtime.
There was a problem hiding this comment.
I agree that there's room for improvement in these areas. I'm working on a more comprehensive design, including changes to WASI itself, which I hope will address these concerns.
This implements an initial implementation of a secure TTY writer, following the first step of the plan discussed here:
WebAssembly/WASI#162
This neutralizes all escape sequences when the output is a terminal, defusing the security issues such as those described here, including reading back output from previous commands, or potentially even tricking users into executing arbitrary commands.
Introducing support for escape sequences, allowing colors and cursor positioning, is the second step of the plan, which I expect to implement in a separate PR.