1. 13
  1.  

  2. 4

    Wait. I thought all physical world analogies to locked doors were erroneous because cyber is different.

    (Also, this really is a pointless change. It’s the kind of feel good distraction which probably results in net negative security.)

    1. 2

      This is pretty much the definition of when Raymond Chen writes about attacks that “rather involve being on the other side of this airtight hatchway.” Which, incidentally, he’s already done for precisely this exact “attack”. But smoke ‘em if you got 'em, I guess.

    2. 2

      Nothing the Notepad++ guy does is going to protect his users from the CIA.

      https://twitter.com/tqbf/status/839899010349555713

      1. 3

        That’s not moving the discussion forward very much, is it?

        1. 2

          Because you don’t like the conclusion? If some action is useless, are we supposed to pretend otherwise in order to advance the conversation even towards a dead end? Doesn’t calling out futility allow us to advance in more productive directions?

          1. 3

            simply linking to a content-free tweet is pretty dead-end and fails to meet any sensible standard for productive commentary. before clicking, I had my hopes up for a detailed analysis of how single-app attacks aren’t as much of a worry whereas wholistic I/O vectors are the hot new concern. I would love to see some thoughts on novel defensive techniques that might defend against client compromise.

            [meta] I increasingly think we need a “doesn’t add to the conversation” or “dead-end observation” down votes category. we have more and more comments like the root of this thread that derail and absorb attention or content from better top level options.

      2. 2

        Is the underlying technical reason for this change that although Windows can verify a signed executable when it loads, that verification doesn’t (can’t?) extend to DLLs loaded at runtime via LoadLibrary? It’s all down to the programmer of the application?

        I did a quick search of Microsoft’s documentation on secure DLL loading, but it seems to all be avoiding insecure search path orders (so malware can’t hijack Windows DLLs without access to the Windows system directories).

        EDIT: I guess this makes sense if the installer is a signed exe, which puts any DLLs in globally privileged directories. Then to replace a DLL requires same privileges as replacing the exe and/or the authenticode verifier itself. Is that how it’s supposed to work?

        1. 4

          In Unix terms, Windows always considers the directory containing the .exe to be the first entry on $LD_LIBRARY_PATH. (Or if you prefer, the directory containing an .exe is equivalent to a macOS .app bundle.) So the usual way to prevent this particular attack is to stick the application, signed or not, in a subdirectory of %ProgramFiles%, which is owned by the Windows equivalent of root. Which is why this attack normally doesn’t matter: switching out the DLL requires root access, at which point, the call is coming from inside the airtight hatchway. So this should theoretically be an entirely…er…theoretical…attack.

          What’s gotten trickier in recent years is the widespread use of “portable” applications on Windows, which are executables that are just lying randomly around your folders. These folders aren’t secure, and so the application bundles themselves aren’t secure, which finally allows this attack: anyone who can pose as the user can overwrite these DLLs with nefarious, evil ones, and thereby inject code into the process.

          So the correct fix, in Windows, would be for the installer to be signed, and Notepad++ to be put into a secured directory. Whether that directory is %ProgramFiles% or a similarly secured directory is left as an exercise to the implementor, since any secure directory will do. But it at any rate shouldn’t be e.g. just sitting on the Desktop.

          But that all said: even if you’re using the portable version of Notepad++, this attack assumes that the attacker can overwrite the DLL in the first place, which in turn means they’re able to overwrite Notepad++, with one that e.g. doesn’t verify the DLL signature. Or just uploads your files directory; screw the DLL injection.

          So…I have no idea what the bleep this is actually accomplishing. This isn’t locking your doors, knowing that a determined thief could still break a window; this is putting massive iron bolts to lock your door, but mounting them outside, where anyone can just unbolt them.

        2. -1

          The author wants to show a commitment to security in Notepad++? Switch to SaferCPlusPlus or a memory-safe language, carefully validate input, and drop any unneccesary privileges soon as possible. This is just a publicity stunt.