Comment by dgl | Hacker News Reader

Comment by dgl | Hacker News Reader

Parent Full thread

(Author here.)

If there's any takeaway from this, while the worst part is the terminal bugs; I'd like people to be aware that any tool dealing with text (command lines, potentially even websites) should consider sanitizing control characters for defense in depth.

I am amused that for example https://www.osnews.com/story/137552/31m-ansi-terminal-securi... has posted my article with the escape character in the title intact. This means that running:

  curl https://www.osnews.com/story/137552/31m-ansi-terminal-security-in-2023-and-finding-10-cves/

...will turn your screen red because of the embedded "[31m". Obviously this is just harmless fun (would have been more fun to get iTerm2's "]1337;RequestAttention=fireworks", like my curl ip.wtf/moo does, but I couldn't really stick that in the title innocently), but an attacker might be able to find a way to social engineer someone into running "curl" or similar on what looks like a trustworthy site.

edit: Hacker News also doesn't sanitize escape characters, so this very comment will turn your screen red:

  curl 'https://news.ycombinator.com/item?id=37963815'

Right on. I reported a bug to GNU Tar which allows you display pictures on someone's terminal if they list (or extract) the archive contents.

Demo: https://media.ccc.de/v/all-systems-go-2023-225-making-a-magi...

Background and utility to put such messages in tar archives: https://curiosities.nontrivialpursuit.org/tarvertise-put-a-m...

You can see for yourself whether you have the fix:

Fast featureful terminals (for instance, Kitty):

  curl -s https://obfusc.gavagai.nl/roll.tar.xz | unxz | tar tf -

Less featureful terminals:

  curl -s https://obfusc.gavagai.nl/compatroll.tar.xz | unxz | tar tf -

Slow and featureless terminals:

  curl -s https://obfusc.gavagai.nl/compatroll-lowfps.tar.xz | unxz | tar tf -

Cute, I found a similar issue in OpenBSD's tar as mentioned, I didn't share the exploit before but basically a long filename does it.

Something like: https://gist.github.com/dgl/355840320535bf8ef8b70f2e0722bf65

(I reported this one to OpenBSD but they didn't fix it. Much like Busybox, which has been known for years.)

Interesting that they didn't fix it.

I emailed the Tar maintainers privately because I thought they might consider it a security vulnerability, however mild. They fixed it promptly but didn't want to make a CVE fuss out of it.

Actually, I got it wrong, too many vulnerabilities in flight. They did fix it: https://github.com/openbsd/src/commit/375ccafb2eb77de6cf240e...

I don't think we should expect websites to sanitize escape characters. But tools such as curl perhaps should have (or already has?) some option to do it.

Or extension of the POSIX terminal control flags could result in gaining a mode, which the curls and tars of this world would use, to express to a terminal "ignore any terminal control code I write out; I don't actually mean it".

But this would require coordination in POSIX, in the terminals, and in programs using the terminal :-/

But the advantage would be that then you'd be able to put your terminal into this safe mode by default. And the terminal can alert you when a program is writing out control codes that are being ignored, and then you can whitelist them and/or get those programs fixed to fence off their sections of "I'm going to output data from god-knows-where now" with this new terminal mode.

It's not going to happen but we can dream ;-)

I have command line program that I use to give me a list of window titles. If there are too many of certain kind (browser windows...), I close some until I get under a certain threshold. Anyway, I was reading the stuff in the articles and well the text in the terminal turned red after I got that list. Some terminal/shell combinations seem better at recovering than others. Firefox (and other browsers that have a similar problem) should sanitize title data. As other have pointed out, perhaps window managers should filter or not allow control/escape characters in the titles.

Just goes to show how important sanitizing data from unknown sources is.

Should curl, w3m, wget and similar sanitize the data? One can argue that some times you want to pipe the raw data and other times one might not be thinking about the escape sequences and get burned. I would be inclined to say that the tools should filter/escape the dangerous stuff and have a flag like "--raw".

> edit: Hacker News also doesn't sanitize escape characters (...) will turn your screen red

No, it won't:

  wget -qO - https://news.ycombinator.com\
  /item?id=37963815|grep 31M|xxd -g1 -c6

  (...)
  0108: 74 3b 26 6c 74 3b  t;&lt;
  010e: 45 53 43 26 67 74  ESC&gt
  0114: 3b 5b 33 31 4d 26  ;[31M&

It does. Try grep -i

Reply on news.ycombinator.com