[swift-evolution] A path forward on rationalizing unicode identifiers and operators

[Félix Cloutier]

> Le 2 oct. 2017 à 21:40, Chris Lattner <clattner at nondot.org> a écrit :
> 
>> On Oct 2, 2017, at 1:13 AM, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> If you tried hard enough, you could probably create a variable that looks like it's shadowing one from an outer scope while it actually isn't, and use the two to confuse readers. This could trick people into thinking that some dangerous/backdoor code is actually good and safe, especially in the open-source world where you can't always trust your contributors.
>> 
>> On one hand, other than the complexity of telling if two characters are lookalikes, I don't know why Αrray (GREEK CAPITAL LETTER ALPHA) and Array (LATIN CAPITAL LETTER A) should be considered different identifiers. On the other hand, I struggle to imagine the specifics of an exploit that uses that. You'd have to work pretty hard to assemble all the pieces of a backdoor in visually-similar variable names without arousing suspicion.
> 
> I don’t think this is something we have to try hard to avoid.  It is true that some characters look similar, particularly in some fonts, but this isn’t new:
> 
>   let a1 = 42
>   let al = 12
>   let b = al + a1 

There is a fundamental difference between similar characters and characters that are meant to be visually identical. People judge the quality of a font by its Unicode support, and that means that only "low-quality" fonts would render, say, LATIN CAPITAL LETTER T and GREEK CAPITAL LETTER TAU differently.

> If there were real code that was maliciously shadowing to try to cause confusion, then you have a more serious problem on your hands than someone accidentally misunderstanding which one to use.

I'm not sure I understand. If the "more serious problem" you're talking about is that your popular project is a valuable target to subvert, then there is no question that being backdoored would be more serious than people not reading your code right. I don't see how it pushes the problem out of scope, though.

As a security guy, I take my role of thinking about how anything can be abused very seriously. Backdoored open source projects turn up every now and then.

This code is backdoored. I challenge you to spot the bug:

func shellEscape(_ args: [String]) -> [String]?
func isWhitelisted(_ tool: String) -> Bool

func execute(externalTool: String, parameters: [String]) {
    if isWhitelisted(externalTool), let pаrameters = shellEscape(parameters) {
        print("Running tool \(pаrameters[0])")"
        system(parameters.joined(separator: " "))
    }
}

> All I’m saying is that we shouldn’t complicate the design to solve this problem (IMO).  If it falls out of the solution somehow (e.g. just disallow invisible characters) then that’s great of course!

How did you identify the bug in the snippet from above? Is it practical enough that you would, for instance, recommend that the server group do that test on every PR that they receive going forward?

I think that it's hard to build something meaningful without making it look suspicious. It's already kind of fishy that my shellEscape function returns an Optional, and people will eventually figure out that the parameters are not, in fact, shell-escaped. Still, I feel that it should be recognized that security is more than buffer overflows and integer overflows, and if there ever is an underhanded Swift code contest, that'll be my entry.

Félix

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171003/d14b3e98/attachment.html>