Announcement

Collapse
No announcement yet.

GCC 12 Ready To Help Fend Off Trojan Source Attacks

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC 12 Ready To Help Fend Off Trojan Source Attacks

    Phoronix: GCC 12 Ready To Help Fend Off Trojan Source Attacks

    Disclosed a few months back were "Trojan Source" attacks against compilers where specially crafted code could be rogue but not appear so due to exploiting Unicode issues. Unicode control characters could be used to reorder tokens in source code that could alter the behavior when compiled. With the upcoming GCC 12 compiler release there is a new warning to help point out possible Trojan Source attacks...

    https://www.phoronix.com/scan.php?pa...12-Wbidi-chars

  • #2
    Of course Malcom's in the middle of all of this.

    Scary to think that printf "Be sure to drink your Ovaltine.\n"; is the code that'll make you shoot your eye out.

    For another lol, I've been messing with this script lately and have been using "printf '%s\n' $_VAR" and my first thought was "you don't have to put the newline with the text" until I realized it was C. I don't know C so I have no idea how right or wrong '%s\n' is for printf in C.

    For a bad one...I when I started the script I was using _WRITE=$(printf '%s/n') and it took me longer than I care admit to find the typo.

    Comment


    • #3
      Originally posted by skeevy420 View Post
      Of course Malcom's in the middle of all of this.

      Scary to think that printf "Be sure to drink your Ovaltine.\n"; is the code that'll make you shoot your eye out.

      For another lol, I've been messing with this script lately and have been using "printf '%s\n' $_VAR" and my first thought was "you don't have to put the newline with the text" until I realized it was C. I don't know C so I have no idea how right or wrong '%s\n' is for printf in C.

      For a bad one...I when I started the script I was using _WRITE=$(printf '%s/n') and it took me longer than I care admit to find the typo.
      Without input checking on the variable that's being fed to %s it could potentially be disastrous. This is the kind of thing that launched a thousand DOS conditions. It's probably the same problem Apple ran into with their OS(es) and a DOS condition with specially crafted WIFI SSIDs.

      Example, let's say the output of the printf("%s\n") the variable contains improperly checked input from unknown users and is fed to a pipe. The piped command then executes whatever it's fed with an immediate enter. That's kinda out there, but the prevalence of piped output as unverified input is pretty common either on the shell prompt or in scripts. I don't know if that's what you're looking for.

      Comment


      • #4
        A warning doesn't prevent it, usually. Only an error can.

        Comment


        • #5
          Originally posted by zxy_thf View Post
          A warning doesn't prevent it, usually. Only an error can.
          Errors don't always prevent, jailing devs does.

          Comment


          • #6
            Can someone check if Rust has similar problems processing Unicode? I know it's bad of me, but I'm a bit tired of people telling me how perfect it is

            Comment


            • #7
              Originally posted by zxy_thf View Post
              A warning doesn't prevent it, usually. Only an error can.
              -Werror

              Yes, we all know that (especially) for large legacy code bases it can be painful to retrofit -Werror into the development stream.

              Comment


              • #8
                Originally posted by zxy_thf View Post
                A warning doesn't prevent it, usually. Only an error can.
                I think they can't make it an error, by default. I'm sure users of right-to-left languages would file a load of bugs on GCC, if it prevented them from printf'ing strings with those characters.

                As CommunityMember pointed out, GCC kindly gives you -Werror, if you want to treat warnings as errors.

                Comment


                • #9
                  Originally posted by OneTimeShot View Post
                  Can someone check if Rust has similar problems processing Unicode? I know it's bad of me, but I'm a bit tired of people telling me how perfect it is
                  https://research.swtch.com/trojan

                  I doubt anyone is telling people Rust is a perfect language. They might tell you it prevents a certain category of bugs and that is entirely true but there are tradeoffs involved for doing that.

                  Comment


                  • #10
                    Originally posted by skeevy420 View Post
                    I don't know C so I have no idea how right or wrong '%s\n' is for printf in C.
                    The beauty of C is in its simplicity. You could probably pick up the core language in an afternoon, except for maybe the part about pointers and heap allocation. At this point in time, I'd say it might actually be simpler than Python, which would be a reversal of the situation from when I first learned Python.

                    In C, the printf() function belongs to a weird class of functions that can take a variable number of arguments. This is sort of a quirky corner of the language. The language has no runtime type information, so the caller doesn't actually know the type or number of arguments passed, but modern compilers are pretty good about checking the format string and saving you from passing inconsistent arguments.

                    Anyway, in C, what you wrote would be:
                    Code:
                    printf("%s\n", _VAR);
                    By convention, we don't use _-prefixed variables, since I think those are reserved for the standard library. Also, many people restrict ALL_CAPS symbols for preprocessor definitions, because you really don't want to have an unintentional name-collision between one of those and a variable or function in your code! Lastly, if you use singe-quotes, C treats it as a single character. Double quotes makes it a character string, and automatically terminates it with '\0'. That's a little trick about string-processing: you often have to account for the trailing '\0' (so-called null terminator).

                    Once you get the basics of C, then you can delve deeper into things like malloc()/free()/realloc(), varargs, function pointers, preprocessor tricks, C idioms, and good style. Since C is the basis for so many modern languages, it's worth the time and effort to gain some familiarity with it. Also, it could give you a little more insight into the hardware or various things about UNIX, since C was created as a portable alternative to assembly language and then used to write a portable operating system (i.e. UNIX). Perhaps a couple things about UNIX will make more sense, when seen through the eyes of a C programmer.

                    Happy travels!

                    Comment

                    Working...
                    X