We live in a magical future where "strings" is exploitable.

What is this I can't even.




Previously, previously, previously, previously, previously, previously.

Tags: , , , , , ,

10 Responses:

  1. A GNU release with a wacky, junior birdman vulnerability that didn't even have to exist? Tell me more about this new story that has never, ever happened before to every piece of software they've ever released.

  2. John Adams says:

    I still don't understand why something simple like strings has to be so overwrought

    • Edouard says:

      It's not strings, it's GNU strings. Splains everything.

      But, even so, WTF?

    • Dusk says:

      The idea was to have "strings" detect binary files, and only extract strings from the data segments, not the text segments. That way, "strings" wouldn't generate false positives on code that looks like readable text. This is a surprisingly common issue; strings like "AWAVAUATSH", for instance, are common in x86_64 code. ("push %r15; push %r14; push %r13; push %r12; push %rbx", if you're wondering.)

  3. Did you read the part that said "GNU?"

  4. The most pathetic thing about this is that the various BSDs no longer maintain the UCB version. The handbasket seats everyone.

  5. tfb says:

    The most amusing thing here is that if you're really using strings on untrusted binaries then you probably should expect whoever created the binary to have hidden strings in the text segment. So not only does its behaviour make it vulnerable, it's not even helpful in the first place. (I know you can turn it off.)

  6. Well, at least there's basically no way that anyone could remotely exploiHA HA HA HA HA RVM AND EVERY LAST OTHER CUTTING-EDGE SHITPILE THAT RECOMMENDS "wget | sh" AS A COMBINED DOWNLOAD+INSTALL METHOD.

    This industry, man. It's amazing we can walk and chew gum at the same time.

  • Previously