ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: duerst <noreply@ruby-lang.org>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:106061] [Ruby master Feature#18336] How to deal with Trojan Source vulnerability
Date: Mon, 15 Nov 2021 02:50:25 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-94652.20211115025024.50@ruby-lang.org> (raw)
In-Reply-To: <redmine.issue-18336.20211115000846.50@ruby-lang.org>

Issue #18336 has been updated by duerst (Martin Dürst).


VSCode deal with the Bidi control characters at https://code.visualstudio.com/updates/v1_62#_unicode-directional-formatting-characters.

----------------------------------------
Feature #18336: How to deal with Trojan Source vulnerability
https://bugs.ruby-lang.org/issues/18336#change-94652

* Author: duerst (Martin Dürst)
* Status: Open
* Priority: Normal
----------------------------------------
The "Torjan Source" vulnerability recently has caught some attention.

The vulnerability involves using certain combinations of Unicode characters to let source code look like it is correct (and therefore pass code review,...) but actually do something else than intended.

For background, please see discussion on KrebsonSecurity (https://krebsonsecurity.com/2021/11/trojan-source-bug-threatens-the-security-of-all-code/) and the Web site (https://www.trojansource.codes/) and original paper (https://www.trojansource.codes/trojan-source.pdf).

I contacted the Ruby security list, which was already aware of the issue, and we agreed to discuss this here because the vulnerability is already public.

The paper focuses on the use of [A] Directional Formatting Characters (*1) in string constants, comments, and similar constructs to change the visual appearance of code outside these constructs. There are related vulnerabilities, namely the use of [B] non-spacing (and therefore mostly invisible) characters e.g. in variable names, and the use of [C] mixed-script identifiers, which also lets some variable names look identical even if they are not.

Some languages, such as Rust, have addressed [A] (see https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html) by requiring escapes to be used for the relevant characters in source. On the other hand, people such as Russ Cox think compilers are the wrong place to address the issue; it should be addressed in editors and similar tools (see https://research.swtch.com/trojan). Github now warns about 

The question is what Ruby should do, if anything.
Addressing [A] similar to how Rust does it can be done relatively easily. If that's done, I'd prefer to only reject incomplete Bidi control sequences, which is a bit more complicated. In particular, string interpolation needs a very careful analysis.
For [B], I'll open a separate issue.
For [C], we have all data about scripts, but the way it's currently structured makes finding out which character a script belongs to quite inefficient.


(*1) "Directional Formatting Character" is the official Unicode term (see https://www.unicode.org/reports/tr9/#Directional_Formatting_Characters). The terms "Bidi/Bidirectional control" or "Bidi/Bidirectional control character" are also used. Overall, there are 9 such characters. Unfortunately, both the paper and KrebsonSecurity use the term "Bidi Override", which is highly misleading. The term “Bidi Override” is reserved for two characters only:
LRO, U+202D, Left-to-Right Override, and RLO, U+202E, Right-to-Left Override (see Table 1 in the paper). It is also used for the phenomenon associated with these two characters, a “hard” override (i.e. affecting all characters including e.g. the Latin alphabet), and mechanisms in other technology that achieve the same (e.g. the HTML bdo element (https://html.spec.whatwg.org/#the-bdo-element) or the ‘bidi-override’ value of the unicode-bidi property in CSS (https://www.w3.org/TR/CSS2/visuren.html#propdef-unicode-bidi)).




-- 
https://bugs.ruby-lang.org/

  reply	other threads:[~2021-11-15  2:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15  0:08 [ruby-core:106055] " duerst
2021-11-15  2:50 ` duerst [this message]
2021-11-15  5:33 ` [ruby-core:106064] " mame (Yusuke Endoh)
2021-11-15 10:19 ` [ruby-core:106071] " duerst
2021-11-22  2:55 ` [ruby-core:106197] " duerst
2021-11-23 20:39 ` [ruby-core:106232] " Dan0042 (Daniel DeLorme)
2024-10-21  8:50 ` [ruby-core:119548] " wilburlo (Daniel Lo) via ruby-core

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-94652.20211115025024.50@ruby-lang.org \
    --to=noreply@ruby-lang.org \
    --cc=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).