oss-sec mailing list archives
Re: escaping terminal control characters (was Re: backdoor in upstream xz/liblzma leading to ssh server compromise)
From: Steffen Nurpmeso <steffen () sdaoden eu>
Date: Fri, 03 May 2024 00:39:12 +0200
Sam James wrote in <87o79nlwxl.fsf () gentoo org>: |Solar Designer <solar () openwall com> writes: |> On Wed, Apr 03, 2024 at 11:03:17AM +1100, Matthew Fernandez wrote: |>> On 4/1/24 08:30, Solar Designer wrote: |>>>On Sat, Mar 30, 2024 at 04:37:48PM -0000, Tavis Ormandy wrote: |>>>>It was also pointed out they submitted an odd PR to libarchive: |>>>> |>>>>https://github.com/libarchive/libarchive/pull/1609 |>>>> |>>>>In summary, they replaced calls to safe_fprintf() with fprintf() -- |>>>>meaning control characters are no longer filtered from errors. That |>>>>seems pretty minor, but now that we know they were in the business of |>>>>obfuscating the presence of backdoors -- seems a bit suspicious. |>>>> |>>>>Regardless, that change has now been reverted: |>>>> |>>>>https://github.com/libarchive/libarchive/pull/2101 |>>> |>>>This does look minor indeed - not usable for large-scale attacks, and |>>>libarchive is quite unique in that it even bothered to filter control |>>>characters, whereas most command-line tools outputting filenames don't |>>>bother. My guess is it could have been an early experiment to see |>>>whether the project would accept PRs degrading security. |>>> |>>>That said, here's an excellent write-up by David Leadbeater on specific |>>>ways that specific terminal emulators may be usefully attacked with |>>>control sequences: |>>> |>>>https://dgl.cx/2023/09/ansi-terminal-security#vulnerabilities-using-know\ |>>>n-replies |>> |>> Is the currently accepted wisdom that any application printing to |>> stdout/stderr should take steps to avoid control characters in the |>> output? |> |> First, let's limit this to cases where the control characters come from |> potentially untrusted input to the program. Obviously, many programs |> generate terminal escapes on their own (usually via a library), for |> their intended functionality (colorized listings, TUIs, etc.) Some |> programs pass potential control characters from their trusted input. |> |> Second, I think no, there isn't currently an established opinion on |> whether programs should perform such filtering of untrusted input. | |Lasse has put up an initial implementation for xz: |https://github.com/tukaani-project/xz/pull/118. | |Comments are welcome. It was a TODO from a long time ago ;) | |We're not sure how much is overkill (or underkill) for this, especially |given it gets harder when Unicode is involved. | |> [...] For this purpose there exists the (very very expensive) https://man.netbsd.org/vis.3 series of functions. Or you do something like this, where "isuni" gives you "this is a UTF-8 nl_langinfo(CODESET)". if(!iswprint(wc) && wc != '\n' /*&& wc != '\r' && wc != '\b'*/ && wc != '\t'){ if((wc & ~S(wchar_t,037)) == 0) wc = isuni ? 0x2400 | wc : '?'; else if(wc == 0177) wc = isuni ? 0x2421 : '?'; else wc = isuni ? 0x2426 : '?'; }else if(isuni){ /* TODO ctext */ /* Need to filter out L-TO-R and R-TO-R marks TODO ctext */ if(wc == 0x200E || wc == 0x200F || (wc >= 0x202A && wc <= 0x202E)) continue; /* And some zero-width messes */ if(wc == 0x00AD || (wc >= 0x200B && wc <= 0x200D)) continue; /* Oh about the ISO C wide character interfaces, baby! */ if(wc == 0xFEFF) continue; } if((n = wctomb(mbb, wc)) <= 0) continue; This can be made better (for example the above requires "wc" to be an actual ISO 10646 codepoint, which ISO C etc), but the key point is that the Unicode standard gives you everything needed to properly mask these sequences, from its very beginning in 1993: 2400..2424 ; 1.1 # [37] SYMBOL FOR NULL..SYMBOL FOR NEWLINE and i have yet to see a font which does not support those. (Whether and how users can make sense of them totally aside.) Of course you loose the copy&paste capability. --End of <87o79nlwxl.fsf () gentoo org> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Current thread:
- escaping terminal control characters (was Re: backdoor in upstream xz/liblzma leading to ssh server compromise) Matthew Fernandez (Apr 02)
- Re: escaping terminal control characters (was Re: backdoor in upstream xz/liblzma leading to ssh server compromise) Solar Designer (Apr 03)
- Re: escaping terminal control characters (was Re: backdoor in upstream xz/liblzma leading to ssh server compromise) Sam James (May 02)
- Re: escaping terminal control characters (was Re: backdoor in upstream xz/liblzma leading to ssh server compromise) Steffen Nurpmeso (May 03)
- Re: escaping terminal control characters (was Re: backdoor in upstream xz/liblzma leading to ssh server compromise) Steffen Nurpmeso (May 03)
- Re: escaping terminal control characters (was Re: backdoor in upstream xz/liblzma leading to ssh server compromise) Sam James (May 02)
- Re: escaping terminal control characters (was Re: backdoor in upstream xz/liblzma leading to ssh server compromise) Solar Designer (Apr 03)