Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow Invisible Terms and Operators for Security Reasons #5320

Open
p6rt opened this issue May 16, 2016 · 3 comments
Open

Disallow Invisible Terms and Operators for Security Reasons #5320

p6rt opened this issue May 16, 2016 · 3 comments
Labels
RFC Request For Comments

Comments

@p6rt
Copy link

p6rt commented May 16, 2016

Migrated from rt.perl.org#128159 (status was 'open')

Searchable as RT128159$

@p6rt
Copy link
Author

p6rt commented May 16, 2016

From @zoffixznet

Hi,

Currently, some invisible characters can be used as terms and operators. Some of those are​:

  > [⁠] U+2060 WORD JOINER [Cf]
  < [​] U+200B ZERO WIDTH SPACE [Cf]
  + [⁡] U+2061 FUNCTION APPLICATION [Cf]
  - [⁢] U+2062 INVISIBLE TIMES [Cf]
  . [⁣] U+2063 INVISIBLE SEPARATOR [Cf]
  , [] U+FEFF ZERO WIDTH NO-BREAK SPACE [Cf]

This allows for malicious and invisible action at a distance. For example, in one module I can define this invisible operator​:

  sub prefix​:<⁣> is tighter(&infix​:<or>) is export {spurt 'DEBUG.txt', $^a, :append};

It uses U+2063 invisible separator. Now, in code that `use`s this module, I'm now able to silently
steal data, like say this​:

  use SomethingInnocent;
  ⁣my $credit_card = '3333-4444-4444-4444'; # pretend this is coming in from DB

By prefixing the `my` with U+2063 invisible separator, I'm silently siphoning the data assigned to $credit_card into a secret file. This addition of the invisible character also poorly shows up in revision history tools, like GitHub, for example.

I can't think of any useful case for invisible terms and operators but I can think of a malicious one.

Thus, I propose invisible terms and operators be explicitly prohibited.

@p6rt
Copy link
Author

p6rt commented May 17, 2016

From @lizmat

+1 from me. Is there a unicode property that indicates invisibleness?

Liz

On 16 May 2016, at 14​:35, Zoffix Znet (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Zoffix Znet
# Please include the string​: [perl #​128159]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=128159 >

Hi,

Currently, some invisible characters can be used as terms and operators. Some of those are​:

[⁠] U+2060 WORD JOINER [Cf]
< [​] U+200B ZERO WIDTH SPACE [Cf]
+ [⁡] U+2061 FUNCTION APPLICATION [Cf]
- [⁢] U+2062 INVISIBLE TIMES [Cf]
. [⁣] U+2063 INVISIBLE SEPARATOR [Cf]
, [] U+FEFF ZERO WIDTH NO-BREAK SPACE [Cf]

This allows for malicious and invisible action at a distance. For example, in one module I can define this invisible operator​:

sub prefix​:<⁣> is tighter(&infix​:<or>) is export {spurt 'DEBUG.txt', $^a, :append};

It uses U+2063 invisible separator. Now, in code that `use`s this module, I'm now able to silently
steal data, like say this​:

use SomethingInnocent;
⁣my $credit_card = '3333-4444-4444-4444'; # pretend this is coming in from DB

By prefixing the `my` with U+2063 invisible separator, I'm silently siphoning the data assigned to $credit_card into a secret file. This addition of the invisible character also poorly shows up in revision history tools, like GitHub, for example.

I can't think of any useful case for invisible terms and operators but I can think of a malicious one.

Thus, I propose invisible terms and operators be explicitly prohibited.

@p6rt
Copy link
Author

p6rt commented May 17, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt p6rt added the RFC Request For Comments label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request For Comments
Projects
None yet
Development

No branches or pull requests

1 participant