33

Given that people share code on the main site and chat, it might be a good idea to either block or explicitly render control-characters and the like.

For example, if you copy the following code block into the nano editor (please DO NOT copy paste directly to the prompt, or if you do, please do not press Enter)

I like Undo's charm -- he's really one of the nicest people I've met /

you may realize that the innocuous text above hides something much more evil. All I've done is intersperse it with ^Hs, and now its true purpose is masked. This works in chat too

A user can include that or a similar message (possibly commented out, with a ^H on the commenting character) in a multiline bash script, and if people enter that directly into the terminal, many things will get deleted.

Could something be done about this?

Related Security.SE post

8
  • 4
    I vote for rendering. Don't mess with my text! Feb 5, 2014 at 21:53
  • Apparently on editing the post, the magic goes away. Example of a licensing header that is malicious Feb 5, 2014 at 22:08
  • 1
    As a preliminary fix, the characters ^H and ^] (ESC, because of vim) should be blocked from all input across SE. I'll think of more when I get time. Feb 5, 2014 at 23:07
  • I like Undo's charm -- he's really one of the nicest people I've met /
    – user1228
    Feb 6, 2014 at 14:53
  • 11
    O̼̱̠̝̳̖̞̰̖̣̞̹̞̭̳͚̔̍ͪ͌ͪ̍̋̂̆̎̓͌ͮ̄̃̄ͪ͟Ḣ͔͚̰͕̤̬̯̲͕̭͖̜̟̻̏̔͆͋̾̈́͐̿̏͆͆͡͡ ̸̴̷͙̟̮̺̝̥̻͈̹̘̪͇̞̬ͮ̍̔̏̆͌̍̃́M̨̈͐̓ͫ̽ͭ͂̃̇ͭͪ̆ͩ̀͡҉̲̰͎̤͔͓̞̯̜Y͕͙̟̩͎̹̞̣̩̍ͫͣͦ̆̎̀ ̴̴̨̧̬̟̹͖̝̼ͣͥ͒ͨͥ̆̔̃͒͗G̨̮̼̙̖̖̖͉̱̘̝̳̙̮͙̬̼͂̆̈́̔̅͒̐̃̇͗ͧ͢ͅO̳͕͍̳̭̥͚̩͕͎̟̱̝͓̞ͪͨ͒ͦ̿̈̉̈̀ͪ̆̌ͦ̔̃̌̚̚͜͜͞Ḏ̴̴̡͔͓̞̹͇̱̱͖̜̜̫͓̻̦̣̈́̀̑̔̎͒̀ ̸̧͙̘͇̼̲͖̹̫̟̥̥͔̭̺͇̤̰̇̐̓͆̆̔̈́͞ͅͅW̻͚̱̪̜̬͔̟͉̣͚̰͍̪̻̻͂ͫ̅͐̅̎͘͡ͅͅH̷̨͎͍͈̲͔̘̳̝̮͍̗͉̩̯͑̒̆̌́͊ͧ̊́͟A̷̤̗͈͈̪̯̣̠͓̻̼͓͚̾͋ͦͬ̅̎ͩ̐̄̔̀͢͝T̶̶͈̲̜͓̖̪̠̖̃̾͒̈́͞ ̢͒̍ͮ͋ͬ͑̈́ͭ̔ͫ̓ͤ̒̚҉̶̨̰̗͙̯̳̬͈̜̠̗͈͙̝̟ͅͅT̵̠̫̰̥͓͐̓ͣ͑ͥ́̃̃̉̆̋͝͡H̴̢̧̛̤̮̟͈͎̦̤̊̄ͤͫͪ͐̑ͪ̄̍̈́ͨ̎ͬ̈́̐Ę̯̗͙͍̿̊ͦͣ̓ͧͩ̎̽̆ͪ͘͟ ̸̢͖̜͙̣̦̬̥͉̰̥̯̭͇͉̺̣̦͓͚̎̍̑̒̅͘H̴͕̜̳͖̲̫͔̘̭̩̝̬͑́ͤ̿͝E̛̘̖̺̦̲̣͍͓̫͖̳̼̘ͩ͗ͩ̐ͥ̾ͫ͆̏́͟͞͠Ļ͖͚̻͎̖͈͕͙̫̯̞̜̖̝ͦ͑̑ͭ̊͋̐̈́́̐́̿ͦ̎͗͜͠ͅL̃̇̀͊̈́̌
    – user1228
    Feb 6, 2014 at 14:55
  • 2
    Can you please explain in a few words to this layman what evil thing your code does? I have no idea. When I copy this into Notepad++, I see various characters saying "BS", is that backspace or something? Mar 1, 2014 at 3:51
  • @Cerberus yes. And many terminals just accept those the same way as backspaces from the keyboard. So while it looks like a harmless comment, the backspaces convert it to something dangerous. Mar 1, 2014 at 3:53
  • 3
    @Manishearth: Ahh I see, so this only works in terminals or consoles or prompts that accept direct commands. So the reason why you would want to block this in chat is not because it could do something harmful in chat, but because people might copy and use the code in some terminal of their own and thus mess up their own computer. Mar 1, 2014 at 10:12

2 Answers 2

19

Update: Thanks for the help, Gilles, Manishearth, and snailplane. Gilles' version ([\x00-\x08\x11\x12\x14-\x1f\x7f-\x9f]) will be going into production later today.


Could something be done about this?

Sure could!

I'm looking at putting this regex into production:

[\x00-\x08\x11\x12\x14-\x19\x1A-\x1F\x7F]

to strip out every control character that's not TAB, CR, or LF. I've done a bunch of testing with various inputs and it looks like that's gonna do the trick while preserving the most important post of all time.

However, we also have sites that regularly use alphabets that reportedly use control chars as part of their encodings, such as Japanese. I've done some testing with posts from those sites, and it all looks good, but I'm not 100% convinced I haven't missed something.

Considering that this change would impact literally every post made on every site, I'm inclined to be a bit more cautious and leave this one sitting over the weekend while I do a bit more testing.

If you or anyone else seeing this post wants to run this regex and see if it preserves the right things while dropping everything potentially malicious (especially in Japanese or Chinese dialects), please do so and let me know if I missed anything. Thanks!

14
  • Don't you use Unicode exclusively? Unicode doesn't use any control character (except as control characters). \x80-\x9f are also control characters. Note that I'm talking about characters (Unicode code points), not about bytes. So assuming a Unicode regex matching engine, that's [\x00-\x08\x11\x12\x14-\x1f\x7f-\x9f]. Feb 28, 2014 at 21:23
  • Thanks for looking in to this! :) Feb 28, 2014 at 21:45
  • 1
    @Gilles \x80-\x9f aren't non-printable, so I'm not too worried about excluding those. Should I be?
    – Adam Lear StaffMod
    Feb 28, 2014 at 21:49
  • @AdamLear U+0080 through U+009F are non-printable, they're control characters. If your system tells you that \x80 is not a control character, then it isn't using Unicode (or perhaps it has a weird semantics for the \xXX notation, try \u0080 or \u{0080}). Very few systems treat them as anything special, they're mostly reserved for historical compatibility so that the Unicode range U+0000..U+00FF aligns with ISO-8859-1. Feb 28, 2014 at 21:55
  • @Gilles I thought those were the extended ASCII character set, which aren't really controls. I might be looking at the wrong reference here because Internet, though. Thanks!
    – Adam Lear StaffMod
    Feb 28, 2014 at 21:57
  • 3
    “Extended ASCII” is a phrase that means “I don't really understand character sets”. This Unicode range is made of control characters because Unicode says so. However, few (if any) systems use them to control anything. Feb 28, 2014 at 22:04
  • Seems okay on Japanese.
    – user215040
    Mar 1, 2014 at 3:38
  • @gilles some multibyte encodings use part of the control char space. I need to look this up a bit more, though. Mar 1, 2014 at 6:21
  • @Manishearth Some multibyte encodings use bytes in the 0–31 or 127–159 range. (Example: the UTF-16 encoding of Unicode uses the byte 0 to encode the 1-character string a.) As I wrote a few comments back, I'm talking about characters (so the encoding is irrelevant), and assuming the Unicode character set. Mar 1, 2014 at 7:23
  • @Gilles Depends on whether the language does regex matching on the bytes or the chars, then. I don't know how C# handles it. Mar 1, 2014 at 8:30
  • If SE is only UTF8, there shouldn't be an issue , though. Mar 1, 2014 at 8:34
  • 2
    @Manishearth .NET uses UTF-16, as far as I know. UTF-16 is decomposed in 16-bit units, not in 8-bit units, so byte matching on UTF-16 would be pretty useless. In any case, the regex engine operates on characters, so the internal representation is irrelevant. Mar 1, 2014 at 8:41
  • Ah, great, so that solves things :) Mar 1, 2014 at 8:44
  • You missed a spot. Also, did you check the non-canonical (ie., illegal) utf-8 encodings of control characters and the & character?
    – sh1
    Nov 8, 2017 at 20:27
0

You can still get the same effect using &# escapes, though you have to open your own <pre> block to stop the escape behind escaped.

<pre>xy&#8;z</pre>

I've updated the related security.SE question accordingly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .