1. 15
  1. 14

    Site, paper

    This write-up isn’t very concrete, the issue is that this:

    if accessLevel != "user‮ ⁦// Check if admin⁩ ⁦" {
        fmt.Println("You are an admin.")
    }
    

    Seems alright, however, there are some sneaksy control characters in there:

    if accessLevel != "user<RLO><LRI>// Check if admin<PDI><LRI>" {
        fmt.Println("You are an admin.")
    }
    

    Which are:

    • RLO (U+202e) - Render text as right-to-left.
    • LRI (U+2066) - Isolate this text as left-to-right until PDI or newline.
    • PDI (U+2069) - End last LRI, RLI, or FSI.

    This is very difficult to see; Vim shows the RLO as <202e>, but it doesn’t show the other two, although it behaves weird when editing and you can see it if you move the cursor and press e.g. g8 or have the codepoint in the statusline. This probably depends on your terminal too.

    So essentially it renders two blocks of left-to-right text in right-to-left order:

    if accessLevel != "user[// Check if admin][" {]
    

    There are more complex things you can do as well; this was adapted from one of their examples. It seems GitHub presents you with a warning to protect you.

    I’ve always hated these LTR things as a user and developer. Copy something accidentally and everything will behave weird and it’s really hard to understand what’s going on; the only reason I know is because I know about Unicode, but most people don’t, and even if you know about Unicode it’s a pain to deal with as you can’t “just delete” or “see” them clearly in pretty much all text inputs.

    1. 6

      Similar ploy I heard proposed once: contribute code to a project which is correct, but has warnings; if the warnings are ‘fixed’ the way the compiler suggests, the result will be buggy. So you submit correct code, but plant the seeds for somebody else to create a vulnerability. The example given was about signed/unsigned conversions, which are commonly misunderstood anyway (that is a problem in its own right).

      1. 2

        I have seen that happen unintentionally once. It is long enough that I can’t summon the details without involving one of the guilty parties – Code that was ‘added to make Coverity to shut the f- up’ led the RSS client to introduce data corruption in the flash driver of a certain feature phone.

        1. 1

          The alarming part of that is not the bug itself. It’s that the RSS reader can meaningfully affect the flash driver at all. It’s reading and acting upon untrusted data from the network all the time!

          1. 1

            You could save a few cents per device by not having a MMU - so process separation wasn’t a thing.

            1. 1

              I appreciate that. I’m still very glad that low-end smartphones are slowly eating the feature phone market from above. Those things are radioactive junk.

              1. 1

                Yeah their time has thankfully come and passed. I am, politely put, not a friend of Android internals, but given what it replaced – it was a step up, even compared to alternatives when Android wasn’t exactly certain — the first versions were incredibly rocky, duct-tape everywhere.

                The amount of stuff that has been shoved into the hardware ‘platform’ nowadays though is a misstep in another direction though.

      2. 2

        It should be possible to write a tool that scans all of GitHub/Gitlab and see if somebody exploited the approach already.

        1. 1

          First thought: doesn’t syntax highlighting trivially defeat this?

          1. 1

            Yes, it seems it does. There’s quite a lot of discussion on the HN thread which for once seems to be a cut above the usual level:

            https://news.ycombinator.com/item?id=29061987