Trojan Source Code

Would this affect Xojo?

https://www.lightbluetouchpaper.org/2021/11/01/trojan-source-invisible-vulnerabilities/

We have discovered ways of manipulating the encoding of source code files so that human viewers and compilers see different logic. One particularly pernicious method uses Unicode directionality override characters to display code as an anagram of its true logic. We’ve verified that this attack works against C, C++, C#, JavaScript, Java, Rust, Go, and Python, and suspect that it will work against most other modern languages.

I’d love to see an example of this.

Remember the thread from a day or so ago:

‘String.Length’ Bug?

That was caused by a string with invisible unicode characters in it.

Ah, I see. So when reading an IF statement that compares values, you might think it will do one thing when it will actually drop to the ELSE clause.

Just looking through the paper and trying something simple, xojo doesn’t render the unicode correctly so instead of seeing ⁧⁦abc⁩⁦def⁩⁩ (yes there is unicode in this post, %u2067%u2066abc%u2069%u2066def%u2069%u2069) you see abcdef which would mean you couldn’t hide the change while using the xojo ide. That being said, if the code went downstream for checking for example to a source control system that rendered it correctly, it might be overlooked and nefarious code could be let through.

I just tried the example from @GarryPettet post about the String.Length issue. It gives 21 as Garry said. The “Clean Invisibles” command does detect those characters, which are multi-byte UTF-8 characters.

You can move stuff around so it visually renders in one way but the actual code sent to the compiler reads another way, so you can fake a change and have it push into live code.

It’s really bad for bad actors that have trusted access to source in a corporation as those checking the changes over might not even know they are letting through a new zero day exploit.

Copy this line into the Xojo IDE

If accessLevel <> "user‮⁦ //check if admin⁩⁦" Then

4 Likes

Hah nifty

That doesn’t look valid on casual inspection though, but still quite nifty.

It’s not, its just showing the concept

1 Like

Here’s some valid xojo to show the problem.

Dim user as string = "user‮ ⁦ 'not admin⁩⁦"
if user="user‮ ⁦ 'not admin⁩⁦" Then
  system.DebugLog("uh oh, this was meant to be a user")
End If

If user was passed in, the user could now log in as user‮ ⁦ 'not admin⁩⁦
and the person that checked in the change would be none the wiser.

Obviously this would show in the IDE, but might now show in the source control system.

There is also the issue of replacing ascii character with their unicode lookalikes which could allow for another function to be called

Public Sub Abс()
  system.DebugLog("Fake Abc")
End Sub

Public Sub Abc()
  system.DebugLog("Abc")
End Sub

Plenty of fun :wink:

I remeber many years ago finding a Trojan on the windows install cd, they were pressed in Europe, so even if your produce a good product you have to secure end to end delivery. Don’t expect hashes will help, they won’t.

I get

The keyword ‘Then’ is expected after this if statement’s condition

And I had to type it in as copy paste changed it round

It would need to be verified, but I suspect TextInputCanvas is not able to display that kind of Unicode.

I found another “neat” Xojo issue with non-visible characters yesterday. Turns out that you can name a property of a class with text with non-visible characters (did this by mistake, pasting the property name into the IDE). You then can’t access said property by typing it’s visible name.

If you can Save As XML the project, were-you able to delete the Property ?